CiscoSecure ACS 2.4 for Windows NT User Guide
Table of ContentsUser Databases
Selecting a Database for Authentication
CiscoSecure User DatabaseConfiguring a Master CiscoSecure ACS and Replicating the Configuration to Other CiscoSecure ACSes
Windows NT User Database
DS RequirementsMCIS LDAP Database
Organizational Units and Groups
Configuring CiscoSecure ACS to use the DS User Database
MCIS LDAP RequirementsNovell NDS Database
Organizational Units and Groups
Configuring CiscoSecure ACS to use the MCIS LDAP User Database
Token-Card Server User Databases
You can select the CiscoSecure user database or configure an external user database such as Windows NT, Novell Directory Services (NDS), Open Database Connectivity (ODBC), Directory Services (DS), Microsoft Commercial Internet System Lightweight Directory Access Protocol (MCIS LDAP), or a token-card database to authenticate usernames and passwords according to your network requirements. This chapter discusses the advantages and limitations of each option.
When the network access server (NAS) first receives an authentication request, it searches the CiscoSecure user database for the user requesting access. If it does not find a match and CiscoSecure ACS 2.4 for Windows NT Server (CiscoSecure ACS) has not been configured to check another database, the authentication request fails and the user is denied access. However, if a match is found, or if the Unknown User Policy is configured to search another database, CiscoSecure ACS authenticates the user and assigns the authorization privileges of the group to which the user is assigned.
Figure 3-1 Using the CiscoSecure User Database for Authentication
The CiscoSecure ACS user database draws information from a number of data sources, including a hash-indexed flat file, VarsDB.MDB (an Access MDB) and the Windows NT Registry. This 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 file builds an index and tree structure, so searches can occur exponentially rather than linearly. This allows the CiscoSecure user database to authenticate users quickly.
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, MS-CHAP, ARAP, and ASCII.
Note Although using the CiscoSecure user database does not permit a single login, it does increase the level of network security.
You can configure CiscoSecure ACS to authenticate usernames and passwords against those already in the Windows NT user database. In organizations in which a substantial Windows NT user database already exists, CiscoSecure ACS can leverage the work already invested in building the database without any additional input. This eliminates the need for separate databases.
The pairing of the CiscoSecure and Windows NT user databases makes network security administration convenient. The NAS presents the username to CiscoSecure ACS. CiscoSecure ACS searches its own database to locate a match. If CiscoSecure ACS does not find a match, and CiscoSecure ACS is configured to check the Windows NT user database, then the username and password are forwarded to Windows NT for authentication against those 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. In the future, this user will authenticate much faster, because 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.
Figure 3-2 Using the Windows NT User Database for Authentication
To further control access by a user from within the Windows NT User Manager, you can configure CiscoSecure ACS to also check the setting for Grant dialin permission to user. If this parameter is disabled for the user, 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 to log in to the network. This means that you can configure CiscoSecure ACS so that users need to enter their username and password only once, allowing for a convenient single login.
However, authenticating against the Windows NT user database does not allow storage of third-party passwords (for example, CHAP). Therefore, if security is more important than leveraging the Windows NT user database, use either the CiscoSecure user database or MS CHAP.
You can map Windows NT domains to a specific CiscoSecure ACS group. For more information, see "Sophisticated Handling of Unknown Users."
CiscoSecure ACS can take advantage of Trust relationships that have been established between Windows NT servers. This allows users of the Trusted domain to authenticate against a user account residing in another domain. CiscoSecure ACS can also reference the Grant dialin permission to user setting across Trusted domains. Only one of the servers in the Trust relationship needs to have Windows NT installed on it. There are two types of Trust relationshipsone-way and two-way. See your Microsoft documentation for more information on Trust relationships.
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 takes advantage of the Windows NT domain information appended to the username (for example, domain_name\username.)
If you do not enter a domain name when entering the username, CiscoSecure ACS first checks the local Windows NT database. If it does not find the username, CiscoSecure ACS then checks all trusted domains. If CiscoSecure ACS still does not find the username, authentication fails. Users who want to authenticate against a specific domain must enter the domain name before their username in the following format:
Because the Windows NT operating system does not allow fallback on rejection, if a user who is dialing in from a Windows 95/98 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/98 dial-up networking. It is important to remove usernames from a database when the privileges associated with the user are no longer required.
Several parameters allow you to configure the Data Source Name (DSN). Change the DSN username and password to match the security settings of your ODBC database. If you cannot connect to the ODBC database when CiscoSecure ACS is starting, increase the connection retries counter.
Note The ODBC worker thread count should be increased only if the ODBC driver you are using is certified thread safe. For example, the Microsoft Access ODBC driver is not thread safe and can cause CiscoSecure ACS to become unstable if multiple threads are used. Where possible, the driver is queried to find out if it is thread safe. The thread count to use depends on the time the DSN takes to execute the procedure and the rate at which authentications are required. The maximum thread count is 10.
Figure 3-3 Using the ODBC Database for Authentication
The SQL procedure must return a single row containing the (non-NULL) fields. (See Table 3-1.)
Table 3-1 SQL Procedure Results
You can set the result codes listed in Table 3-2.
Table 3-2 Result Codes
A return code of 4 or higher results in an authentication error event. These errors do not increment per-user failed attempt counters. Additionally, error codes are returned to the NAS so it can distinguish between errors and failures and, if configured to do so, fall back to a backup AAA server.
Successful or failed authentications are not logged; general CiscoSecure ACS logging mechanisms will apply. In the event of an error (CSNTresult equal to or less than 4) the contents of the CSNTerrorString are written to the Windows NT Event Log under the Application Log.
Figure 3-4 Using Directory Services for Authentication
When you first install the DS directory, you select either Membership Authentication or Windows NT Authentication. For use with CiscoSecure ACS, select Membership Authentication. This is because the user's password must be available from the DS directory in clear-text format. If the DS directory is configured for Windows NT Authentication, the user's password is available only in the encrypted Windows NT internal format, not in a readable clear-text format. See your DS documentation for more information.
If a user is a member of a DS group, that group does not need to have the same name as the CiscoSecure ACS group; the DS group can be mapped to a CiscoSecure ACS group with any name you want to assign. To view the name of the group to which a user is assigned, click Users: User Management: Properties: Groups. A user can belong to no group, one group, or multiple groups. For more information on DS group mappings and CiscoSecure ACS, see the "Directory Services Database Group Mappings" section.
For information on configuring CiscoSecure ACS to use the DS user database, see the "Directory Services Database Configuration" section.
Figure 3-5 Using the Microsoft MCIS LDAP Directory for Authentication
When you first install the LDAP directory, you select either Membership Authentication or Windows NT Authentication. For use with CiscoSecure ACS, select Membership Authentication. This is because the user's password must be available from the LDAP directory in clear-text format. If the LDAP directory is configured for Windows NT Authentication, the user's password is available only in the encrypted Windows NT internal format, not in a readable clear-text format. See your Microsoft MCIS or Site Server documentation for more information.
CiscoSecure ACS uses the "Groups" Organizational Unit (ou). If a user is a member of an MCIS group, that group does not need to have the same name as the CiscoSecure ACS group; the MCIS group can be mapped to a CiscoSecure ACS group with any name you want to assign. To view the name of the group to which a user is assigned, click Users: User Management: Properties: Groups. A user can belong to no group, one group, or multiple groups.
For information on configuring CiscoSecure ACS to use the MCIS LDAP user database, see the "MCIS LDAP Configuration" section.
Note The Novell Requester must already be installed on the same Windows NT server on which you will install CiscoSecure ACS. You can download the Requester software from the Novell web site. See your Novell and Microsoft documentation for details.
In order for users to authenticate against an NDS database, CiscoSecure ACS must be correctly configured to recognize the NDS structure. 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 "NDS Database Authentication Configuration" section.
For an increased level of security, many networks require a token card for one-time password (OTP) authentication. To use a token card, the user must possess a token card or soft token algorithm and know a password to enable the token. This concept is "something you have and something you know." This represents one of the highest commercially available security methods of authentication.
CiscoSecure ACS can act as a client to the token-card server. To accomplish this, 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 server. You can use database replication or CSUtil.exe to update and maintain the user database.
Requests from the access device are first sent to CiscoSecure ACS. If CiscoSecure ACS has been configured to authenticate against a token-card server and finds the username, it forwards the authentication request to the token-card server. If it does not find the username, CiscoSecure ACS checks the database configured to authenticate unknown users. If the request for authentication returns a pass, then the appropriate authorizations are forwarded to the access device along with the approved authentication. CiscoSecure ACS then maintains the accounting information.
CiscoSecure ACS supports several token servers, including Security Dynamics, CRYPTOCard, SafeWord, and AXENT. The CRYPTOCard token-card server is included with CiscoSecure ACS; other servers must be 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, CiscoSecure ACS supports token caching for ISDN terminal adapters. 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 2 OTPs, plus any other login passwords, such as those for Windows NT networking. If the terminal adapter (TA) 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.
To help make the OTPs a bit easier for users, 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.
Replication of the CiscoSecure ACS information to other CiscoSecure ACSes requires different solutions depending on the environment. This section presents considerations when configuring CiscoSecure ACS database replication.
If the NAS at the administrator's site uses CiscoSecure ACS as a means of controlling network access, users can dial in to an access device at a central location. You can configure CiscoSecure ACS to allow redundant AAA server capability if you want the ability to fall back to a secondary CiscoSecure ACS when the primary CiscoSecure ACS server goes out of service. This allows incoming requests to be authenticated with no down time.
Note The NAS must be configured to point to both the primary and secondary authentication, authorization, and accounting (AAA) servers.
You must configure both a primary and at least 1 secondary CiscoSecure ACS, then replicate the information from the primary to the other(s), allowing the CiscoSecure ACSes to mirror one another. This, in effect, creates a backup CiscoSecure ACS so that users can still authenticate if the primary CiscoSecure ACS goes out of service. You must configure CiscoSecure ACS with the applicable Distributed System settings. There are two Distributed System settings that apply to configuring CiscoSecure Database Replication:
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 you also want to use the proxy feature, make sure you enter the identical key on both CiscoSecure ACSes. The CiscoSecure ACS software handles the security of the data when replicating from the primary AAA server to the secondary. If you are not using the proxy feature, you can leave this field blank. (See the "Proxy" section.) From the AAA Server Type menu, select CiscoSecure ACS for Windows NT. Database Replication can take place only between CiscoSecure ACSes. The traffic type once again pertains to proxy and does not apply to the direction in which replication will flow.
After you enter the secondary CiscoSecure ACS into the AAA Server table on the primary CiscoSecure ACS, enter the information for the primary CiscoSecure ACS in the AAA Server table on the secondary CiscoSecure ACS. After you enter this information, each CiscoSecure ACS will be aware of the other. This is the foundation on which other Distributed System features are configured.
You can then configure CiscoSecure Database Replication to determine the information that is replicated and replication schedule. See the "CiscoSecure Database Replication" section in "Step-by-Step Configuration for CiscoSecure ACS," for details on configuring database replication. 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 need to be replicated every time, and, if there are very few updates and additions being made to CiscoSecure ACS, you can set replication to take place less frequently or even manually.
The Replication Partners section lists the defined AAA servers; the list 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.
On the secondary CiscoSecure ACS, in the Replication Partners section, click the name of the primary CiscoSecure ACS in the Accept Replication From list. This defines the primary CiscoSecure ACS as the source from which the secondary CiscoSecure ACS will receive replication.
If the network includes additional CiscoSecure ACSes, you can configure CiscoSecure Database Replication so that the first CiscoSecure ACS also sends the data to these CiscoSecure ACSes after the first Database Replication process is completed. Simply enter the additional CiscoSecure ACS in the AAA Server table and add the additional CiscoSecure ACSes to the Replication list.
You can also configure CiscoSecure ACS to perform Database Replication by cascading the replication process from the first CiscoSecure ACS to the second, then from the second to the third, and so on. To configure this feature, set Replication Scheduling on the secondary CiscoSecure ACS to Automatically Triggered Cascade. The secondary CiscoSecure ACS can then perform replication to its configured list of CiscoSecure ACSes upon completion of an incoming session from a higher level. This allows you to build a hierarchy of CiscoSecure ACSes. In this case, the secondary CiscoSecure ACS is both a server and a clientit is a client to the higher-level server from which it receives the incoming replication, and it is a server to the CiscoSecure ACS to which it replicates. This reduces the load on the primary CiscoSecure ACS because it does not need to replicate to every CiscoSecure ACS.