|
|
You can select the CiscoSecure User Database or configure an external user database such as Windows NT, Novell NDS, or a token-card database to authenticate usernames and passwords according to your network requirements. This section discusses the advantages and limitations of each option.
The NAS searches the CiscoSecure User Database for the user requesting access. If a match is not found, and the CiscoSecure ACS has not been configured to check another database, the request for authentication will fail and the user will be denied access. However, if a match is found, or if the Unknown User Policy is configured to search the local database, the CiscoSecure ACS authenticates the user and assigns the authorization privileges of the group to which the user is assigned.
The CiscoSecure ACS user database is a hash-indexed flat file. This type of file is not searched from the top of a text file as typically associated with the term flat file, but instead is indexed like a database. The hash-indexed flat file builds an index and tree structure so searches can occur exponentially rather than in a linear fashion, which enables the CiscoSecure User Database to rapidly authenticate users.
If you are using the CiscoSecure User Database, there are three ways to enter usernames:
After the names exist in the CiscoSecure User Database, administration is easier than using the Windows NT User Database. The CiscoSecure User Database supports authentication for PAP, CHAP, ARAP, and ASCII.
The CiscoSecure ACS 2.1 for Windows NT can be configured to authenticate usernames and passwords against those usernames and passwords already configured in the Windows NT User Database. This means that in organizations in which a substantial Windows NT User Database already exists, the CiscoSecure ACS can leverage the work already invested in building that database without any additional input from the system administrator. This eliminates the need to build two separate databases.
The pairing of the CiscoSecure User Database and the Windows NT User Databases results in convenient administration of network security. The access device presents the username to the CiscoSecure ACS. The CiscoSecure ACS searches its own database to locate a match. If a match is not found, and the CiscoSecure ACS has been configured to check the Windows NT User Database for usernames not found, then the username and password are forwarded to Windows NT for authentication against the usernames and passwords residing in the Windows NT User Database. If a match is confirmed, the username (but not the password) is stored in the CiscoSecure User Database for future authentication requests. This enables all future authentications by this user to occur much faster because the CiscoSecure ACS goes directly to the Windows NT User Database for authentication. When this new user is added to the CiscoSecure User Database, the User Setup: Password Authentication is automatically configured to use the Windows NT User Database for password authentication, and to assign the user to the group specified as Windows NT Users.
Authorization privileges assigned to the user's group are then assigned to the user just authenticated.
For administrators that desire to further control access by a user from within the Windows NT User Manager, the CiscoSecure ACS can be configured to also check the setting for Grant dialin permission to user. If the user has this parameter disabled, access is not permitted, even if the username and password are entered correctly.
An added benefit of using the Windows NT User Database is that the username and password used for authentication are also used for network login. This means that you can configure the CiscoSecure ACS so that users need to enter their username and password only once, allowing a convenient simple, single login.
However, authenticating against the Windows NT User Database does not allow the storage of third-party passwords for added levels of security (for example, CHAP). Therefore, if security is a more important consideration than the benefits of leveraging the Windows NT User Database, you should use the CiscoSecure User Database.
Windows NT domains can be mapped to a specific CiscoSecure ACS group. For more information, see the chapter "Sophisticated Unknown User Handling."
The CiscoSecure ACS can also work across trusted Windows NT domains.
Before using the Windows NT User Database for authentication:
If you dial in to the NAS using the Windows NT Dialup Networking client, you are presented with three fields:
If you have the same username on multiple trusted domains, you can enter a domain name to specify the account against which to authenticate. CiscoSecure ACS will take advantage of the Windows NT domain information that is appended to the username (for example, DOMAIN_NAME\USER_NAME.)
If you dial in to the CiscoSecure ACS using the Windows 95 Dialup Networking client, you are normally presented with two fields:
If just the username is entered, CiscoSecure ACS will first check the local Windows NT database. If the username is not found, the CiscoSecure ACS will then check all trusted domains. If the username is not found, authentication fails. Users who want to authenticate against a specific domains must enter the domain name before their username in the following format:
DOMAIN_NAME\USER_NAME
For example, user Mary in Domain10 would enter:
Domain10\Mary
Because the Windows NT operating system does not allow fallback on rejection, if a user who is dialing in from a Windows 95 client is included in more than one domain and the username is not found in the first domain checked, the user might be able to authenticate; however, the privileges assigned will be those associated with the second database or domain. You can work around this by having the user enter the domain name, including the backslash (\) character, when logging in using Windows 95 dial-up networking. It is important to remove usernames from a database when the privileges associated with it are no longer required.
For both Windows 95 and Windows NT, entering the domain name can speed up authentication, because the CiscoSecure ACS can go directly to the domain rather than searching through the local domain and all trusted domains until it finds the username.
Novell users can also use a Novell NetWare Directory Services (NDS) database.
In order for users to authenticate against an NDS database, the CiscoSecure ACS must be properly configured to recognize the NDS structure. The CiscoSecure ACS supports only one Tree. Each Tree has several Containers, and each Container can have several Contexts. Contexts can be thought of as similar to Windows NT domains. In order for a user to authenticate against an NDS Context, a user object must exist and the password must be able to log the name into the Tree.
To use an NDS database for authentication, you must set it up in External User Databases: Database Configuration: NDS User Database. For more specific configuration information, see the section "NDS Database Authentication Configuration" in the chapter "Step-by-Step Configuration for the CiscoSecure ACS."
For an increased level of security, many networks require a token card for OTP authentication. The use of the token card requires a user to possess a token card or soft token algorithm and know a password to enable the token. This concept is also "something you have and something you know." This represents one of the highest commercially available security methods of authentication.
The CiscoSecure ACS can act as a client to the token-card server. To accomplish this, the CiscoSecure ACS is set up with a secured communication link to the token-card server. This is done by either configuring a shared secret password between the two servers and defining the IP address or by installing a file created by the token-card server that contains the same information into the CiscoSecure ACS. You can use Database Replication or CSUtil.exe to update and maintain the user database.
Requests from the access device are first sent to the CiscoSecure ACS. If the username is found and has been configured to authenticate against a token-card server, the authentication request is forwarded accordingly. If the username is not found, the CiscoSecure ACS checks the database you have configured to authenticate unknown users. If the request for authentication returns a pass, then the appropriate authorizations are forwarded with the approved authentication to the access device. The CiscoSecure ACS then maintains the accounting information.
The CiscoSecure ACS 2.1 for Windows NT supports several token servers, including Security Dynamics, CRYPTOCard, SafeWord, and AXENT. Token-card servers other than CRYPTOCard are not included with the CiscoSecure ACS; they are purchased separately. Both PPP (ISDN and async) and Telnet are supported for Security Dynamics, CRYPTOCard, and Safeword token-card servers. AXENT token-card server support includes only Telnet over async, not PPP with ISDN.
Additionally, token caching for ISDN terminal adapters is supported by the CiscoSecure ACS.
A convenient feature for the support of using ISDN Terminal Adapters (TAs) is token caching. One of the inconveniences 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 two OTPs plus any other login passwords, such as those for Windows NT networking. If the TA supports the ability to turn on and off the second B channel, users could find themselves entering many OTPs each time the second B channel came into service.
To help make the OTPs a bit easier for users to deal with, the ability to cache the token was created. 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 in which the second B channel can come into service without having to enter another OTP. To lessen the risk of unauthorized access to the second B channel, the time the second B channel is up can be limited. Furthermore, the second B channel can be configured to use the CHAP password entered 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.
For some customers, the ability to replicate the CiscoSecure ACS information to other CiscoSecure ACSes requires different solutions depending on the environment. This section gives an idea of considerations when configuring the Database Replication feature in CiscoSecure ACS.
A typical scenario is one in which a NAS is configured at the administrator's site to use the CiscoSecure ACS as a means of controlling network access, allowing users to dial in to an access device at their central location. The CiscoSecure ACS can be configured to allow redundant AAA server capability if the primary CiscoSecure ACS server goes out of service and the ability to fall back to a secondary CiscoSecure ACS is desired to continue to handle incoming authentication requests with no down time.
A primary and secondary CiscoSecure ACS must be configured, and the information from the primary replicated to the secondary, allowing the CiscoSecure ACSes to mirror one another. This means that the CiscoSecure ACS must be configured with the necessary Distributed System setting. There are two Distributed System settings that apply to configuring CiscoSecure Database Replication:
If these features do not display in the user interface, enable them in Interface Configuration: Advanced Options.
On the primary CiscoSecure ACS, in the AAA Servers table, there is already an entry for this server itself. Click Add Entry and enter the name and the IP address of the secondary CiscoSecure ACS. The Key field is used for encryption and pertains to another feature. If CiscoSecure is also to be configured for authentication forwarding, make sure that the identical key is entered on both CiscoSecure ACSes. The security of the data is handled by the CiscoSecure ACS software when replicating data from the primary to the secondary AAA Servers. If the authentication forwarding feature is not used, you can leave this field blank. (See the section "Authentication Forwarding" in the Chapter "Distributed Systems."). In the AAA Server Type pull down menu, select CiscoSecure ACS for Windows NT. Database Replication can take place only between CiscoSecure ACSes. The traffic type once again pertains to Authentication Forwarding and does not apply to the direction in which replication is to flow.
After you have entered the secondary CiscoSecure ACS into the AAA server table on the primary CiscoSecure ACS, you must then enter the information for the primary CiscoSecure ACS in the AAA Server table on the secondary CiscoSecure ACS. After you have entered this information, each CiscoSecure ACS can be aware of the other. This is the foundation on which other Distributed System features are configured.
You can then configure the CiscoSecure Database Replication parameters to determine what is to be replicated and when the replication is to take place. The previous sections in this chapter provides the instructions for determining the CiscoSecure ACS components to be replicated and for scheduling when Database Replication is to take place. The primary CiscoSecure ACS will usually have only the Send boxes checked, while the secondary CiscoSecure ACS will have the Receive boxes checked. Not all components will need to be replicated every time, and, if there are very few updates and additions being made to the CiscoSecure ACS, you can schedule replication to take place less frequently or even manually.
In the Replication Partners section, a list of the defined AAA Servers displays; the information is taken from the information configured in the AAA Servers table. The secondary CiscoSecure ACS is listed in the AAA Servers list on the primary CiscoSecure ACS. Select and move the secondary server to the Replication list. This section configures the target to which data is replicated from the primary CiscoSecure ACS.
In the same Replication Partners section on the secondary CiscoSecure ACS, click the Accept Replication From pull down list and select the primary CiscoSecure ACS. This defines the primary CiscoSecure ACS as the source from which the secondary CiscoSecure ACS will receive replication.
If there are additional CiscoSecure ACSes, you can configure CiscoSecure Database Replication so that the primary CiscoSecure ACS also sends the data to the third CiscoSecure ACS after the Database Replication process is completed with the secondary CiscoSecure ACS, as long as the proper parameters have been configured. Simply enter the third CiscoSecure ACS in the AAA Server table and add the third CiscoSecure ACS to the Replication list.
You can also configure the CiscoSecure ACSes to perform Database Replication by cascading the replication process from the primary to the secondary CiscoSecure ACS, and then from the secondary to the third CiscoSecure ACS, and so on. To configure this feature, set Replication Scheduling on the secondary CiscoSecure ACS to Automatically Triggered Cascade. This allows the secondary CiscoSecure ACS to perform replication to its configured list of CiscoSecure ACSes upon completion of an incoming Database Replication session from a higher level, which would be the primary CiscoSecure ACS. This allows the administrator to build a propagation tree hierarchy of CiscoSecure ACSes. In this situation, the secondary CiscoSecure ACS is both a server and a client--it is a client to the higher level server from which it receives the incoming replication, and it is a server to the masters which it replicates to. Additionally, this reduces the load on the primary CiscoSecure ACS because it does not need to replicate to all the CiscoSecure ACSes.
|
|