The problem areas of CS ACS can be categorized as follows:
Installation and upgrade issues
CS ACS with Active Directory integration
CS ACS with Novell NDS integration
CS ACS with ACE Server (Secure ID [SDI]) integration
Replication issues
Network access restrictions (NAR) issues
Downloadable ACL issues
Installation and Upgrade Issues
If you follow the procedure properly, installation or upgrade is a fairly easy process for both CS ACS on Windows and CS ACS Appliance. This section examines the installation and upgrade procedure, important issues to be aware of, things that may go wrong, and how to resolve the problems.
CS ACS on Windows Platform
Depending on the version of CS ACS that needs to be installed, check the following documentation to make sure all the minimum requirements for the Operating System version, Service Packs (SPs), and so on, are met. Otherwise, abnormal failure might occur that might not be diagnosed or supported by Cisco TAC unless the documented minimum requirement is fulfilled.
http://www.cisco.com/warp/public/480/csnt.html
Installation steps are intuitive, and therefore they are not covered here.
Upgrading from an older to a new version is a little more complex than installing a new version. However, if you work through the following steps carefully, you can minimize the chance of upgrade failure substantially:
Step 1. Review the prerequisites for installation of the version that you are trying to upgrade. If you must perform an incremental upgrade, for instance, from CS ACS 2.3 on NT platform to CS ACS 3.3 on Win 2K platform, define the strategy.
Step 2. Back up the database using C:\Program Files\CiscoSecure ACS v3.3\Utils>CSUtil -b (full backup including NAS information) and C:\Program Files\CiscoSecure ACS v3.3\Utils>CSUtil -d (partial backup, only users/groups information) options, and save the files offline in a different location.
Step 3. Run the setup.exe file of the new version.
Step 4. If the standard upgrade procedure in Step 3 fails, run the uninstall shield or uninstaller from the control panel, and choose the option during uninstall to keep the old database. Then install the new version. These procedures should find the information saved by the uninstall procedure and import it.
Step 5. If Step 4 fails, chances are very high that your Registry has been corrupted. If so, uninstall the CS ACS completely, and run the clean.exe files, which come in the CS ACS CD. These files will clean up the Registry. Then proceed with the installation. In the newer version (for instance, CS ACS 3.3), the Clean utility comes as setup.exe within the Clean directory, which is in the ACS Utilities\Support\ directory of the installation CD.
Step 6. If all the services started on the newer version, import the dump.txt that you have created in Step 2 with the csutil -d option, which contains only the user and group information. You still need to define the NASs. If there is a small number of NASs, this may work.
Step 7. If you have a large number of NASs, build another server with a version that runs the old version of code and import the database that is created in Step 2 with the csutil -b option, which includes the whole database that has the NAS information in it. Then follow Steps 26.
You should be aware of the following important facts if you are trying to upgrade one of the older CS ACS versions or from the trial version:
The minimum CS ACS version requirement to run on the Windows platform is CS ACS 2.5.
If you are upgrading CS ACS from 2.3 on a Windows NT platform to CS ACS 3.3 on the Windows 2000 platform, be sure to upgrade to CS ACS 2.6 on the NT platform first, and be sure the database upgraded and data migrated properly. As CS ACS 2.6 can run on Windows 2000, upgrade the OS of your CS ACS server to Windows 2000 after ensuring that the service packs and other prerequisites are fulfilled, and, finally, upgrade to the target version of CS ACS, which is CS ACS 3.3.
If you are running a trial version, to migrate that version to production, just upgrade or install the production CS ACS version on top of the trial version. For example, you can install the CS ACS 3.1 production version over the CS ACS 2.6 trial version, or install the CS ACS 3.3 production version over the CS ACS 3.3 trial version.
CS ACS installation or upgrade may fail for the following reasons:
Running an unsupported version of OS, service pack (SP), or browser.
CS ACS services are crashing.
If you are running a supported browser and service pack but CS ACS is still crashing, upgrade to the latest build of the CS ACS release that you are running. There may be a bug that has been fixed in the latest build of that release. If you are running the latest release, provide Cisco TAC with the package.cab file or, at least, run drwtsn32 in a DOS prompt, with the following box checked: Dump Symbol Table.
CS ACS with Active Directory Integration
To integrate with the Active Directory, Cisco Secure ACS can be installed in one of the following modes:
Standalone Server If CS ACS is installed on a standalone server, CS ACS can authenticate Windows users only against the local SAM database.
Domain Controller If CS ACS is installed on a Primary Domain Controller (PDC) or Backup Domain Controller (BDC), it will be able to authenticate Windows users who are defined in any trusted domain.
Member Server CS ACS on a member server will also authenticate users defined in any trusted domains. However, lack of permissions could cause issues with domain lists, authentication, and Remote Access Service (RAS) flag fetching.
Cisco Secure ACS services run under the local system account on the server. The local system account has almost the same privileges as the administrator.
When a new external WindowsNT/2000 database is defined on CS ACS, CS ACS fetches the list of domains trusted by the domain of the computer where the server is installed. CS ACS fetches the list of trusted domains only to populate it to Java control. The user can add domains manually as well. CS ACS uses the list of enumerated domains to determine the order in which they will be checked when an external authentication is presented.
When a new mapping between Windows NT/2000 user groups and Cisco Secure ACS user group is defined, CS ACS obtains and displays the list of the user groups defined in the selected Windows domain.
When a windows user is being authenticated, CS ACS uses Microsoft's Network Logon on behalf of the user to verify the user's credentials. This is a noninteractive login, as opposed to a desktop login.
CS ACS fetches the following information about that user:
List of user groups to which the user belongs.
Callback flag.
Values are set on the MS user definition page, which includes Admin set phone #, and user set (send by the client during authentication).
Dialin permission (RAS flag).
Password status.
Microsoft Point-to-Point Encryption (MPPE) keys (there are two, a 56-bit and 128-bit key).
Until CS ACS version 3.0, there were no "hooks" into the Security Accounts Manager (SAM) database to change the password through CS ACS. CS ACS 3.0 uses an API to change MS-CHAP passwords, but the MS-CHAPv2 protocol must be supported end-to-end.
Table 13-3 shows the trust relationship for CS ACS with the domain controller when the CS ACS is on the member server of Domain A.
Table 13-3. Trust Relationship of CS ACS and Windows Domain Controller When CS ACS Is on a Member Server of Domain A Task
Trust Direction
Description
Fetch list of domains trusted by Domain A.
A trusts other domains.
The list includes domains trusted by A.
Fetch list of user groups from a trusted Domain B.
B trusts A.
CS ACS reads information (accesses resources) on Domain B.
Authenticate a user with account on Domain B.
A trusts B.
CS ACS performs the network logon with user name. The user with an account on Domain B is going to access a computer in Domain A.
Fetch information (callback, and so on) on user with account on Domain B.
B trusts A.
CS ACS reads information (accesses resources) on Domain B.
Change password of a user with account on Domain B (CS ACS v3.0).
B trusts A.
CS ACS changes information (Access ressources) on Domain B.
Configuration Steps
The following steps are required to integrate CS ACS with the domain controller:
On the domain controller serving the CS ACS server follow these steps:
Step 1. Create a user.
Step 2. Make the user hard to hack by giving it a very long, complicated password.
Step 3. Make the user a member of the Domain Administrator group.
Step 4. Make the user a member of the Administrators group.
On the Windows 2000 server running CS ACS, follow these steps:
Step 1. Add a new user to the proper local group. Go to Start > Settings > Control Panel > Administrative Tools > Computer Management. Open Local Users and Groups and then Groups. Double-click the Administrators group. Click Add. Choose the domain from the Look in box. Double-click the user created earlier to add it. Click OK.
Step 2. Give the new user special rights on CS ACS server. Go to Start > Settings > Control Panel > Administrative Tools > Local Security Policy > Local Policies. Open User Rights Assignment. Double-click on Act as part of the operating system. Click Add. Choose the domain from the Look in box. Double-click the user created earlier to add it. Click OK. Double-click Log on as a service. Click Add. Choose the domain from the Look in box. Double-click the user created earlier to add it. Click OK.
Step 3. Set the CS ACS services to run as the created user. Open Start > Settings > Control Panel > Administrative Tools > Services. Double-click the CSADMIN entry. Click the Log On tab. Click This Account and then the Browse button. Choose the domain, and double-click the user created earlier. Click OK. Repeat for the remainder of the CS services.
Step 4. Wait for Windows to apply the security policy changes, or reboot the server. If you rebooted the server, skip the rest of these instructions. Otherwise, stop and then start the CSADMIN service. Open the CS ACS GUI. Click on System Config. Click on Service Control. Click Restart.
Note
If the Domain Security Policy is set to override settings for "Act as part of the operating system" and "Log on as a service" rights, the user rights changes listed in the previous steps also need to be made there.
Troubleshooting Steps
This section discusses some of the common issues that you may run into when integrating with Active Directory.
Windows Group to CS ACS Group Mapping Problems
During Configuring of Group mapping, the user sees a pop-up window. If you are having problems with Group mapping, you may see the following message:
Failed to enumerate Windows groups. If you are using AD consult the installation
guide for information
Possible causes of the problems are as follows:
CS ACS services do not have privileges to execute the NetGroupEnum function Refer to Configuration steps discussed for "CS ACS with Active Directory Integration" in the preceding section to correct the permission issue.
NetBIOS over Transmission Control Protocol (TCP) is not enabled NetBIOS over TCP must be enabled; otherwise, group mapping will fail.
Domain Name System (DNS) is not working correctly You may try to reregister DNS with commands: "ipconfig/flushdns" then "ipconfig/registerdns" at the DOS prompt.
Remote Procedure Call (RPC) is not working correctly (for example, after applying the blaster patch) In that case, consult with Microsoft.
Domain Controller (DCs) are not time-synchronized Run the command net time /Domain:
Different service packs If you run different SPs on different DCs, you may run into this problem. Apply the same patch to fix the problem.
NetLogon Services are not running NetLogon Services must up and running on all DCs.
Check that no firewall (FW) packet filters are installed If there is a packet-filtering firewall installed, be sure to select Yes on DNS properties to "allow dynamic updates".
CS ACS Maps User to Wrong Group of CS ACS (Default Group)
After successful user authentication based on the group mapping configuration, the user is mapped to a specific CS ACS group. The following list summarizes some of the reasons why the user may be mapped to the wrong CS ACS group:
Misconfiguration of group mapping If the user belongs to both group X and group Y, CS ACS assigns the user according to the order in which the user was configured.
Service accounts under which CS ACS services are running do not have permission to validate groups for another user Log in as user, under the CS ACS services that are running. Check if you have access to get the groups of another user.
CS ACS with Novell NDS Integration
This section works through the configuration steps that lead in turn to sections that cover troubleshooting steps.
Configuration Steps
Use the following steps to configure an NDS database with CS ACS on Windows.
Step 1. Consult with your Novell NetWare administrator to get administrator context information for CS ACS and the names of the Tree, Container, and Context details.
Step 2. On CS ACS, click on External User Databases > Database Configuration > Novell NDS > Configure.
Step 3. In the Novell NDS configuration window, enter a name for the configuration. This is for information purposes only.
Step 4. Enter the Tree name.
Step 5. Enter the full Context List, with items separated by dots(.). You can enter more than one context list. If you do, separate the lists with a comma and space. For example, if your Organization is Corporation, your Organization Name is Chicago, and you want to enter two Context names, Marketing and Engineering, you would enter: Engineering.Chicago.Corporation, Marketing.Chicago.Corporation. You do not need to add users in the Context List.
Step 6. Click Submit. Changes take effect immediately; you do not need to restart the Cisco Secure ACS.
Caution
If you click Delete, your NDS database is deleted.
Step 7. Then perform the Group Mappings (between the Novell NDS Database Groups and CS ACS Groups) by browsing to External User Databases > Database Group Mappings > Novell NDS.
Step 8. Finally, configure the unknown user policy by selecting Check the following external user databases and moving the Novell NDS database from the External Databases to the Selected Databases text box on the External User Databases > Unknown User Policy page.
Troubleshooting Steps
You can isolate any problem that you may have with the troubleshooting steps in the sections that follow.
Novell Client Is Not Installed
You must install the Novell client on the CS ACS server, so that CS ACS can talk to the Novell NDS database. If you do not have the Novell client installed on the CS ACS, and you try to configure Novell NDS database settings from the External User Database > Database Configuration > Novel NDS, you will receive an error message similar to the following:
An error has occurred while processing the External Database Configuration Page
because of an internal error..
Revise the Configuration on CS ACS
Most of the time, the Novell NDS authentication failure is caused by misconfiguration. Therefore, check to see if the tree name, context, and container name are all specified correctly. Start with one container in which users are present; later more containers can be added if needed.
Check Admin Username
Check the admin username to be sure it is correct, and that you have defined a fully qualified path. For example, instead of admin, define admin.cisco, as the latter is a fully qualified name.
Example 13-1 shows the incorrect provision of admin credentials.
Example 13-1. Incorrect Admin Credentials
AUTH 03/22/2005 10:40:21 I 0360 0676 External DB [NDSAuth.dll]: Tree 224462640 could
not log in with admin credentials supplied
Perform Group Mapping
Performing Group Mapping is an excellent test to ensure the admin context can connect and pull the group information from the Novell NDS database. Therefore, if you are unable to map groups, the admin user does not have permission to list the groups. Under that circumstance, check that the admin can list users in the other domain. One way to verify that is as follows: on the CS ACS Server, using Nwadmin, examine the groups from the other domain. If you cannot do so, consult with the Novell administrator.
Authentication Failure with a Bad Password
Before looking at authentication that has failed either due to the wrong username or a bad password, it's extremely important to understand and be familiar with the sequence of events that occur within CS ACS with Novell NDS authentication. Therefore, closely observe the successful user authentication log shown in Example 13-2.
Example 13-2. Successful User Authentication Against NDS Database
AUTH 03/22/2005 12:20:56 I 5081 1764 Start RQ1026, client 2 (127.0.0.1)
! As the user doesn't exist on the local database, CS ACS is tagging this as unknown user
AUTH 03/22/2005 12:20:56 I 4683 1764 Attempting authentication for Unknown User
'cisco'
! The following two lines indicate that Novell NDS is configured to this user
! authentication. This is being done by selecting Novell NDS database for Unknown User
! Policy
AUTH 03/22/2005 12:20:56 I 1280 1764 ReadSupplierRegistry: Novell NDS loaded
AUTH 03/22/2005 12:20:56 I 0863 1764 pvAuthenticateUser: authenticate 'cisco'
against Novell NDS
! Following lines indicate that CS ACS is trying to lock a thread for this user
! Authentication.
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: User cisco waiting
for lock
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: User cisco waiting
in lock
! A new thread is getting initialized here for the user authentication under ndstest
tree
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: Initializing thread
0 for tree ndstest
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Starting Thread 0
! The following two lines indicate that the user authentication is under works
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Waiting for work
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Got work
! This is where the user is authenticated.
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Authenticated
cisco.OU=SJ.TESTING.LAB, Response 0
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: Back from Wait for
user cisco with code 0
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: Response 0 from
successful Tree ndstest
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Response 0 from Tree
ndstest
AUTH 03/22/2005 12:20:56 I 0360 0472 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Waiting for work
! Following three lines indicates that the group mappings between Novell NDS and CS ACS
! are successful. Third line in particular indicates that user is mapped to CS ACS Group
! number 150.
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: Added
'sj_acs.SJ.testing.LAB' to Group List for user: cisco.OU=SJ.TESTING.LAB
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: There were 1 Groups
for this user: cisco.OU=SJ.TESTING.LAB
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: User cisco
authenticated into group 150
AUTH 03/22/2005 12:20:56 I 0360 1764 External DB [NDSAuth.dll]: User cisco out from lock
AUTH 03/22/2005 12:20:56 I 3421 1764 User cisco password type changed
AUTH 03/22/2005 12:20:56 I 1586 1764 User cisco feature flags changed
AUTH 03/22/2005 12:20:56 I 1586 1764 User cisco feature flags changed
AUTH 03/22/2005 12:20:56 I 5081 1764 Done RQ1026, client 2, status 0
As mentioned before, it is extremely important to understand the sequence of events that occur with a successful user authentication as shown in Example 13-2, before you can analyze and find the cause of failure for a bad user password. With the knowledge gained from Example 13-2, examine example 13-3, which shows failed authentication due to a bad password.
Example 13-3. Shows a Failed Authentication Attempt Due to Bad Password to NDS Database
AUTH 08/13/2003 14:11:47 I 0276 2212 External DB [NDSAuth.dll]: User cisco waiting
for lock
AUTH 08/13/2003 14:11:47 I 0276 2212 External DB [NDSAuth.dll]: User cisco waiting
in lock
AUTH 08/13/2003 14:11:47 I 0276 2212 External DB [NDSAuth.dll]: Initializing thread
0 for tree ndstest
AUTH 08/13/2003 14:11:47 I 0276 1968 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Got work
AUTH 08/13/2003 14:11:50 I 0276 1968 External DB [NDSAuth.dll]: Response 1 from Tree
ndstest
AUTH 08/13/2003 14:11:50 I 0276 1968 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Waiting for work
! In the following line, code 102 indicates that authentication fails due to bad
username
! or wrong password.
AUTH 08/13/2003 14:11:53 I 0276 2212 External DB [NDSAuth.dll]: Back from Wait for
user cisco with code 102
! Then eventually it times out trying.
AUTH 08/13/2003 14:11:53 I 0276 2212 External DB [NDSAuth.dll]: Timeout trying User
cisco
AUTH 08/13/2003 14:11:53 I 0276 2212 External DB [NDSAuth.dll]: User cisco out from
lock
Authentication Failure When the User Does Not Exist
If the user does not exist on the Novell NDS database or the user enters the wrong username, the authentication will fail, giving the same error code as a bad password (error code 102). Example 13-4 shows the output when the user does not exist on the database.
Example 13-4. Failed Authentication Due to Unknown User
AUTH 08/13/2003 14:13:24 I 0276 2212 External DB [NDSAuth.dll]: User cisco123
waiting for lock
AUTH 08/13/2003 14:13:24 I 0276 2212 External DB [NDSAuth.dll]: User cisco123
waiting in lock
AUTH 08/13/2003 14:13:24 I 0276 2212 External DB [NDSAuth.dll]: Initializing thread
0 for tree ndstest
AUTH 08/13/2003 14:13:24 I 0276 1968 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Got work
AUTH 08/13/2003 14:13:24 I 0276 1968 External DB [NDSAuth.dll]: Response 1 from Tree
ndstest
AUTH 08/13/2003 14:13:24 I 0276 1968 External DB [NDSAuth.dll]: Thread 0 for tree
ndstest Waiting for work
AUTH 08/13/2003 14:13:26 I 5094 2220 Worker 3 processing message 275.
AUTH 08/13/2003 14:13:26 I 5081 2220 Start RQ1012, client 27 (127.0.0.1)
AUTH 08/13/2003 14:13:26 I 5081 2220 Done RQ1012, client 27, status 0
AUTH 08/13/2003 14:13:26 I 5094 2220 Worker 3 processing message 276.
AUTH 08/13/2003 14:13:26 I 5081 2220 Start RQ1031, client 27 (127.0.0.1)
AUTH 08/13/2003 14:13:26 I 5081 2220 Done RQ1031, client 27, status 0
! In the following line, the code 102 is an indication that user authentication failed
! either due to bad username or wrong password.
AUTH 08/13/2003 14:13:30 I 0276 2212 External DB [NDSAuth.dll]: Back from Wait for
user cisco123 with code 102
! Eventually will timeout
AUTH 08/13/2003 14:13:30 I 0276 2212 External DB [NDSAuth.dll]: Timeout trying User
cisco123
AUTH 08/13/2003 14:13:30 I 0276 2212 External DB [NDSAuth.dll]: User cisco123 out
from lock
AUTH 08/13/2003 14:13:30 I 0276 2212 External DB [NTAuthenDLL.dll]: Starting
authentication for user [cisco123]
! Following lines indicate that NT/2K domain is also configured next in order, so
! attempting authentication to NT/2K domain as well and eventually fails.
AUTH 08/13/2003 14:13:30 I 0276 2212 External DB [NTAuthenDLL.dll]: Attempting NT/
2000 authentication
AUTH 08/13/2003 14:13:30 E 0276 2212 External DB [NTAuthenDLL.dll]: NT/2000
authentication FAILED (error 1326L)
AUTH 08/13/2003 14:13:30 I 1547 2212 Unknown User 'cisco123' was not authenticated
Wrong Group Mapping
After successful user authentication, the user is mapped to a specific CS ACS group. Two things determine which CS ACS group the user is mapped to: the Novell NDS group or groups the user belongs to, and the CS ACS group mapping configuration under the External Database Configuration page. If there are problems with proper group assignment by CS ACS after successful Novell NDS user authentication, analyze the auth.log file to find out which NDS database groups a specific user belongs to, and if the same group or groups are mapped to the desired CS ACS group. Examine the following example. Assume that the user belongs to all the following groups and maps to the CS ACS Group 10:
superuser.xyz
http_only.xyz
http_ftp.xyz
http_netmeeting.xyz
Analyze the log as shown in Example 13-5.
Example 13-5. Sample Output: User Saad Belongs to Multiple Groups That Do Not Match with the Group Mapped to CS ACS
AUTH 10/13/2004 10:20:49 I 0259 1340 External DB [NDSAuth.dll]: Initializing
thread 0 for tree XYZ
AUTH 10/13/2004 10:20:49 I 0259 0676 External DB [NDSAuth.dll]: Thread 0 for
tree XYZ Got work
AUTH 10/13/2004 10:20:52 A 0259 0676 External DB [NDSAuth.dll]: Login
Attempt: Context 'MKT.DH.XYZ' User 'saad.MKT.DH.XYZ'
Password 'saad' result 0
AUTH 10/13/2004 10:20:52 I 0259 0676 External DB [NDSAuth.dll]:
Authenticated saad.MKT.DH.XYZ, Response 0
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: Back from
Wait for user saad with code 0
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: Response 0
from successful Tree XYZ
AUTH 10/13/2004 10:20:52 I 0259 0676 External DB [NDSAuth.dll]: Response 0
from Tree XYZ
AUTH 10/13/2004 10:20:52 I 0259 0676 External DB [NDSAuth.dll]: Thread 0 for
tree XYZ Waiting for work
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: Added
'Everyone.MKT.DH.XYZ' to Group List for user:
saad.MKT.DH.XYZ
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: Added
'http netmeeting.XYZ' to Group List for user:
saad.MKT.DH.XYZ
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: There were 2
Groups for this user: saad.MKT.DH.XYZ
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: User saad
authenticated into group 0
So, from Example 13-5, you see that user saad belongs to NDS groups "Everyone.MKT.DH.XYZ" and "http_netmeeting.XYZ". Thus, the user does not meet the requirements to be mapped to group 10 on CS ACS, as both of the groups are not mapped on the CS ACS to group 10. As any unmatched group defaults to the CS ACS Default Group, saad is mapped to Group 0. So, the user must belong to all the NDS groups in the mapping, to be mapped into the configured CS ACS group, not just one.
On CS ACS to map this user into group 10, you need a map, which has one of the following combinations of NDS groups:
Everyone.MKT.DH.XYZ
http_netmeeting.XYZ
Everyone.MKT.DH.XYZ' and 'AAA_http netmeeting.XYZ'
It does not matter if a user also belongs in other NDS groups, in addition to those listed in the mapping, but the user must belong in all the NDS groups listed in a mapping to be mapped to a proper CS ACS group.
CS ACS with ACE Server (Secure ID [SDI]) Integration
Cisco Secure ACS can integrate with a few token servers, but this chapter discusses only the ACE server. The ACE server is also known as the SDI server, so both names will be used interchangeably throughout this chapter. Because the implementation of other token servers is very similar to the implementation of the ACE server, the discussion of ACS integration with ACE is applicable for the other token servers as well. The SDI server can be installed on the same machine on which Cisco Secure ACS is running, or on a separate machine. ACE client software is required on the system running Cisco Secure ACS software.
Installation and Configuration Steps
Use the following steps to install and configure CS ACS with SDI Software
Step 1. Install the ACE server as per ACE direction.
Step 2. Bring the ACE server into host configuration mode (run sdadmin).
Step 3. Be sure you have configured the hostname/ip-address of Cisco Secure ACS system as a client in the ACE server setup. This can be verified under Client > Edit Client from ACE Server Host configuration window. For CS ACS Windows client, encryption should be Data Encryption Standard (DES), because the client is Windows, and you have to choose Net OS Client. When you click the User Activations tab, you must see the SDI user under Directly Activated Lists.
Step 4. Be sure the user is activated on the clientthe client is the system on which Cisco Secure ACS is installed. This can be verified under Users > Edit Users > Client Activations. In this window you will see a list of available clients. Choose the right one and move them under Clients Directly Activated On.
Step 5. Be sure the CS ACS client and the SDI server can perform forward and reverse lookups of each other (that is, ping by name or IP).
Step 6. Copy the SDI server's sdconf.rec to the CS ACS client; this can reside anywhere on the CS ACS client.
Step 7. The installation of the ACE client on Windows may differ slightly by version. Run agent.exe to initiate the installation process of the ACE client. During installation, when asked to install Network Access Protection Software, answer No, and leave the root certificate box blank. Then go to Next. When prompted, specify the path to the sdconf.rec file, including the file name.
Step 8. After the client installation and reboot, go to Windows Control Panel > SDI Agent > Test Authentication with Ace Server > Ace/Server Test Directly and enter the username, code, and card configured on the Ace server to perform an authentication test and check the communication between the SDI client and the server. If this test does not work, it means the SDI client is not communicating with the SDI server. It also means the CS ACS Windows will not be able to communicate with the SDI Server. This is because CS ACS uses an SDI client interface to communicate with the SDI server.
Step 9. Then install CS ACS on Windows as usual.
Step 10. From Navigation, go to External User Databases > Database Configurations > Configure. ACS should be able to find the SDI Dynamic Linked Library (DLL).
Step 11. Go back to External User Databases. Click on Unknown User Policy and check the second radio button. Then move the SDI database from External Databases to Selected databases.
Step 12. Go back to External User Databases and click on Database Group Mapping > SDI Database > Cisco Secure ACS group to pick the group that will be mapped to SDI group.
Step 13. Go to Group setup and edit the settings for the group that was mapped to SDI. In this case, it is Default Group. Add appropriate attributes for TACACS+ & RADIUS depending on what kind of service the user will use (either Shell or PPP).
Troubleshooting Steps
Use the following step-by-step procedures to troubleshoot the SDI issues with CS ACS:
Step 1. First, authenticate the user with the ACE test agent.
Step 2. If this works, confirm that the card is synchronized with the database. Be sure to use DES encryption on the SDI server when the card is initialized. Choosing SDI will not work.
Step 3. If this does not work, resynchronize from the Token menu in host configuration mode. Click on Token > Edit Token, and then choose the token that you want to resynchronize. You will have a menu to resynchronize.
Step 4. Next, bring up the activity monitor (Report > Log Monitor > Activity Monitor) on the ACE server while attempting Telnet authentication to a device.
Step 5. Then check to see if there are any errors on the activity monitor on the ACE server.
Step 6. If the ACE server works, but there is a problem with the dial users, check the settings on the network access servers (NASs) to be sure that Password Authentication Protocol (PAP) is configured. Then try connecting as a non-SDI user.
Step 7. If that works, connecting as an SDI user should work. Put the username in the username tab and the passcode in the password tab on Dial-up Networking.
Step 8. If the client from where you are dialing is configured to bring up the post terminal screen after dialing, then be sure the following AAA statement is on the NAS:
aaa authentication ppp default if-needed tacacs+/Radius
The key is to use >if-needed>. This means that if the user is already authenticated by the following AAA statement:
aaa authentication login default tacacs+/radius
then you do not have to authenticate the user again when doing PPP. This also applies when using the normal PAP password.
Here are some common problems that you might face with SDI and CS ACS integration:
The ACE log displays the message "Passcode accepted", but the user still fails Check the CS ACS Failed Attempts log to determine the cause of the problem. The failure could be due to authorization issues.
The ACE log displays the message "Access Denied, passcode incorrect" This is an ACE problem with the passcode. During this time, the CS ACS Failed Attempts log shows either the message External DB auth failed or External DB user invalid or bad password.
The ACE log displays the message "User not in database" Check the ACE database. During this time, the CS ACS Failed Attempts log shows either the message External DB auth failed or External DB user invalid or bad password.
The ACE log displays the message "User not on agent host" This is an ACE configuration problem. To solve this problem, configure the user on the agent host.
The CS ACS log displays the message "External database not operational" If the ACE log does not show any attempts, confirm the operation with the ACE client test authentication and check to be sure that the ACE/server authentication engine is running.
The CS ACS log displays the message "CS user unknown" or "Cached token rejected/expired" with nothing in the ACE log If the network device is sending a Challenge Handshake Authentication Protocol (CHAP) request and the CS ACS does not have an enumerated ACE user with a separate CHAP password, CS ACS does not send the user to ACE because token-only authentication requires PAP.
Replication Issues
Replication allows the CS ACS Server to maintain distributed databases. This helps the NAS to improve fault tolerance (by providing a backup server) or to improve performance (by sharing throughput across several servers). Replication can be configured as a straightforward master-to-slave relationship, or as a pipeline, or even as a tree in which each slave automatically replicates to its children upon receipt of replicated data from its parent.
Configuration
Replication is configured by the GUI. The GUI is used on both the master and slave to configure both ends of the replication.
The following are the steps required for replication on the master (IP Address 10.1.1.1) and the slave (IP address 30.1.1.1). Use the following steps to configure the master CS ACS:
Step 1. Log in to the primary CS ACS server GUI.
Step 2. Turn on Distributed System Settings and enable Cisco Secure Database Replication optionsfound under Interface Configuration->Advanced Options.
Step 3. In the Network Configuration section, add each secondary server to the AAA Servers table as shown in Figure 13-5. The Traffic Type should be left defaulting to inbound/outbound unless there is a good reason to do otherwise.
Figure 13-5. Slave CS ACS Server Entry Configuration on the Primary CS ACS Server
[View full size image]
Step 4. In the navigation bar, click System Configuration. Then click Cisco Secure Database Replication, which brings up the Database Replication Setup page.
Step 5. Select the Send check box for each database component to send to the secondary server as shown in Figure 13-6.
Figure 13-6. Replication Component Configuration on the Master CS ACS
[View full size image]
Step 6. Select a scheduling option from one of the four options: Manually, Automatically Triggered Cascade, Every X Minutes, or At Specific times. To set up Auto Replication, you must not select manually, and the Scheduling Option must be set up on Master, not on the slave.
Step 7. Under the Replication Partners, add the secondary CS ACS server to the Replication Partner column as shown in Figure 13-7.
Figure 13-7. Replication Partner Configuration on Master
[View full size image]
Step 8. Click Submit. Note that Accept Replication from does not have any meaning on the master.
Use the following steps to configure steps required the slave CS ACS server:
Step 1. Follow the preceding Steps 1-4, which were outlined for the master server.
Step 2. Click the Receive check box for each database component to be received from a primary server as shown in Figure 13-8.
Figure 13-8. Replication Components Configuration on the Slave
[View full size image]
Step 3. Leave the Scheduling Option set to Manually.
Step 4. Do not add the primary server to the Replication Partner column, under the Replication Partners; the replication partner column should be blank as shown in Figure 13-9.
Figure 13-9. Replication Partners Configuration on the Slave
[View full size image]
Step 5. From the Accept Replication From drop-down list, select Master Server. If you have more than one Master server, select Any Known Cisco Secure ACS for Windows 2000/NT Server.
Step 6. Click Submit.
Troubleshooting Steps
Before getting into the details of some of the common problems that you might face with replication, it is useful to examine the internal workings of replication.
On the master, a dedicated thread within the CSAuth service continually monitors the time and controls the outbound replication when due. The following actions are performed:
1. Lockout and wait for any open transactions to complete (authentication's and admin's updates).
2. Dump the required registry keys and copy/compress required files to a temporary location.
3. Release lockouts, allowing normal service to resume.
For each child replication partner, CSAuth then performs the following tasks:
1. Connects to remote CSAuth server.
2. Exchanges version and component specifications.
3. Copies permitted files onto remote AAA server.
4. Initiates replication take-up on the remote AAA server. This request also specifies where the files are located on the remote AAA server.
On the slave, the CSAuth service performs the following task:
1. Opens a connection as per any client request.
2. Responds to the master's request for version and replication information checks by verifying that the two servers are running the same software version. The master will have sent a list of components it is allowed to send. The slave then removes any components it is not allowed to receive. The resultant list is returned to the master.
3. Performs remote file copy operations as the master transmits the replication set.
When the slave receives the replication take-up command from the master, it performs the following:
1. Lockout and wait for any open transactions to complete (authentications and administrator updates).
2. Load the required Registry keys. Uncompress and save required files from the temporary location.
3. Release lockouts, allowing normal service to resume.
4. Restart any services as configured in the Registry (default CSRadius and CSTacacs).
5. Kick the replication thread so that if so configured, "cascade" replication occurs.
To view the actions performed by the CSAuth service for replication as described in the previous steps, analyze the auth.log file. The replication CSV file gives a summary version of the status of replication. Therefore, to troubleshoot the replication issues, first look at the CSV file, which is under Reports & Activity, or in the logs directory of the CS ACS installation. If the problem cannot be resolved with the CSV file, you can analyze the auth.log (...\csauth\logs\auth.log), which shows details of failure (be sure to turn logging to FULL).
To see only the replication log on auth.log file, search for string "dbreplicate(out)" on the master and "dbreplicate(in)" on the slave server. Example 13-6 shows the output of auth.log file on the Master Server.
Example 13-6. Replication Only Log on the Master Server
DBReplicate(OUT) attempting to exchange sync info with host acs1
DBReplicate(OUT) attempting to tx files to host acs1
DBReplicate(OUT) - one or more files could not be sent to acs1
DBReplicate(OUT) to host acs1 was denied
Etc.
The following are some of the issues that you might encounter, and their resolutions.
Compatible version numbers Both ends of a replication must be running the same version. However, they may be running different builds of the same version, that is, 2.3(1.24) and 2.3(1.29). This has caused a few problems in clients replicating from 2.3 betas to 2.3 FCS systems due a change in Registry encryption. This might be rectified in the future but is worth bearing in mind.
Master being rejected by the slave The slave AAA server may reject connection attempts from the master due to the master PC having several network adapter cards. This is because the slave can see the IP address of the wrong card, that is, it does not see the one configured in its network configuration. Either the second card can be removed, or another dummy AAA server (with the second IP address) can be added.
Secret value/shared key problems Both AAA servers must share the same secret key.
Proxy entries on slave overwritten If you use replication to update several distributed masters, each with its own proxy distribution table, you might see that the slave will keep on losing its proxy table. This is a misconfiguration, and can be resolved by unchecking the component Distribution Table on the tx/rx list.
Replication timeout After issuing the replication take-up request, the master waits up to 5 minutes before assuming that the slave died and reporting it as such. Should the slave be configured so that it uses RDBMS synchronization, it is possible that a large number of transactions could block the slave from accepting the replication before the master gives up. Try to avoid this type of setting.
Master CS ACS entry is missing on the slave server In the auth.log file of the secondary server, you may see the following message:
Worker 2 message from unknown host x.x.x.x - closing conn 41
So, on the slave, configure the master CS ACS entry.
CS ACS's own server entry is missing from the server list When CS ACS is installed, its own entry is created as an AAA server. If you remove that, you may run into problems with the CS ACS replication, and the auth.log could display the following message:
"ERROR Inbound database replication aborted - check IP address for this AAA
Server"
This appears when the AAA server's list does not contain the CS ACS machine itself. You need to investigate further the Registry of both master and slave. After checking the Registry of both master and slave, you might find that the slave machine on the AAA Servers list has only the master configured and does not have its own definition. On the slave CS ACS, only MASTER (Master CS ACS) is configured as an AAA server (type=1) as shown in Example 13-7.
Example 13-7. Registry on the Slave Server
[HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAv3.1\Hosts\MASTER]
"key"=hex:36,2e,70,77,e6,24,01,37,73,59,da,d9,b3,61,1d,d9,de,47,79,e2,28,b4,cd,\
27,42,11,7d,a4,c9,6e,bd,85
"vendor"=dword:ffffffff
"protocol"=dword:00000063
"type"=dword:00000001
"direction"=dword:00000003
"acct Packet Filter"=dword:00000005
"network device group"=dword:00000006
"ip"=hex(7):31,00,37,00,32,00,2e,00,32,00,35,00,2e,00,35,00,37,00,2e,00,39,00,\
31,00,00,00,00,00
"lastModified"=hex:50,7c,26,f8,fb,0d,c3,01
On the master server, there are two AAA servers configured : MASTER(the Master itself) and SLAVE(the Slave CS ACS) as shown in Example 13-8.
Example 13-8. Registries of the CS ACS Servers
[HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAv3.1\Hosts\CPFACS01]
"key"=hex:eb,e5,07,d8,98,ad,fe,5b,f2,88,81,e8,83,1f,e0,00,36,d6,57,03,f7,fd,dc,\
5b,61,89,6a,a6,a8,78,b9,5b
"vendor"=dword:ffffffff
"protocol"=dword:00000063
"type"=dword:00000001
"direction"=dword:00000003
"acct Packet Filter"=dword:00000005
"network device group"=dword:00000000
"ip"=hex(7):31,00,37,00,32,00,2e,00,32,00,35,00,2e,00,35,00,37,00,2e,00,39,00,\
31,00,00,00,00,00
"lastModified"=hex:80,06,62,dd,e5,07,c3,01
[HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAv3.1\Hosts\HQACS02]
"key"=hex:58,a5,28,70,6e,50,f6,80,64,7c,fe,1f,70,c1,b1,bb,8d,d7,0f,1f,7a,11,ac,\
64,86,b3,4a,c9,a5,37,db,a4
"vendor"=dword:ffffffff
"protocol"=dword:00000063
"type"=dword:00000001
"direction"=dword:00000003
"acct Packet Filter"=dword:00000005
"network device group"=dword:00000006
"ip"=hex(7):31,00,37,00,32,00,2e,00,32,00,35,00,2e,00,35,00,37,00,2e,00,39,00,\
32,00,00,00,00,00
"lastModified"=hex:c0,be,de,ab,fb,0d,c3,01
Add a profile of the slave CS ACS to the slave CS ACS AAA Server's list to fix the problem.
Bi-directional replication between two CS ACS Servers Bi-directional replication is not supported. If you configure the bi-directional replication, you will see messages like the one in Example 13-9 in the auth.log file and the replication will fail. So avoid configuring bidirectional replication.
Example 13-9. Auth.log Output for Bidirectional Replication
03/22/2005 21:26:19 ERROR Inbound database replication from ACS
'dumb' denied
03/22/2005 21:36:36 INFO Outbound replication cycle starting...
03/22/2005 21:36:42 ERROR ACS 'dumb' has denied replication request
NAT or Firewall device between the replication partners If there is a Network Address Translation (NAT) or firewall device between the replication partners, you may see the following message on the auth.log
denied - shared secret mismatch
From CS ACS version 3.1 and above, the IP address is embedded in the data and used as part of the server verification process. Hence, if the NAT device changes the source IP of the server, replication no longer works. To get around the problem, you may want to configure the firewall or NAT device so that it keeps the same source IP address. In addition to taking care of the NAT issue, be sure to allow TCP/2000 for the communication to take place.
Replication is not working for some components A master CS ACS has a dirty flag for each replication component. If no data changes on the master between replication cycles, nothing is replicated. To see which components are being replicated, be sure that user.dat, user.idx, and varsdb.mdb are being transmitted. The users are listed in user.dat. The advanced settings for users and groups are in varsdb.mdb.
Slave server does not have enough space If you have a 10-MB database that needs to be replicated to a slave CS ACS, there must be enough space to hold the compressed file set, you need space in temp during de-compress, and you need space for uncompressed files. For a 10-MB database, 50-MB should be comfortable.
Network Access Restrictions (NARs) Issues
Network Access Restrictions (NARs) allow you to define additional authorization conditions that must be met before a user can gain access to the network. Even though it is an authorization condition, NAR is indeed an authentication process.
Cisco Secure ACS supports two basic types of network access restrictions:
IP-based restrictions in which the originating request relates to an existing IP address
Non-IP-based filters for all other cases in which the automatic number identification (ANI) may be used
A non-IP-based NAR is a list of permitted or denied "calling"/"point of access" locations that you can employ in restricting an AAA client when you do not have an IP-based connection established. The non-IP-based NAR generally uses the calling line ID (CLI) number and the Dialed Number Identification Service (DNIS) number.
Configuration Steps
To illustrate the functionality of NAR, consider the following example. Table 13-4 shows how users belonging to a default group can connect via Router1. Users in Group1 can connect only via AP11 and Group2 users get access via Router2 and AP11.
Table 13-4. Configuration Metric Group
User
Router1
Router2
AP11
Default
Laci
Pass
Fail
Fail
Group1
Magi
Fail
Fail
Pass
Group2
Torri
Fail
Pass
Pass
This can be accomplished in several ways: using per "User defined Network Access Restriction" and using "Shared Profile Component for NAR", whereas all NAR is applied on Group-Settings.
The following are the configuration steps for NAR:
Step 1. Define Router1, Router2, and AP11 as AAA client under AAA client, if not defined already.
Step 2. Define users listed in Table 13-4 and map them to corresponding groups.
Step 3. Go to each group's settings and under Access Restrictions, define the parameters as shown in Figure 13-10 for all three devices such as Default Group, which allows only Router1.
Figure 13-10. NAR Configuration for Group
[View full size image]
Step 4. If Shared Profile components is the component that is used instead, then from Navigation, click on Shared Profile Component, and define three NARs: NAR-AP, NAR-router1, and NAR-router2 in a manner similar to that shown in Figure 13-11 for Router1. The name of the NAR is NAR-router1.
Figure 13-11. Shared Profile Component for NAR
[View full size image]
Step 5. Now apply the NAR defined in Step 4 on all three groups under network access restrictions in a manner similar to that shown in Figure 13-12, which is configured for Default Group.
Figure 13-12. NAR Applied on Default Group
[View full size image]
Note
This setup can also be extended to use Network Device Groups (NDG). Configuration steps are exactly the same, but instead of selecting NAS, select NDG.
Troubleshooting Steps
The best way to troubleshoot the NAR issues is to use Failed Attempts or Passed Authentications reports to understand why access was or was not granted to a certain user. Usually, the caller ID, network access server (NAS) port, and NAS IP address fields are available and can be used to debug the session. When the reason for acceptance or denial is unclear, you can add the Filter Information field to these reports (both to Failed Attempts and Passed Authentications). This field will provide additional data. However, remember that you must use the Shared Profile Component (SPC) NARs configuration to get this additional information. With traditional NARs, it is hard to find the cause of acceptance or denial, as the first message (No Filter Activated) always appears regardless of the results. For additional details, look at the RDS.log or TCS.log and see how the packet is coming to the CS ACS Server from NAS and if it is getting forwarded to the CSAuth service, which shows the information on auth.log.
Example 13-10 shows the auth.log file for successful authentication.
Example 13-10. Snippet of auth.log File Shows NAR Passing
03/22/2005,18:41:21,Authen OK,laci,Default Group,10.0.0.2,66,10.0.0.171,,,,,,All
Access Filters Passed.,,router1,,,No,laci,cisco,,,
03/22/2005,18:42:08,Authen OK,torri,Group 2,10.0.0.2,66,10.0.0.172,,,,,,Access
Filter NAR-router2 from Group 2 permitted on Filter Line: 'router2 (Port=*) (IP=*)'.
This is sufficient to satisfy an 'Any Selected' SPC NAR
config.,,router2,,,No,torri,cisco,,,
03/22/2005,18:42:59,Authen OK,magi,Group 1,0040.9638.8e9a,99,10.0.0.1,,,,,,All
Access Filters Passed.,,ap11,,,No,magi,cisco,,,
03/22/2005,18:43:10,Authen OK,torri,Group 2,0040.9638.8e9a,99,10.0.0.1,,,,,,Access
Filter NAR-AP from Group 2 permitted on Filter Line: 'ap11 (Port=*) (CLI=*)
(DNIS=*)'. This is sufficient to satisfy an 'Any Selected' SPC NAR
config.,,ap11,,,No,torri,cisco,,,
Example 13-11 shows the auth.log file for unsuccessful authentication.
Example 13-11. Snippet of auth.log File Shows NAR Failing
03/22/2005,18:41:39,Authen failed,magi,Group 1,10.0.0.2,User Access
Filtered,,,66,10.0.0.171,Access Filter NAR-AP from Group 1 denied on Filter Line:
'* (Port=*) (IP=*)'. This is sufficient to reject an 'All Selected' SPC NAR
config.,,,,,,,router1,,,,No,magi,cisco,,,
03/22/2005,18:41:44,Authen failed,torri,Group 2,10.0.0.2,User Access
Filtered,,,66,10.0.0.171,No Access Filters
Passed.,,,,,,,router1,,,,No,torri,cisco,,,
03/22/2005,18:41:57,Authen failed,laci,Default Group,10.0.0.2,User Access
Filtered,,,66,10.0.0.172,Access Filter NAR-router1 from Default Group Did not permit
any criteria. This is sufficient to reject an
'All Selected' SPC NAR config.,,,,,,,router2,,,,No,laci,cisco,,,
03/22/2005,18:42:03,Authen failed,magi,Group 1,10.0.0.2,User Access
Filtered,,,66,10.0.0.172,Access Filter NAR-AP from Group 1 denied on Filter Line:
'* (Port=*) (IP=*)'. This is sufficient to reject an 'All Selected' SPC NAR
config.,,,,,,,router2,,,,No,magi,cisco,,,
03/22/2005,18:42:45,Authen failed,laci,Default Group,0040.9638.8e9a,User Access
Filtered,,,97,10.0.0.1,Access Filter NAR-router1 from Default Group denied on Filter
Line: '* (Port=*) (CLI=*) (DNIS=*)'. This is sufficient to reject an 'All Selected'
SPC NAR config.,,,,,,,ap11,,,,No,laci,cisco,,,
The following link contains some interesting and useful discussion about NAR and how to troubleshoot it efficiently:
http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_white_paper09186a00801a8fd0.shtml
Downloadable ACL Issues
You can download ACL from the CS ACS Server to NAS to control which resources the user can access after getting access to the network. There are three ways to configure this, as described in the sections that follow.
Downloading ACL per User Basis Using Filter-id
With this option, you need to define the ACL in the NAS, and on the CS ACS server, and you need to define the name of the ACL using the Internet Engineering Task Force (IETF) RADIUS attribute 11 as shown in Figure 13-13.
Figure 13-13. ACL Named Defined with IETF Radius Attribute
[View full size image]
Using Cisco AV-Pair
On the NAS, you must have authorization turned on; otherwise, the AV pair will not be applied on the NAS. On CS ACS, you need to configure this under Group Profile. Click on Group Setup > Select a Group from drop-down, and then click on Edit Settings. In the Group Setup page, select Cisco IOS/PIX RADIUS from the Jump To drop-down. Then check "[009\001] cisco-av-pair" box, and define your ACL in the rectangle text box underneath as shown in Figure 13-14.
Figure 13-14. ACL Defined Using Cisco AV Pair
[View full size image]
Note
The variable x (ip:inacl#
Using Shared Profile Components
If you are running CS ACS 3.0 and 3.1, under the Shared Profile component, the only option available to download ACL is for the PIX Firewall, which is called "Downloadable PIX ACL." From CS ACS version 3.2 and above, "Downloadable IP ACL" is available under "Shared Profile Components", which is supported by PIX firewall, VPN Concentrator 4.0 code and above, and IOS version 12.3T and above.
The following sequence of events occurs if ACLs via Shared Profile Components are used:
1. The first stage is to download the name and version of the ACL where the device validates it against the local ACL cache.
2. In the second stage, the device (if needed) requests the ACL content, where CS ACS uses inacl for downloading the ACL.
The following step-by-step example shows the user fred when the Shared Profile component ACL is configured.
Step 1. Access a request from PIX (initial user authentication).
User-Name[1] = "fred"
User-Password[2] =
...
...
Step 2. Access an acceptance from CS ACS (authentication response and ACL set assignment).
AV-Pair[26/9/1] ="ACS:CiscoSecure-Defined-ACL=#ACSACL#-myAcl-
1e45bc4890fa12b2
...
...
Step 3. Access a request from PIX (initiation of ACL download).
User-Name = "#ACSACL#-myAcl-1e45bc4890fa12b2"
...
...
Step 4. Access a challenge from CS ACS (first ACL fragment returnedmore to follow).
State[24] = "TBD"
AV-Pair[26/9/1] = "ip:inacl#1 = permit tcp any anyestablished"
AV-Pair[26/9/1] = "ip:inacl#2 = permit ip any any"
...
...
AV-Pair[26/9/1] = "ip:inacl#60 = deny icmp 2.2.2.0 0.0.0.255
9.9.9.00.0.0.255"
Troubleshooting Steps
Most of the time, downloadable ACL issues arise from mis-configuration either on the NAS or on the CS ACS server. So, first you must always perform a sanity check on the configuration, if there is any issue with downloadable ACL. Analyze auth.log and RDS.log files to find out what information CS ACS is sending to the NAS as reply attributes for authorization. Then look at the debug information on the NAS to see if the NAS understands the ACL that CS ACS is sending. Keep the following points in mind when you configure downloadable ACL:
1. Perform a sanity check on the configuration both on the NAS and CS ACS server.
2. Be sure to have the authorization turned on for the NAS; otherwise, even though CS ACS sends the ACL name or the ACL itself, NAS will not install it. In the authorization debug, you will see that ACL is downloading from CS ACS, but when you execute show access-list command, you will not see the ACL being installed.
3. If using filter ID to download only the ACL name to NAS, be sure that ACL is defined locally on the NAS first. Then be sure that the name of the ACL matches on both CS ACS and the NAS. Note that name is case sensitive.
4. When an AV pair is used to download ACL, be sure to define the ACL entries with different numbers to maintain the order of ACL entries.