Filter
Top Products
Chapter 11 Working with User Databases
Token Server User Databases
11-48
Cisco Secure ACS 3.0 for Windows 2000/NT Servers User Guide
78-13751-01, Version 3.0
About Token Servers and Cisco Secure ACS
Cisco Secure ACS provides PAP authentication using token servers. Requests
from the access device 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 access device 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 the token servers
supported, Cisco Secure ACS accomplishes this in one of two ways. The first
method uses the token server’s RADIUS interface. For more information about
Cisco Secure ACS support of token servers with a RADIUS interface, see the
“RADIUS-Enabled Token Servers” section on page 11-49.
For some token servers, Cisco Secure ACS uses the token server vendor’s
proprietary API. For more information about Cisco Secure ACS support of token
servers using the token server vendor’s proprietary API, see the “Token Servers
with Vendor-Proprietary Interfaces” section on page 11-53.
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
use the CHAP password specified during the first login to further lessen the
chance of a security problem. When the first B channel is dropped, the cached
token is erased.