Administration Issues

Remote administrator cannot bring up the ACS web interface in a browser or receives a warning that access is not permitted.

To recover from this condition:

1. Verify that you are using a supported browser. Refer to the Release Notes for Cisco Secure Access Control Server for Windows for a list of supported browsers.

2. Ping ACS to confirm connectivity.

3. Verify that the remote administrator is using a valid administrator name and password that have previously been added in Administration Control.

4. Verify that Java functionality is enabled in the browser.

5. Determine whether the remote administrator is trying to administer ACS through a firewall, through a device performing Network Address Translation, or from a browser configured to use an HTTP proxy server.

No remote administrators can log in.

The Allow only listed IP addresses to connect option is selected, but no start or stop IP addresses are listed. Choose Administrator Control > Access Policy, and specify the Start IP Address and End IP Address.

Unauthorized users can log in.

The Reject listed IP addresses option is selected, but no start or stop IP addresses are listed. Choose Administrator Control > Access Policy, and specify the Start IP Address and Stop IP Address.

The Restart Services function does not work.

This malfunction might occur if the system is not responding. To manually restart services:

If the services do not respond when manually restarted, reboot the server.

Administrator configured for event notification is not receiving e-mail.

Ensure that the SMTP server name is correct. If the name is correct, ensure that the computer running ACS can ping the SMTP server or can send e-mail via a third-party e-mail software package. Ensure that you have not used underscores (_)in the e-mail address.

Remote administrator cannot bring up ACS from his or her browser, or receives a warning that access is not permitted.

If Network Address Translation is enabled on the PIX Firewall, administration through the firewall cannot work.

To administer ACS through a firewall, you must configure an HTTP port range. Choose Administrator Control > Access Policy. You must configure the PIX Firewall to permit HTTP traffic over all ports in the range specified in ACS. For more information, see Access Policy.

Browser Issues

Condition

Recovery Action

The browser cannot bring up the ACS web interface.

Open Internet Explorer or Netscape Navigator. Choose Help > About to determine the version of the browser. See Installation Guide for Cisco Secure ACS for Windows for a list of browsers that ACS supports, and the release notes for known issues with a particular browser version.

The browser displays the Java message that your session connection is lost.

Check the Session idle timeout value for remote administrators. This value appears on the Session Policy Setup page of the Administration Control section. Increase the value as needed.

Administrator database appears corrupted.

The remote Netscape client is caching the password. If you specify an incorrect password, it is cached. When you attempt to re-authenticate with the correct password, the incorrect password is sent. Clear the cache before attempting to re-authenticate, or close the browser and open a new session.

Ensure that the client browser does not have proxy server configured. ACS does not support HTTP proxy for remote administrative sessions. Disable proxy server settings.

Cisco NAC Issues

Condition

Recovery Action

The results of show eou all or show eou ip address include postures that do not match the actual result of posture validation or display "-------" instead of a posture.

If you see "-------", the AAA client is not receiving the posture-token attribute-value (AV) pair within a Cisco IOS/PIX RADIUS cisco-av-pair vendor-specific attribute (VSA). If the posture that appears does not correspond to the actual result of posture validation, the AAA client is receiving an incorrect value in the posture-token AV pair.

Check group mappings for Network Admission Control (NAC) databases to verify that the correct user groups are associated with each system posture token (SPT). In the user groups that are configured for use with NAC, ensure that the Cisco IOS/PIX cisco-av-pair VSA is configured correctly. For example, in a group configured to authorize NAC clients receiving a Healthy SPT, be sure the [009\001] cisco-av-pair check box is checked and that the following string appears in the [009\001] cisco-av-pair text box:

posture-token=Healthy

Caution The posture-token AV pair is the only way that ACS notifies the AAA client of the SPT that the posture validation returns. Because you manually configure the posture-token AV pair, errors in configuring posture-token can result in the incorrect SPT being sent to the AAA client; or, if the AV pair name is mistyped, the AAA client not receiving the SPT at all.

