Home > Articles > Cisco Network Technology > General Networking > Troubleshooting Cisco Secure ACS on Windows

Troubleshooting Cisco Secure ACS on Windows

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jun 16, 2006.

Chapter Description

Cisco Secure Access Control Server, which is known as CS ACS, fills the server-side requirement of the Authentication, Authorization, and Accounting (AAA) client server equation. For many security administrators, the robust and powerful AAA engine, along with CS ACS's ability to flexibly integrate with a number of external user databases, makes the CS ACS software the first and sometimes only choice for an AAA server-side solution. This chapter explores CS ACS in detail and walks you through troubleshooting steps. The chapter focuses on the approach required to troubleshoot any issue efficiently, either with the CS ACS software itself or with the whole AAA process.

Categorization of Problem Areas

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.


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 2–6.

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


Trust Direction


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.

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: <DomainName> to synchronize time.
  • 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.

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 (
! 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 (
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 (
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:
AUTH 10/13/2004 10:20:52 I 0259 1340 External DB [NDSAuth.dll]: Added
’http netmeeting.XYZ’ to Group List for user:
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 client—the 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.


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 and the slave (IP address 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 options—found 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 5

Figure 13-5 Slave CS ACS Server Entry Configuration on the Primary CS ACS Server

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 6

Figure 13-6 Replication Component Configuration on the Master CS ACS

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 7

Figure 13-7 Replication Partner Configuration on Master

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.

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 8

Figure 13-8 Replication Components Configuration on the Slave

Figure 9

Figure 13-9 Replication Partners Configuration on the Slave

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

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

"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
"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

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

"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
"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

"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
"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

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





















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 10

Figure 13-10 NAR Configuration for Group

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.

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 11

Figure 13-11 Shared Profile Component for NAR

Figure 12

Figure 13-12 NAR Applied on Default Group

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,,66,,,,,,,All Access Filters Passed.,,router1,,,No,laci,cisco,,,
03/22/2005,18:42:08,Authen OK,torri,Group 2,,66,,,,,,,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,,,,,,,All Access Filters Passed.,,ap11,,,No,magi,cisco,,,
03/22/2005,18:43:10,Authen OK,torri,Group 2,0040.9638.8e9a,99,,,,,,,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,,User Access Filtered,,,66,,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,,User Access Filtered,,,66,,No Access Filters Passed.,,,,,,,router1,,,,No,torri,cisco,,,
03/22/2005,18:41:57,Authen failed,laci,Default Group,,User Access Filtered,,,66,,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,,User Access Filtered,,,66,,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,,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:


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

Figure 13-13 ACL Named Defined with IETF Radius Attribute

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 14

Figure 13-14 ACL Defined Using Cisco AV Pair

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] = <whatever> 
<Other attributes> 

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 
<Other attributes> 


Step 3

Access a request from PIX (initiation of ACL download).

User-Name = "#ACSACL#-myAcl-1e45bc4890fa12b2" 
<Other attributes> 


Step 4

Access a challenge from CS ACS (first ACL fragment returned—more 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" 
<ACLs 3..59> 

AV-Pair[26/9/1] = "ip:inacl#60 = deny icmp"

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.
4. Case Studies | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020