Using the ACS Database Alone
Using either the RADIUS or
TACACS+ protocol, the network access server directs all dial-in user access
requests to Cisco Secure ACS for authentication and authorization of
privileges, which verifies the username and password
. The following
service and ACS user database interaction occurs:
- The TACACS+ or RADIUS service directs request to the Cisco Secure ACS
authentication and authorization service, where the request is authenticated
against the Cisco Secure ACS user database, associated authorizations are
assigned, and accounting information is logged to the Cisco Secure ACS logging
service.
- The Windows 2000 user database does not authenticate and grant dial
permission as a local user. The user may log in to Windows 2000 once the
dial-up AAA process is complete.
Using a Windows Database
When Cisco Secure ACS uses the
Windows 2000 Server user database for AAA, the following service and database
interaction occurs
:
- TACACS+ or RADIUS service directs request to the Cisco Secure ACS
Authentication and Authorization service, where the username and password are
sent to the Windows 2000 user database for authentication.
- If approved, Windows 2000 Server grants dial permission as a local
user.
- A response is returned to Cisco Secure ACS and authorizations are
assigned.
- Confirmation and associated authorizations assigned in Cisco Secure ACS for
that user are sent to the network access server. Accounting information is
logged.
- Using the Windows 2000 user database makes single login for dial-in and
network login possible, since the username and password used for authentication
are the same used for network login.
Using an External User Database
Cisco Secure ACS can be
configured to forward authentication of users to one or more external user
databases
. In
organizations in which a substantial user database already exists, Cisco Secure
ACS can leverage the work already invested in building the database without any
additional input.
For Cisco Secure ACS to interact with an external user
database, Cisco Secure ACS requires an API for third-party authentication.
Cisco Secure ACS communicates with the external user database using the API.
For Windows user databases and Generic LDAP, the program interface for the
external authentication is local to Cisco Secure ACS. In these cases, no
further components are required. For other third-party authentication sources,
additional components may be required.
In addition to performing authentication for network access, Cisco Secure
ACS can perform authentication for TACACS+ enable privileges using external
user databases.
Using Token Cards
Cisco Secure ACS supports
several third-party token servers
. For some token
servers, Cisco Secure ACS acts as a client to the token server. For others, it
uses the RADIUS interface of the token server for authentication requests. As
with the Windows 2000 database, after the username is located in the Cisco
Secure ACS user database, CSAuth can check the selected token server to verify
the username and token-card password. The token server then provides a response
approving or denying validation. If the response is approval, CSAuth knows that
authentication should be granted for the user.
Cisco Secure ACS can
support token servers using the RADIUS server built into the token server.
Rather than using the proprietary API of the vendor, Cisco Secure ACS sends
standard RADIUS authentication requests to the RADIUS authentication port on
the token server.
Cisco Secure ACS supports any token server that is a
RADIUS server compliant with IETF RFC 2865. So, in addition to the
RADIUS-enabled token server vendors explicitly supported, any token server that
supports RADIUS-based authentication can be used.
You can create multiple
instances of each of these token server types in Cisco Secure ACS for Windows
Server.