|
|
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), 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 first searches the CiscoSecure user database for the user requesting access. If it does not find a match and Cisco Secure ACS 2.3 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.
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 linearly. This allows the CiscoSecure user database to authenticate users quickly.
If you are using the CiscoSecure user database, there are 3 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, MS-CHAP, ARAP, and ASCII.
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 user database and the 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.
Authorization privileges assigned to the user's group are then assigned to the user just authenticated.
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 Unknown User Handling."
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 Dial-up Networking client, 3 fields appear:
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 dial in to CiscoSecure ACS using the Windows 95 Dial-up Networking client, two fields normally appear:
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:
DOMAIN_NAME\USER_NAME
For example, user Mary Smith (msmith) in Domain10 would enter:
Domain10\msmith
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 the user are no longer required.
 | TimeSaver For both Windows 95 and Windows NT, entering the domain name can speed up authentication, because CiscoSecure ACS can go directly to the domain rather than searching through the local domain and all trusted domains until it finds the username. |
CiscoSecure ACS supports authentication via the Open Database Connectivity (ODBC) authenticator.
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.
The CiscoSecure ACS types and their matching SQL types are:
The procedure should accept the following named parameters:
The parameter names are for guidance only and can be changed; however, they must appear in the order shown---the username must precede the password parameter.
The SQL procedure must return a single row containing the (non-NULL) fields. (See Table 3-1.)
| Field | Type | Explanation |
|---|---|---|
See 3.4 Result Codes. | ||
Integer | The CiscoSecure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-99 are converted to the default. | |
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 fields CSNTGroup and CSNTacctInfo are processed only upon 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-2.
| 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 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.
CiscoSecure ACS supports authentication via the Microsoft Commercial Internet System Lightweight Directory Access Protocol (MCIS LDAP) authenticator.
You can manage your MCIS LDAP database via either the HTML interface or the Microsoft Management Console. For information on managing your MCIS LDAP database, see your Microsoft documentation.
To use MCIS LDAP authentication, you must have Microsoft Site Server 3.0 or MCIS 2.0 installed on the server.
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.
The LDAP directory instance should have Clear Text/Basic Authentication enabled.
User Objects in the LDAP directory must meet the following requirements:
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 in "Step-by-Step Configuration for CiscoSecure ACS."
Novell users can use a Novell NetWare Directory Services (NDS) database.
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 in ""Step-by-Step Configuration for CiscoSecure ACS."
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.
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.
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:
If these features do not display in the user interface, click Interface Configuration: Advanced Options and check the applicable check boxes.
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 in "Distributed Systems.") 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 client---it 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.
|
|