Cisco Systems Servers Manuale Utente

Pagina di 654
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 
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 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.