|
|
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 Cisco Secure Access Control Server for Windows NT/2000 Servers Version 2.6 (Cisco Secure 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, Cisco Secure ACS authenticates the user and assigns the authorization privileges of the group to which the user is assigned. See Figure 3-1.
The Cisco Secure ACS user database draws information from a number of data sources, including a hash-indexed flat file, VarsDB.MDB (in Microsoft Access MDB format), and the Windows NT/2000 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 enables the CiscoSecure user database to authenticate users quickly. If you are using the CiscoSecure user database, there are three ways to create user accounts in Cisco Secure ACS:
After the user accounts exist in the CiscoSecure user database, it is easier to administer user accounts in Cisco Secure ACS than in the Windows NT/2000 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. |
The pairing of the CiscoSecure and Windows NT/2000 user databases makes network security administration convenient. The NAS presents the username to Cisco Secure ACS. Cisco Secure ACS searches its database to locate a match. If Cisco Secure ACS does not find a match, and Cisco Secure ACS is configured to check the Windows NT/2000 user database, the username and password are forwarded to Windows NT/2000 for authentication against those in the Windows NT/2000 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 Cisco Secure ACS goes directly to the Windows NT/2000 user database for authentication. When this new user is added to the CiscoSecure user database, User Setup: Password Authentication is automatically configured to use the Windows NT/2000 user database for password authentication and to assign the user to the group specified as Windows NT/2000 Users.
Authorization privileges assigned to the user's group are then assigned to the user just authenticated. See Figure 3-2.
An added benefit of using the Windows NT/2000 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 Cisco Secure ACS so that users need to enter their usernames and passwords only once, allowing a convenient, single login.
However, authenticating against the Windows NT/2000 user database does not allow storage of third-party passwords (for example, CHAP). Therefore, if security is more important than leveraging the Windows NT/2000 user database, use either the CiscoSecure user database or MS CHAP.
You can map Windows NT/2000 domains to a specific Cisco Secure ACS group. For more information, see "Sophisticated Handling of Unknown Users."
Cisco Secure ACS can also work across trusted Windows NT/2000 domains.
Before using the Windows NT/2000 user database for authentication, follow these steps:
Step 2 Click to clear the following User Properties check boxes:
If you use the Windows NT/2000 Dial-Up Networking client to dial in to the NAS, three fields appear:
|
Note For more information about the implications of completing or leaving the domain field blank, see the "Windows NT/2000 Authentication" section. |
If you use the Windows 95/98 Dial-Up Networking client to dial in to the NAS, two fields appear:
|
Note You also have the option of prefixing your username with the name of the domain you want to log in to. For more information about the implications of prefixing or not prefixing the domain name before the user name, see the "Windows NT/2000 Authentication" section. |
While the Windows NT/2000 and Windows 95/98 provide different methods of specifying a domain name, the effect of providing or not providing the domain name while logging in is the same.
The most reliable method of authenticating users against a specific domain is to require users to submit the domains they should be authenticated against along with their usernames. With the Windows NT/2000 dial-up client, this is accomplished by typing the domain in the domain field (or selecting it from the drop-down list). With the Windows 95/98 dial-up client, this is accomplished by submitting the username in the fully qualified format. Users submitting a fully qualified username must enter the domain name before their username in the following format:
DOMAIN_NAME\USER_NAME
For example, user Mary Smith (msmith) in Domain10 would enter the following:
Domain10\msmith
Another reason to provide the username in the format shown above is if a user is included in more than one domain. In this case, the privileges assigned upon authentication will be those associated with the account in the first domain with a matching username and password. This also illustrates the importance of removing usernames from a domain when the privileges associated with the user are no longer required.
If you do not specify a domain name when typing the username, Cisco Secure ACS submits the username to the Windows NT/2000 operating system on the Cisco Secure ACS server. If the Windows NT/2000 server does not find the username in its local database, it then checks all trusted domains. If the password of the first occurrence of the username in the trusted domains does not match the password submitted by Cisco Secure ACS, authentication fails. If the Domain List list box in External User Databases: Windows NT/2000: Configure has been configured with a list of trusted domains, Cisco Secure ACS will then submit the username and password to each domain in the list in a fully qualified format until it successfully authenticates the user. If Cisco Secure ACS has tried each domain listed in the Domain List list box or if no trusted domains have been configured in the Domain List list box, Cisco Secure ACS stops attempting to authenticate the user and does not grant that user access.
|
Note Cisco Secure ACS does not support the user@domain format of qualified usernames. |
Cisco Secure ACS passes the user information to the relational database via the ODBC connection. The relational database must have a stored procedure that queries the appropriate tables and returns to Cisco Secure ACS. If the returned values indicate that the username and password provided are valid, Cisco Secure ACS grants the user access. Otherwise, Cisco Secure ACS denies the user access. See Figure 3-3.
To support the two protocols, Cisco Secure ACS provides different input and expects different output from the ODBC authentication request. This requires a different stored procedure in the relational database to support either protocol.
The Cisco Secure ACS CD-ROM provides "stub" routines for creating a procedure in either Microsoft SQL Server or an Oracle database. You can either modify a copy of these routines to create your stored procedure or write your own. Example routines for creating PAP and CHAP/MS-CHAP/ARAP authentication stored procedures in SQL Server are given in the "ODBC Configuration" section.
The following sections provide reference information about Cisco Secure ACS data types versus SQL data types, PAP authentication procedure inputs and outputs, CHAP/MS-CHAP/ARAP authentication procedure inputs and outputs, and expected result codes. You can use this information while writing your authentication stored procedures in your relational database.
The Cisco Secure ACS types and their matching SQL types are as follows:
Table 3-1 details the input provided by Cisco Secure ACS to the stored procedure supporting PAP authentication. The stored procedure should accept the named input values as variables.
Field | Type | Explanation |
|---|---|---|
String | 0-64 characters | |
CSNTpassword | 0-255 characters |
The input names are for guidance only. Procedure variables created from them can have different names; however, they must be defined in the procedure in the order shown—the username must precede the password variable.
The stored procedure must return a single row containing the non-null fields. Table 3-2 lists the procedure results Cisco Secure ACS expects as output from stored procedure.
Field | Type | Explanation |
|---|---|---|
Integer | See Table 3-5. | |
Integer | The Cisco Secure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-99 are converted to the default. | |
String | 0-16 characters. A third-party defined string is added to subsequent account log file entries. | |
String | 0-255 characters. A third-party defined string is written to the CSAuth service log file if an error occurs. |
The CSNTGroup and CSNTacctInfo fields are processed only after a successful authentication. The CSNTerrorString file is logged only after a failure (if the result is greater than or equal to 4).
The procedure must return the result fields in the order listed above.
Cisco Secure ACS provides a single value for input to the stored procedure supporting CHAP/MS-CHAP/ARAP authentication. The stored procedure should accept the named input value as a variable. See Table 3-3.
|
Note Because Cisco Secure ACS performs authentication for CHAP/MS-CHAP/ARAP, the user's password is not an input.
|
The input name is for guidance only. A procedure variable created from it can have a different name.
The stored procedure must return a single row containing the non-null fields. Table 3-4 lists the procedure results Cisco Secure ACS expects as output from stored procedure.
Field | Type | Explanation |
|---|---|---|
Integer | See Table 3-5. | |
Integer | The Cisco Secure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-99 are converted to the default. | |
String | 0-16 characters. A third-party defined string is added to subsequent account log file entries. | |
String | 0-255 characters. A third-party defined string is written to the CSAuth service log file if an error occurs. | |
String | 0-255 characters. The password is authenticated by Cisco Secure ACS for CHAP authentication. |
The CSNTGroup and CSNTacctInfo fields are processed only after a successful authentication. The CSNTerrorString file is logged only after a failure (if the result is greater than or equal to 4).
The procedure must return the result fields in the order listed above.
You can set the result codes listed in Table 3-5.
Result Code | Meaning |
|---|---|
0 (zero) | Authentication successful |
1 | Unknown username |
2 | Invalid password |
3 | Unknown username or invalid password |
4+ | Internal error—authentication not processed |
The SQL procedure can decide between 1, 2, or 3 to indicate a failure, depending on how much information you want the failed authentication log files to include.
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 Cisco Secure 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/2000 Event Log under the Application Log.
Cisco Secure ACS supports authentication via any supported version of generic LDAP, such as Netscape. Configuring Cisco Secure ACS to authenticate against an LDAP database does not enforce changes in the LDAP database directly. To manage your LDAP database, see your LDAP database documentation. See Figure 3-4.
To use LDAP authentication, you must have an LDAP database installed.
|
Note Cisco Secure ACS does not currently support password aging when using LDAP. To disable an account, use the Account Status settings on the LDAP server. |
The LDAP directory instance should have Clear Text/Basic Authentication enabled.
|
Note The password is in clear text and is not encrypted. To increase security, select the Use Secure Authentication check box. |
If a user is a member of an LDAP group, that group does not need to have the same name as the Cisco Secure ACS group; the LDAP group can be mapped to a Cisco Secure 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 LDAP group mappings and Cisco Secure ACS, see the "Generic LDAP Database Group Mappings" section.
For information on configuring Cisco Secure ACS to use the LDAP user database, see the "Generic LDAP Database Configuration" section.
Cisco Secure ACS supports authentication via the MCIS authenticator. Configuring Cisco Secure ACS to authenticate against a MCIS database does not enforce changes in the MCIS database directly. To manage your MCIS database, see your Microsoft database documentation. See Figure 3-5.
|
Note Cisco Secure ACS does not currently support password aging when using MCIS. To disable an account, use the Account Status settings on the LDAP server. |
The LDAP directory instance should have Clear Text/Basic Authentication enabled.
|
Note The password is in clear text and is not encrypted. To increase security, select the Use Secure Authentication check box, the Use Encryption check box, or both. |
User Objects in the LDAP directory must meet the following requirements:
|
Note Cisco Secure ACS cannot authenticate user objects in the AnonymousUsers container (ou=Members,ou=AnonymousUsers). |
For information on configuring Cisco Secure ACS to use the MCIS user database, see the "MCIS Configuration" section.
Novell users can use a Novell NDS database, version 4.6 or greater.
For users to authenticate against a Novell NDS database, Cisco Secure ACS must be correctly configured to recognize the Novell NDS structure. Cisco Secure ACS supports up to twenty trees. Each tree has several containers, and each container can have several contexts. Contexts can be thought of as similar to Windows NT/2000 domains. For a user to authenticate against a Novell NDS context, a user object must exist, and the password must be able to log the name into the tree.
To use a Novell NDS database for authentication, you must set it up in External User Databases: Database Configuration: Novell NDS. For more specific configuration information, see the "Novell NDS Database Authentication Configuration" section.
Cisco Secure ACS can act as a client to the token-card server. To accomplish this, Cisco Secure 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 Cisco Secure 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 Cisco Secure ACS. If Cisco Secure 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, Cisco Secure ACS checks the database configured to authenticate unknown users. If the request for authentication returns a pass, the appropriate authorizations are forwarded to the access device along with the approved authentication. Cisco Secure ACS then maintains the accounting information.
If the NAS at the administrator's site uses Cisco Secure ACS as a means of controlling network access, users can dial in to an access device at a central location. You can configure Cisco Secure ACS to allow redundant AAA server capability if you want the ability to fall back to a secondary Cisco Secure ACS when the primary Cisco Secure 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. |
If these features do not appear in the user interface, click Interface Configuration: Advanced Options and select the applicable check boxes.
On the primary Cisco Secure ACS, in the AAA Servers table, there is already an entry for this server itself. Click Add Entry and type the name and the IP address of the secondary Cisco Secure 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 specify the identical key on both Cisco Secure ACS servers. The Cisco Secure 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 Cisco Secure ACS for Windows NT/2000. Database replication can take place only between Cisco Secure ACS servers. 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 Cisco Secure ACS into the AAA Server table on the primary Cisco Secure ACS, specify the information for the primary Cisco Secure ACS in the AAA Server table on the secondary Cisco Secure ACS. After you specify this information, each Cisco Secure 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 the replication schedule. See the "CiscoSecure Database Replication" section for details on configuring database replication. The primary Cisco Secure ACS will usually have only the Send check boxes selected, while the secondary Cisco Secure ACS will have the Receive check boxes selected. Not all components need to be replicated every time, and, if there are few updates and additions being made to Cisco Secure ACS, you can set replication to take place less frequently or even manually.
On the secondary Cisco Secure ACS, in the Replication Partners section, click the name of the primary Cisco Secure ACS in the Accept Replication From list. This defines the primary Cisco Secure ACS as the source from which the secondary Cisco Secure ACS will receive replication.
If the network includes additional Cisco Secure ACS servers, you can configure CiscoSecure Database Replication so that the first Cisco Secure ACS also sends the data to these Cisco Secure ACS servers after the first Database Replication process is completed. Simply specify the additional Cisco Secure ACS in the AAA Server table and add the additional Cisco Secure ACS servers to the Replication list.
Posted: Fri Dec 29 11:59:55 PST 2000
Copyright 1989-2000©Cisco Systems Inc.
