Chapter 11 Working with User Databases
Token Server User Databases
11-58
User Guide for Cisco Secure ACS for Windows Server
78-14696-01, Version 3.1
Note
Authentication protocols not supported with token server databases may be
supported by another type of external user database. For more information about
authentication protocols and the external database types that support them, see
Authentication Protocol-Database Compatibility, page 1-9
.
Requests from the AAA client are first sent to Cisco Secure ACS. If
Cisco Secure ACS has been configured to authenticate against a token server and
finds the username, it forwards the authentication request to the token server. If it
does not find the username, Cisco Secure ACS checks the database configured to
authenticate unknown users. If the request for authentication is passed, the
appropriate authorizations are forwarded to the AAA client along with the
approved authentication. Cisco Secure ACS then maintains the accounting
information.
Cisco Secure ACS acts as a client to the token server. For all token servers except
RSA SecurID, Cisco Secure ACS accomplishes this using the RADIUS interface
of the token server. For more information about Cisco Secure ACS support of
token servers with a RADIUS interface, see
RADIUS-Enabled Token Servers,
page 11-59
.
For RSA SecurID, Cisco Secure ACS uses an RSA proprietary API. For more
information about Cisco Secure ACS support of RSA SecurID token servers, see
RSA SecurID Token Servers, page 11-64
.
Token Servers and ISDN
Cisco Secure ACS supports token caching for ISDN terminal adapters and
routers. One inconvenience of using token cards for OTP authentication with
ISDN is that each B channel requires its own OTP. Therefore, a user must enter at
least 2 OTPs, plus any other login passwords, such as those for Windows NT/2000
networking. If the terminal adapter supports the ability to turn on and off the
second B channel, users might have to enter many OTPs each time the second
B channel comes into service.
Cisco Secure ACS caches the token to help make the OTPs easier for users. This
means that if a token card is being used to authenticate a user on the first
B channel, a specified period can be set during which the second B channel can
come into service without requiring the user to enter another OTP. To lessen the
risk of unauthorized access to the second B channel, you can limit the time the
second B channel is up. Furthermore, you can configure the second B channel to