Under EXEC Commands, Cisco IOS commands are not being denied when checked.

Examine the Cisco IOS configuration at the AAA client. If it is not already present, add the following Cisco IOS command to the AAA client configuration:

aaa authorization command <0-15> default group TACACS+

The correct syntax for the arguments in the text box is permitargument or denyargument.

EAP request has invalid signature. Error message appears in log.

If ACS receives traffic from any EAP-enabled device that has the wrong shared secret, this error message appears in the log. Three conditions that might cause this to occur are:

•The wrong signature is being used.

•A RADIUS packet was corrupted in transit.

•ACS is being attacked.

Check the EAP-enabled device and make changes if necessary.

Administrator has been locked out of the AAA client because of an incorrect configuration setup in the AAA client.

If you have a fallback method configured on your AAA client, disable connectivity to the AAA server and log in using local or line username and password.

Try to connect directly to the AAA client at the console port. If that is not successful, consult your AAA client documentation or see the Password Recovery Procedures page on Cisco.com for information regarding your particular AAA client.

Check the failed attempts log in the ACS. If the log reads CS password invalid, it may be that the user has no enable password set up. Set the TACACS+ Enable Password in the Advanced TACACS+ Settings section.

If you do not see the Advanced TACACS+ Settings section among the user setup options, choose Interface Configuration > Advanced Configuration Options > Advanced TACACS+ Features and select that option to have the TACACS+ settings appear in the user settings. Then select Max privilege for any AAA Client (this will typically be 15) and enter the TACACS+ Enable Password that you want the user to have for enable.

NAC NRE/Guest Access Limit of 100 Endpoints.

A feature in the EAPoUDP state table that prevents denial of service (DoS) attacks on the ACS server by throttling RADIUS requests.

When the maximum limit of 100 unauthorized nonresponsive endpoints per NAD is reached, the following message appears on the router console:

This message appears because 100 (or more) EAPoUDP sessions are in the INIT state. Normally, upon receiving a RADIUS Accept-Accept from the ACS, the session will transition out of this state. However, the EAPoUDP session will stay in this state during any of the following situations. The:

•You should never have more than 100 unauthorized endpoints behind a single NAC-enabled router or they will prevent access for CTA-enabled endpoints.

•Set the default hold period to a low value.

A new command will be added to the IOS to allow this limit to be increased or decreased as needed for a given deployment.

Database Issues

Condition

Recovery Action

RDBMS Synchronization is not operating properly.

Make sure that the correct server appears in the Partners list.

Database Replication not operating properly.

•Make sure you have set the server correctly as Send or Receive.

•On the sending server, ensure that the receiving server is in the Replication list.

•On the receiving server, ensure that the sending server is selected in the Accept Replication from list. Also, ensure that the sending server is not in the replication partner list.

•Make sure that the replication schedule on the sending ACS is not conflicting with the replication schedule on the receiving ACS.

•If the receiving server has dual network cards, on the sending server add a AAA server to the AAA Servers table in the Network Configuration section for every IP address of the receiving server. If the sending server has dual network cards, on the receiving server add a AAA server to the AAA Servers table in Network Configuration for every IP address of the receiving server.

The external user database is not available in the Group Mapping section.

The external database has not been configured in the External User Databases section; or, the username and password have been typed incorrectly. Click the applicable external database to configure. Make sure that the username and password are correct.

Windows external databases not operating properly.

Make sure that a two-way trust (for dial-in check) has been established between the ACS domain and the other domains.

If ACS is installed on a Member Server and is authenticating to a Domain Controller, see the "Authentication Failures When ACS/NT 4.0 Is Authenticating to Active Directory" Field Notice at the following URL:

A record of a failed attempt appears in the Failed Attempts Report (in the Reports & Activity section, click Failed Attempts).

Create a local user in the ACS internal database and test whether authentication is successful. If it is successful, the issue is that the user information is not correctly configured for authentication in Windows or ACS.

From the Windows User Manager or Active Directory Users and Computers, confirm that the:

•Username and password are configured in the Windows User Manager or Active Directory Users and Computers.

•User can log in to the domain by authenticating through a workstation.

•User Properties window does not have User Must Change Password at Login enabled.

•User Properties window does not have Account Disabled selected.

•User Properties for the dial-in window does not have Grant dial-in permission to user disabled, if ACS is using this option for authenticating.

From within ACS confirm that:

•If the username has already been entered into ACS, a Windows user database configuration is selected in the Password Authentication list on the User Setup page for the user.

•If the username has already been entered into ACS, the ACS group to which the user is assigned has the correct authorization enabled (such as IP/PPP, IPX/PPP or Exec/Telnet). Click Submit + Restart if a change has been made.

•The user expiration information in the Windows user database has not caused failed authentication. For troubleshooting purposes, disable password expiry for the user in the Windows user database.

Click External User Databases, click List All Databases Configured, and then ensure that the database configuration for Windows is listed.

In the Configure Unknown User Policy table of the External User Databases section ensure that the Fail the attempt option is not selected. And ensure that the Selected Databases list reflects the necessary database.

Verify that the Windows group that the user belongs to has not been mapped to No Access.

A dial-in user cannot connect to the AAA client.

The ACS internal database is being used for authentication.

A record of a failed attempt appears in the Failed Attempts Report (in the Reports & Activity section, click Failed Attempts).

From within ACS confirm that:

•The username has been entered into ACS.

•ACS internal database is selected from the Password Authentication list and a password has been entered in User Setup for the user.

•The ACS group to which the user is assigned has the correct authorization enabled (such as IP/PPP, IPX/PPP or Exec/Telnet). Click Submit + Restart if a change has been made.

•Expiration information has not caused failed authentication. Set to Expiration: Never for troubleshooting.

A dial-in user cannot connect to the AAA client; however, a Telnet connection can be authenticated across the LAN.

The problem is isolated to one of three areas:

•Line or modem configuration problem. Review the documentation that came with your modem and verify that the modem is properly configured.

•The user is not assigned to a group that has the correct authorization rights. Authorization rights can be modified under Group Setup or User Setup. User settings override group settings.

•The ACS or TACACS+ or RADIUS configuration is not correct in the AAA client.

Additionally, you can verify ACS connectivity by attempting to Telnet to the access server from a workstation connected to the LAN. A successful authentication for Telnet confirms that ACS is working with the AAA client.

A dial-in user cannot connect to the AAA client, and a Telnet connection cannot be authenticated across the LAN.

Determine whether the ACS is receiving the request by viewing the ACS reports. Based on what does not appear in the reports and which database is being used, troubleshoot the problem based on:

•Line or modem configuration problem. Review the documentation that came with your modem and verify that the modem is properly configured.

•The user does not exist in the Windows user database or the ACS internal database and might not have the correct password. Authentication parameters can be modified under User Setup.

•The ACS or TACACS+ or RADIUS configuration is not correct in the AAA client.

Callback is not working.

Ensure that callback works on the AAA client when using local authentication. Then add AAA authentication.

User authentication fails when using PAP.

Outbound PAP is not enabled. If the Failed Attempts report shows that you are using outbound PAP, go to the Interface Configuration section and check the Per-User Advanced TACACS+ Features check box. Then, choose the TACACS+ Outbound Password section of the Advanced TACACS+ Settings table on the User Setup page and type and confirm the password in the boxes provided.

Proxy Issues

Condition

Recovery Action

Proxying requests to another server fail.

Ensure that the:

•Direction on the remote server is set to Incoming/Outgoing or Incoming, and that the direction on the authentication forwarding server is set to Incoming/Outgoing or Outgoing.

•Shared secret (key) matches the shared secret of one or both ACSes.

•Character string and delimiter match the stripping information configured in the Proxy Distribution Table, and the position is set correctly to either Prefix or Suffix.

If the previous conditions are met, one or more servers is probably down, or no fallback server is configured. Choose the Network Configuration section and configure a fallback server. Fallback servers are used only when:

•The remote ACS is down.

•One or more services (CSTacacs, CSRadius, or CSAuth) are down.

•The secret key is misconfigured.

•Inbound or Outbound messaging is misconfigured.

Installation and Upgrade Issues

Condition

Recovery Action

The following error message appears when you try to upgrade or uninstall ACS:

Ensure that you have selected Log to reportname Report under System Configuration: Logging: Log Target: reportname. You must also set Network Configuration: servername: Access Server Type to ACS for Windows NT.

Make sure that the remote logging function is not configured to send accounting packets to the same location as the Send Accounting Information fields in the Proxy Distribution Table.

After you have changed the date format, the Logged-In User list and the Program Files\CiscoSecure ACS vx.x\TacConfig.txt
Program Files\CiscoSecure ACS vx.x\RadConfig.txt
log still display old format dates.

To see the changes made, you must restart the CSAdmin services and log on again.

Effect of logging unavailability on authentication functionality.

When local or remote logging normal operation is halted, authentication functionality will stop after a very short time as all worker threads are busy with logging assignments. Fixing the logging functionality will restore authentication; thus, troubleshooting the logging service logs is necessary.

The Logged in Users report works with some devices, but not with others

For the Logged in Users report to work (and this also applies to most other features involving sessions), packets should include at least the following fields:

•Authentication Request packet

–nas-ip-address

–nas-port

•Accounting Start packet

–nas-ip-address

–nas-port

–session-id

–framed-ip-address

•Accounting Stop packet

–nas-ip-address

–nas-port

–session-id

–framed-ip-address

Also, if a connection is so brief that there is little time between the start and stop packets (for example, HTTP through the PIX Firewall), the CSAdmin report may fail.

Third-Party Server Issues

Condition

Recovery Action

You cannot successfully implement the RSA token server.

To recover from this problem:

1. Log in to the computer running ACS. (Ensure that your login account has administrative privileges.)

2. Ensure that the RSA Client software is installed on the same computer as ACS.

3. Follow the setup instructions. Do not restart at the end of the installation.

4. Get the file named sdconf.rec from the Logged in Users directory of the RSA ACE server.

5. Place sdconf.rec in the %SystemRoot%\system32 directory.

6. Ensure that you can ping the machine that is running the ACE server by hostname. (You might need to add the machine in the lmhosts file.)

7. Verify that support for RSA is enabled in External User Database: Database Configuration in the ACS.

8. Run Test Authentication from the Windows control panel for the ACE/Client application.

9. From ACS, install the token server.

Authentication request does not hit the external database.

Set logging to full. Choose System Configuration > Service Control.

Check auth.log for confirmation that the authentication request is being forwarded to the third-party server. If it is not being forwarded, confirm that the external database. configuration is correct, as well as the unknown user policy settings.

On ACE/SDI server no incoming request is seen from ACS, although RSA/agent authentication works.

For dial-up users, ensure that you are using PAP and not MS-CHAP or CHAP. RSA/SDI does not support CHAP and ACS will not send the request to the RSA server; rather, it will log an error with external database failure.

Verify that the TACACS+ or RADIUS keys, in AAA client and ACS, are identical (case sensitive).

Re-enter the keys to confirm they are identical.

User can authenticate, but authorizations are not what is expected.

Different vendors use different AV pairs. AV pairs used in one vendor protocol may be ignored by another vendor protocol. Ensure that the user settings reflect the correct vendor protocol; for example, RADIUS (Cisco IOS/PIX).

TACACS+ and RADIUS Attribute Issues

Condition

Recovery Action

TACACS+ and RADIUS attributes do not appear on the Group Setup page.

Ensure that you have at least one RADIUS or TACACS+ AAA client configured in the Network Configuration section and that, in the Interface Configuration section, you have enabled the attributes you need to configure.

Note Some attributes are not customer-configurable in ACS; instead, their values are set by ACS.