CiscoWorks LAN Management Solution (LMS) Common Services provides a robust security mechanism to manage identity and access to the CiscoWorks applications and data in a multiuser environment. As CiscoWorks has powerful network management tools for device configuration and software image management, unintended operations carried out by unauthorized users can cause disruptions to your network and in turn have a severe impact on the business-critical activities. CiscoWorks addresses this requirement by integrating with Cisco® Secure Access Control Server (ACS) to provide improved access control by means of authentication, authorization, and accounting (AAA).
ACS is a scalable, high-performance Remote Access Dial-In User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS+) security server. As the centralized control point for managing enterprise network users, network administrators, and network infrastructure resources, ACS provides a comprehensive identity-based network-access control solution for Cisco intelligent information networks. ACS provides authentication, authorization, and accounting (AAA) services to network devices that function as AAA clients, such as a router, switches, network access server, PIX Firewall, and even the CiscoWorks server (Figure 1).
Figure 1. AAA Client Model
CiscoWorks can be integrated with an ACS server to address the following tasks:
• Provide centralized user management for a group of CiscoWorks servers.
• Provide device-level authorization. Device-level authorization restricts user access to perform certain tasks such as configuration updates and software image updates by authorizing the user for the task.
• Provide editable user roles. The user roles are mapped to tasks that the user is authorized to perform on the devices. ACS allows for the modification of the existing CiscoWorks user roles and for the creation of a new user role.
• Using ACS, groups of users can be assigned user roles per group of devices on a per application basis for the ultimate in authorization control.
The CiscoWorks server will be defined as an AAA client, just like network devices are. When a user tries to log in to the CiscoWorks server, the CiscoWorks server (AAA client) sends a request to the ACS server (AAA server) to authenticate the user, check the authorization, and audit the activities of the user.
This document provides a detailed explanation and step-by-step procedures for setting up CiscoWorks LMS to integrate with Cisco Secure ACS server. The versions of the software used in this white paper are:
• CiscoWorks LMS 3.0 with Common Services 3.1
• Cisco Secure ACS Server 4.1
Note: If multiple LMS or CSM servers are integrating with one ACS server, the Common Services modules on these servers must be of the same version.
Installation of Cisco Secure ACS 4.1 Server
Before integrating your CiscoWorks Common Services with Cisco Secure ACS, you need to have completed the installation of CiscoWorks Common Services and Cisco Secure ACS on the appropriate servers and make sure that network connectivity exists between the two.
Cisco Secure ACS comes in two configurations:
• Cisco Secure ACS for Windows: Software for installation on Windows servers
• Cisco Secure ACS Solution Engine: A 1-rack-unit (1RU) hardware appliance with a preinstalled Cisco Secure ACS license
Cisco Secure ACS for Windows is suitable for customers who prefer to control their operating environment (this may include the type of hardware servers, OS, and installed services). In many cases, where security operations and server/OS operations are different departments in an IT organization, having a security solution on a dedicated appliance facilitates the manageability. In addition, the appliance solution provides benefits such as enhanced security, one-stop support, and a "plug-and-play" solution.
This white paper assumes that the user is selecting the first option to install ACS on their own. Otherwise please go directly to section 3 on page 10.
Installing ACS 4.1
Table 1 lists the system requirements for installing Cisco Secure ACS.
Table 1. System Requirement for ACS 4.1
Component
Minimum Requirement
Hardware
• IBM PC-compatible with Pentium 4 processor, 1.8 GHz or faster
• Color monitor with minimum graphics resolution of 256 colors at 800 x 600 resolution
• CD-ROM drive
• 100BaseT or faster connection
Operating system
• Windows 2000 Server (English version only)
• Windows 2000 Advanced Server (Service Pack 4) without features specific to Windows 2000 Advanced Server enabled or without Microsoft clustering service installed (English version only)
• Windows Server 2003, Enterprise Edition or Standard Edition (Service Pack 1)
File system
New Technology File System (NTFS)
Memory
1 GB, minimum
Virtual memory
1 GB, minimum
Hard drive space
At least 1 GB of free hard drive space, minimum
Note: The actual amount of hard drive space required depends on several factors, including
log file growth, and replication or backup purposes.
The setup program for ACS 4.1 is quite straightforward, just like any other Windows installation programs. The user can finish the installation easily by following the GUI messages. Most of the advanced options can be kept as default if there is no need to customize the ACS server settings (Figure 2).
You need to have administrative privileges for the Cisco Secure ACS server and CiscoWorks server to be able to execute the steps explained in this document.
Common Services 3.1 supports the following versions of Cisco Secure ACS for Windows Server:
• Cisco Secure ACS 3.2 for Windows Server
• Cisco Secure ACS 3.2.3 for Windows Server
• Cisco Secure ACS 3.3.2 for Windows Server
• Cisco Secure ACS 3.3.3 for Windows Server
• Cisco Secure ACS 3.3.4 for Windows Server
• Cisco Secure ACS 4.0.1 for Windows Server
• Cisco Secure ACS 4.1 for Windows Server
• Cisco Secure ACS 4.1.1 for Windows Server
• Cisco Secure Appliance 3.3.3
• Cisco Secure Appliance 3.3.4
• Cisco Secure Appliance 4.0.1
• Cisco Secure Appliance 4.1
• Cisco Secure Appliance 4.1.1
It is recommended that you install the patches, such as the Admin HTTPS PSIRT patch, for the earlier versions.
• Click the Download Cisco Secure ACS Software (Windows) link. You can find the link to the Admin HTTPS PSIRT patch in the table.
Network and Port Requirements
CiscoWorks uses TACACS+ to integrate with ACS. Make sure that the gateway devices between AAA clients and Cisco Secure ACS allow communication over the ports needed to support the TACACS+ protocol for Cisco Secure ACS to provide AAA services to the AAA client.
It is recommended to open all ports on ACS prior to the integration, and then close unused ports after the integration. Table 2 lists the port numbers to be allowed by the gateway devices.
Table 2. Port Numbers for the Gateway Devices
Feature/Protocol
UDP or TCP?
Ports
TACACS+
TCP
49
Cisco Secure Database Replication
TCP
2000
RDBMS Synchronization with synchronization partners
TCP
2000
User-Changeable Password web application
TCP
2000
Logging
TCP
2001
Administrative HTTP port for new sessions
TCP
2002
Administrative HTTP port range
TCP
Configurable; default 1024 through 65535
ACS Server can be accessed across remote machines from the browser; it uses the port number 2002 for its communication.
Note: Cisco Secure ACS and CiscoWorks Common Services cannot coexist on the same server due to a port number conflict.
After ACS 4.1 is successfully installed, the first thing you need to do is to create an administrator user so you can access the ACS server remotely using a Web browser.
Note: If ACS is running on an appliance, the appliance administrator cannot be used as the ACS administrator for LMS integration. The ACS appliance administrator will be visible on the main Administration Control page.
To create the user administrator:
Step 1. Log in to the ACS server locally or through Remote Desktop if it is available.
Step 2. The ACS installation program created a desktop icon for ACS Admin. Double-click the desktop icon to open the browser interface, or manually start Internet Explorer/Firefox and point to http://127.0.0.1:6729. See Figure 3.
Figure 3. Cisco Secure ACS 4.1 Browser Interface
Note: If you cannot view the ACS Web interface, check whether your Internet Explorer/Firefox application is up to date and Java is installed on the local machine.
Step 3. From the menu on the left side, click the Administration Control button. Then add the username you can want to add, for example, administrator, as in the figure 4.
Figure 4. Administration Control Window
Follow the screen to give the password and click the Grant All button to give all administrative privileges to the administrator (Figure 5).
Figure 5. The Administrator Privileges Window
After the administrator user is created, you can log in to the ACS server remotely through the browser at http://servername:2002. Port 2002 is the default port for ACS server Web access.
Workflow for LMS/ACS Integration
Add CiscoWorks Server as an AAA Client in ACS
By default, ACS allows the user to add AAA clients individually. The best practice is to use a network device group (NDG) so you can group the AAA clients and manage them as groups. To use an NDG, you need to turn on the NDG option under Interface Configuration/Advanced Options (Figure 6).
Figure 6. Advanced Options
Then go to Network Configuration to add the CiscoWorks server as an NDG (Figure 7).
Figure 7. Network Configuration
Click Add Entry to add a new NDG LMS server (Figure 8).
Figure 8. New Network Device Group Window
Then add the LMS server itself as an AAA client to the NDG you just created. The LMS server must be added to ACS as a TACACS+ (Cisco IOS) client even though the server does not run Cisco IOS® Software (Figure 9).
Figure 9. Adding an AAA Client
In the Shared Secret box, type the shared secret key that your CiscoWorks server and Cisco Secure ACS use to encrypt the data (up to 32 characters).
Note: For correct operation, the identical key must be configured on the AAA client and Cisco Secure ACS. Keys are case sensitive.
From the Authenticate Using list, select the network security protocol used by the AAA client. Here we selected TACACS+.
Uncheck the single connection TACACS+ option. This must not be used for LMS integration.
If you want to log watchdog packets, select the Log Update/Watchdog Packets from this AAA Client check box.
If you want to log RADIUS tunneling accounting packets, select the Log RADIUS Tunneling Packets from this AAA Client check box.
If you want to track session state by username rather than port number, select the Replace RADIUS Port info with Username from this AAA check box.
Note: If you select this option, Cisco Secure ACS cannot determine the number of user sessions for each user. Each session uses the same session identifier, the username; therefore, the Max Sessions feature is ineffective for users accessing the network through an AAA client with this feature selected.
Note: Restart the ACS service by going to System Options.
Add Network Devices as AAA Clients in ACS
Before you register LMS applications with ACS, it is recommended to add all the devices into ACS so both LMS and ACS have the complete list of devices in their database.
There are two ways to do this; one is to export the device list from LMS to ACS using the dcrcli command utility; the other way is add the devices manually.
• Export LMS devices to ACS using dcrcli.
See Appendix C for how to use dcrcli.
• Manually add devices.
For example, in Figure 10, three NDG groups are created, Core, NorCal, and SoCal. These NDGs will be used in the example in the section "Secure View: Limit the Device Access per User Group Level."
Figure 10. Network Device Groups
Add devices into the NDGs. For example, Figure 11 shows the IP address range or individual IP addresses specified for the NDGs.
Figure 11. Specifying the Address or Address Ranges for the NDGs
Switch CiscoWorks Server to AAA Mode
Now it is time to change the AAA mode from non-ACS to ACS. Go to Common Service > Security > AAA Mode Setup (see Figure 12).
Figure 12. Common Services AAA Mode Setup
Here is an explanation of the options available on this screen.
Server Details
Cisco Works Common Services Software supports up to three backup servers. When the primary Cisco Secure ACS server fails, the AAA requests are redirected to the secondary or backup servers. You can have multiple backup servers for a higher level of redundancy.
It is not mandatory to have all three Cisco Secure ACS servers. You can still have a single primary server.
When you have multiple Cisco Secure ACS servers for backup, make sure that the configurations on all servers are synchronized.
Note: If you enter the hostname instead of the ACS server IP in Solaris, make sure the hostname is resolvable through either Domain Name System (DNS) or the local hosts file.
ACS TACACS+ Port: Port number 49 is utilized by Cisco Secure ACS for the TACACS+ communication.
Login
ACS Admin Name: Enter the administrator user name that you would use to log in to Cisco Secure ACS. This is the same user you created under Administration Control in ACS.
ACS Admin Password: Enter the administrator password that you would use to log in to Cisco Secure ACS.
ACS Shared Key: Enter the shared secret key that you entered in Cisco Secure ACS while adding the CiscoWorks Common Services server as an AAA client.
Application Registration
You can choose to register all installed applications with Cisco Secure ACS by selecting the check box under Application Registration. But you need to know about the following before registering the applications with Cisco Secure ACS:
• Authorization in CiscoWorks is done based on tasks available for every application. The task definition and task to role mapping are available in three XML files. They are:
– <App name>TaskDefinition.xml
– <App name>RoleDefinition.xml
– <App name>Tasks.xml
• By default five predefined roles are available. However, Cisco Secure ACS provides the feature of customized roles, wherein you can create a new role or edit the privileges of the predefined roles. See the section "Role-Based Access Control: Edit Predefined User Roles and Create New Custom User Roles" about this topic.
• In case of an application being reregistered from Common Services, the custom roles (if any) created for that application would be lost. The application registration from the AAA Mode Setup will reregister all the installed applications to Cisco Secure ACS, which will cause the custom roles (if any) to be lost. But this mass application registration can be avoided by using the command-line interface (CLI) script AcsRegCli.pl as explained later.
ACS Communication on HTTPS
Cisco Secure ACS supports secured communication through the Secure Sockets Layer (SSL) mode. HTTP/HTTPS mode is used for device cache initialization, application registration, and administration purposes.
It is recommended to use HTTP to set up LMS integration with ACS. This comes with less overhead, and allows sniffer traces to be collected
In case you have to use HTTPS, select the check box option under ACS Communication on HTTPS when Cisco Secure ACS is configured to work in HTTPS mode.
Note: When you select HTTPS mode, make sure that the backup servers are also in HTTPS mode.
Note: The SSL mode is not applicable to the TACACS+ or RADIUS security protocols, which are used for authentication and authorization between AAA clients and the server.
Refer to Appendix A of this document for information on selecting HTTPS mode and installing security certificates on Cisco Secure ACS.
After clicking the Apply button, one message shows up (Figure 13).
Figure 13. Verification Status
Click the Apply button again to register the applications.
Note: If you have registered before, clicking the Apply button will lose all the custom roles created in ACS.
Figure 14 shows that the LMS applications have been registered successfully to ACS.
Figure 14. Login Module Change Summary
Add the System Identity user
The System Identity user makes possible the trusted communication between LMS and ACS servers. It must be properly set up on both the LMS and ACS servers.
First, in LMS Common Services, add the System Identity user under Local User Setup and assign it all the default roles (Figure 15).
Figure 15. Local User Setup
Then specify the System ID under Common Service > Server > Security > System Identity Setup (Figure 16).
Figure 16. System Identity Setup
In ACS, create a group named SuperAdmin and create a user systemiduser to belong to this group.
First, create the SuperAdmin group (Figure 17)
Figure 17. Creating the SuperAdmin Group
Then create and assign a user systemiduser to this SuperAdmin group.
Restart the Daemon Manager from the Command Line
On Windows:
1. Enter net stop crmdmgtd.
2. Enter net start crmdmgtd.
On Solaris:
1. Enter /etc/init.d/dmgtd stop.
2. Enter /etc/init.d/dmgtd start.
Verify the Integration
To verify the integration, log in to ACS as administrator, click Shared Profile Components and check to make sure that all the LMS applications show up (Figure 18).
Figure 18. Shared Profile Components
Also notice under each application, such as Common Services, a new Super Admin user role is created (Figure 19).
Figure 19. CiscoWorks Common Services Shares Profile Components
Note: Since you have not created any user on ACS, the CiscoWorks server is not open for access yet. Please perform the steps in the scenarios described below to create ACS users to get access to CiscoWorks.
Use Cases for LMS/ACS Integration
Here are two typical use cases for integrating LMS with ACS for the AAA functions.
Secure View: Limit the Device Access per User Group Level
Here is a typical use case:
Acme Corp is a corporation headquartered in Central California. The company has two branch offices, one in Northern California, another one in Southern California. There are three groups of network administrators:
• The SuperAdmin group is in charge of the whole network. Members of this group must have access to all the devices and be able to perform all management tasks on the network.
• The SoCal group is responsible only for the Southern California office network. Members of this group are allowed to perform management tasks only on the devices in their office.
• The NorCal group is responsible only for the Northern California office network. Members of this group are allowed to perform management tasks only on the devices in their office.
To meet this goal, you can separate the network devices into three NDGs:
• The core NDG: Network devices for the headquarters in Central California
• The SoCal NDG: Network devices in the Southern California office
• The NorCal NDG: Network devices in the Northern California office
The SuperAdmin administrator group will have access and control on all the NDGs. SoCal administrators will have access and control only for the SoCal NDG. NorCal administrators will have access and control only for the NorCal NDG. This way you can create secure views of the network that limit the management scope based on the group of the administrators.
Step 1. Create NDG groups for the devices (Figure 20).
Figure 20. Creating NDG Groups for the Devices
Add devices into the NDGs. For example, Figure 21 shows the IP address ranges for the NorCal, SoCal, and Core NDGs.
Figure 21. Address Ranges for the NDGs
Step 2. Create user groups for the administrators.
First, click the Group Setup menu, then rename the default Group 1 as the SuperAdmin group, Group 2 as NorCalAdmin, and Group 3 as SoCalAdmin (Figure 22).
Figure 22. Renaming the Groups
Select the group and choose edit setting. For example, for the SuperAdmin group, scroll down until you see the LMS applications. Then grant access to all the NDG groups as the superadmin role by adding associations from the dropdown lists. Make sure it has superadmin permission to both the device groups NDG and the LMS server NDG (Figure 23).
Figure 23. Group Setup
Repeat for all the application for the SuperAdmin group.
For the NorCal group, perform the same operation on all LMS applications but limit its access to only the NorCal NDG. Make sure it also has superadmin permission to the LMS server NDG (Figure 24).
Figure 24. The NorCal NDG
Notice the NorCal administrator group can only access the NorCal NDG and the LMS server NDG.
Similarly for the SoCal administrator, access is granted to only the SoCal NDG and LMS Server (Figure 25). Make sure it also has superadmin permission to the LMS server NDG.
Figure 25. The SoCal NDG
Step 3. Create users and assign them to different user groups.
Now you are ready to create the administrator as ACS users and assign them to different user groups.
Create three users:
• alladmin belongs to the SuperAdmin group.
• lajolla belongs to the SoCalAdmin group.
• nobhill belongs to the NorCalAdmin group.
As an example, the Figure 26 shows that the alladmin user is assigned to the SuperAdmin group.
Figure 26. The User alladmin
Step 4. Verify the setup.
To verify the setup, log in to LMS using the different user names just created. Go to Common Services/Device Management, and make sure the users can only see their assigned devices. For example, user alladmin can see all devices, also under the System view (Figure 27).
Figure 27. DCR and AAA Information
If the user is granted access to only part of the network, the rest of the devices will show up in Devices Not Configured in ACS. For example, user lajolla can only see 10 devices; the other 22 devices are marked as Devices Not Configured in ACS (Figure 28).
Figure 28. Access for User lajolla
The last step to verify the integration works is to perform some management jobs such as device discovery in Campus Manager, sync archive in Resource Manager Essentials (RME), and so on. If the task can be started and finished as expected, the integration is considered a success.
Note: If the task cannot be started due to permission error, then something is wrong with the integration. Some possible reasons are:
• The user group is not assigned with proper permissions to carry out the job.
• The System Identity user is not set up properly. Remember it must belong to the SuperAdmin group.
Role-Based Access Control: Edit Predefined User Roles and Create New Custom User Roles
CiscoWorks LMS has five predefined local user roles. These roles cannot be edited or customized. The only way to create customized roles is to integrate with ACS.
Here are the default five predefined local user roles:
• Help Desk (default role for all users): Can access network status information only. Can access persisted data on the system but cannot perform any action on a device or schedule a job that will reach the network.
• Approver: Can approve all tasks.
• Network Operator: Can do all Help Desk tasks. Can do tasks related to network data collection but cannot do any task that requires write access on the network.
• Network Administrator: Can do all Network Operators tasks. Can do tasks that result in a network configuration change.
• System Administrator: Can perform all CiscoWorks system administration tasks.
These roles determine which CiscoWorks applications, tools, and product features you are allowed to access. Roles are not set up hierarchically, with each role including all the privileges of the role "below" it. Instead, these roles provide access privileges based on user needs.
You can view the permission in details by generating a Permission Report under Common Services/Server/Reports (Figure 29).
Figure 29. Permission Report
Note: This Permission Report is for the local user role only. It will not reflect the change after integration with ACS.
After integrating with ACS, you can create new custom roles to provide role-based access control (RBAC). Please do not edit the predefined roles.
Adding a New Role
To add a new CiscoWorks role on Cisco Secure ACS:
1. Select Shared Profile Components > CiscoWorks Common Services and click the Add button to add a new role. The new role definition page will appear as show in the Figure 30.
2. Select or deselect any of the Common Services tasks that suit your business workflow and needs of the new role.
3. Click Submit.
Figure 30. Shared Profile Components: Adding a New CiscoWorks Common Services Role
After the new customized role is created, you can create new users in ACS and assign them to these roles for proper access permission.
Logs and Reports
Cisco Secure ACS logs a variety of user and system activities. Depending on the log, and how you have configured Cisco Secure ACS, logs can be recorded in different formats with different attributes.
The logging can be enabled from the Logging configuration under the System Configuration (Figure 31). Refer to the Cisco Secure ACS User Guide section on system configuration for more information.
Figure 31. System Configuration: Logging
You can enable the following three logs, which can be useful when you are debugging CiscoWorks-related user activities and events:
• Passed Authentications: Contains the details of passed authentication
• Failed Attempts: Contains the information for failed authentication and authorizations
• TACACS+ Administration: Audit records
The reports and logs can be viewed from the Cisco Secure ACS Reports and Activity page (Figure 32).
Figure 32. Reports and Activity
Appendix A: Generating Certificates in ACS for SSL Mode
The ACS Certificate Setup pages help enable you to install digital certificates to support HTTPS for secure access to the Cisco Secure ACS HTML interface.
HTTP/HTTPS is used for the following operations between the CiscoWorks server and Cisco Secure ACS:
• Import/export device groups
• Import/export devices
• Audit requests
• Initialize device cache (which in turn calls Import devices)
• Register/unregister applications
Perform this procedure to install a server certificate for your Cisco Secure ACS. You can perform certificate enrollment to support HTTPS for HTML Interface to Cisco Secure ACS. There are three basic options by which you can install the server certificate; you may:
