|
|
This chapter provides a detailed description of the external authentication procedures of CiscoSecure ACS. Following the description, step-by-step procedures are given for authentication configuration.
Sophisticated Unknown User Handling (Unknown User) is a powerful integration feature that allows the CiscoSecure ACS to use a variety of external authentication sources (instead of or in addition to its own internal database) to authenticate incoming user requests. This allows the CiscoSecure ACS to provide the foundation for a basic single sign-on capability by integrating the network and host-level access control. Because the incoming username and password of users dialing in can be authenticated against a variety of external authentication databases, there is no need for the network administrator to manually maintain a duplicate list within the CiscoSecure ACS. This provides two advantages to the CiscoSecure ACS administrator:
The Unknown User feature is a form of authentication forwarding that allows you to add an extra step to the authentication process. This step allows the CiscoSecure ACS to forward authentication of the incoming username and password to the available external authentication sources if authentication against the CiscoSecure ACS's database fails.
The CiscoSecure ACS defines three types of users and treats them slightly differently, depending on their category:
The external database search process provides control of:
To enable Unknown User processing, click Try the following list of authentication servers. To disable unknown user processing, click Fail users not found in the CiscoSecure ACS database. This will cause the CiscoSecure ACS to check incoming authentication requests against its own database only and not consult the list of external authentication sources.
To select an external authentication source for use in Unknown User processing, highlight the source in the list of available external authentication sources in the left list and click the right arrow key. The name will be transferred to the right list of installed authentication sources. To deselect an item, reverse the procedure. To change the order of the list of installed authentication sources, highlight the item and use the up and down arrows to move the item up or down the list.
When the CiscoSecure ACS has Unknown User processing configured and receives an authentication request, it attempts to authenticate the request as follows:
1 ) CiscoSecure ACS checks its own internal database. If the user exists (a Known User), CiscoSecure ACS attempts to authenticate the user using the specified password type for that user against the appropriate authentication source. Authentication for that user will either pass or fail, depending on normal authentication procedures.
2 ) If the user does not exist in the CiscoSecure ACS database (an Unknown User), the CiscoSecure ACS will then try each of the configured external authentication sources in the order in which the administrator has specified. If the user passes authentication against one of the external databases, the CiscoSecure ACS automatically adds that user to its own database with a pointer to use the appropriate password type/database. This unknown user has been converted by the CiscoSecure ACS and is now known.
3 ) When this user attempts to authenticate again, CiscoSecure ACS authenticates the user against the database that was successful the first time. Users added by Unknown User processing are flagged as such within the CiscoSecure ACS database and are called Cached Users to allow you to differentiate between them and those added explicitly through CSAdmin. Cached users can be treated the same as all other users in the CiscoSecure ACS database (Known Users).
4 ) If the user fails authentication against all of the configured external authentication sources, the user is not added to the CiscoSecure ACS database and the authentication request is rejected.
Note that CiscoSecure ACS supports only a single instance of a given username across all configured external databases. For example, if user user1 exists in any of the external authentication sources, the CiscoSecure ACS correctly authenticates only the first one it tries, with one very important exception, the Windows NT User Database. (See the section "Database Authentication Request Handling and Rejection Mode When Using the Windows NT User Database" for information on Windows NT authentication order.) The CiscoSecure ACS always tries the external databases in the order they are specified; therefore, if the CiscoSecure ACS is configured to access the Windows NT user database first and an SDI Ace OTP server second and user1 exists in both databases, when the user1 who exists in the ACE database tries to authenticate with his SDI token, that user will always fail. If the order of databases listed were reversed (that is, SDI was listed first), the Windows NT user1 would always fail, because the CiscoSecure ACS attempts to authenticate that username and password against the SDI Ace server.
Because it is a native Windows NT application, the CiscoSecure ACS (when using Windows NT as an external authentication source) treats Windows NT as a special case, providing numerous public API calls that can be exploited to access its native security database, facilitating richer functionality in the remote access authentication process. Perhaps the most important of these capabilities is support of multiple occurrences of the same username across the Trusted Domains against which CiscoSecure ACS authenticates access requests.
The CiscoSecure ACS communicates with the operating system of the machine on which it is installed to perform authentications, and the local copy of Windows NT uses its built-in facilities to forward the authentication requests to the appropriate domain controller. there are two possible scenarios to consider: when the domain is supplied as part of the authentication request and when it is not.
If the domain name is supplied with the username as part of the authentication request, when you log in using the Windows NT dial-up networking client, the domain name is required. If you log in using the Windows 95 dial-up networking client, there is no separate entry field provided; however, you can enter the domain name manually along with the username in the format domain\user. In either case, CiscoSecure ACS detects that the domain name has been supplied and tries the authentication credentials supplied against the specified domain. If the authentication is rejected by the domain controller, the authentication request is rejected and logged as a failed attempt. Therefore, if a domain name is supplied, CiscoSecure ACS is able to differentiate among multiple users with the same username. The record cached into the CiscoSecure ACS database is in the form domain\user; the combination of username and domain makes that user unique in the CiscoSecure ACS database.
If the appropriate domain identifier is not supplied as part of the authentication process, as with the Windows 95 dial-up networking client or with Windows NT in a Workgroup configuration, the local copy of Windows NT on the same system on which CiscoSecure ACS is running attempts a somewhat more complex authentication process. It first attempts to authenticate the user against its local domain controller. If the user does not exist in that user database, it progresses down the list of all of its Trusted domains trying the username supplied against each one. If this process fails, Windows NT then tries the credentials against its local accounts database. If the user fails there, the authentication request is rejected. If authentication succeeds against the local domain, any of the Trusted Domains, or the local Windows NT accounts database, the user is granted access.
If the username supplied exists in either the local domain or any of the Trusted Domains but the password does not match the one supplied as part of the authentication credentials, Windows NT networking returns a rejection message to the CiscoSecure ACS indicating failure due to Bad Password. It then stops attempting to authenticate that user against any other domains it has not yet tried and that user is not granted access. Note that if an organization allows:
then only the user whose name and password Windows NT checks first will ever successfully authenticate. Because the order in which domains are checked is under the control of Windows NT networking and not CiscoSecure ACS, no control of it can be exerted. Therefore, if an organization requires reliable support of multiple instances of a username across configured domains, the users' domain membership should always be supplied as part of the authentication request.
Adding external authentication sources against which to process unknown users can add significant latency to the time taken for each individual authentication. At best, the time taken for each authentication is the time taken by the external authentication source to authenticate plus some latency for the CiscoSecure ACS processing. In some circumstances (for example, when using a Windows NT user database), the extra latency introduced by the external source can be so high as to be measured in tens of seconds. If multiple sources are configured, this number is multiplied by the time taken for each one to complete. This can have very undesirable consequences--if the NAS timeout value is not set high enough to cope with this delay, every authentication would fail because the NAS will time out the request. The NAS will then redirect the request to the secondary AAA server if one is configured. If the secondary server is configured the same as the primary, the requeset will fail again. The result is that all authentications fail, network traffic increases, server workload increases, and so on. Therefore, it is very important that if an external authentication source is used, NAS timeout is adjusted to a value high enough to accommodate it.
It is important to consider the order in which the sources are listed/tried. To optimize external authentication performance, it is best to process authentications first against the external authentication source where the highest number of authentications are likely to succeed (that is, get the highest level of successful cache hits). Therefore, always list the sources in the order that will allow most authentications to succeed against a source as near to the top of the list as possible.
Unknown Users are users who are not listed in the CiscoSecure ACS database. Before they are allowed to authenticate, you must configure the procedure in External User Databases.
Unknown users can be authenticated using one of the following external users databases:
You can map an external database to a CiscoSecure ACS group. This means that users who authenticate using the specified database will automatically belong to and inherit the characteristics of the group. For example, you might want to configure the CiscoSecure ACS so that all unknown users authenticate via a certain token card database and that all these users belong to a group called "Telecommuters." You can then assign the appropriate group setup for users who are working away from home. For example, you could assign MaxSessions of 1 to all members of the group "Telecommuters." Alternatively, you could configure restricted hours for other groups, but allow "Telecommuters" group members unrestricted access.
You can map a Windows NT domain to a CiscoSecure ACS group, down to the Group level. For example, all users who belong to a Windows NT domain called "Company" could map to the default group and be assigned the default groups settings. Users of the Windows NT domain "Company" who belong to the Windows NT group "Engineering" can map to a different CiscoSecure ACS group called "Engineering" with Group Settings different from the default group. Users in the Windows NT domain "Company" who belong to the Windows NT group "Marketing" could be assigned to a CiscoSecure ACS group named "Marketing" with still different Group Settings.
Users who belong to more than one Windows NT group can be assigned to still another CiscoSecure ACS group. For example, you can configure a CiscoSecure ACS Group Mapping for users who belong to both the "Engineering" and "California" groups. You could then configure different access time for the CiscoSecure ACS "Engineering-CA" group than you would for an "Engineering-NY" group.
You can define a mapping to the group level of a domain to map to a CiscoSecure ACS group.
To prevent remote access for all users of a Windows NT group, assign the Windows NT group to the CiscoSecure ACS No Access group. You could use this feature to assign all members of a Windows NT group "Contractors" to the No Access group so they could not dial in to the network remotely. To assign a Windows NT user to the No Access group, follow these steps:
Step 1 Click External User Databases: Database Group Mappings: Windows NT.
Step 2 Click the name of the existing group or click Add mapping.
Step 3 In the drop-down box, click <No Access>.
Step 4 Click Submit.
For information on preventing all unknown users from dialing in, see the section "Turning off External Database Authentication."
A user can belong to more than one Windows NT group mapping. For example, a user, John, could be a member of the group combination "Engineering" and "California" and at the same time be a member of the group combination "Engineering" and "Managers."
When defining mappings for users who belong to multiple Windows NT groups, make sure they are in the correct order so that users are granted the correct group settings. For example, a user, Mary, is assigned to the three-group combination of Engineering, Marketing, and Managers. Users who belong to those three groups are assigned to the CiscoSecure ACS Group 2. Previously, Mary was assigned to a combination of the two groups, Engineering and Marketing, from which she was not removed when she became a manager. Users who belong to those three groups are assigned to the CiscoSecure ACS Group 1. When authenticating, if Windows NT sees Group 1 listed first, Mary will be authenticated as a user of Group 1, and will be assigned the Group 1 settings, which are different from the Group 2 settings of the other managers.
You can change the mapping for an existing Windows NT group. To remap an existing Windows NT group, follow these steps:
Step 1 Click External User Databases: Database Group Mappings: Windows NT.
Step 2 Click the name of the group.
Step 3 Click the name of the mapping you want to change.
Step 4 From the drop-down box, click the name of the new group to map to.
Step 5 Click Submit.
To delete a Windows NT group mapping, follow these steps:
Step 1 Click External User Databases: Database Group Mappings: Windows NT.
Step 2 Click the name of the group.
Step 3 Click the name of the mapping you want to change.
You can configure the order in which the databases will be checked by the CiscoSecure ACS when users who are not in the CiscoSecure ACS database attempt to authenticate. If a user is not recognized by the first listed database, the next listed database will be checked, and so on down the list, in the order listed, until the user is authenticated. The exception to this is the Windows NT database (see the section, "Windows NT Database and Authentication Order"). If the user is not found in any of the databases, authentication will fail. Follow these steps:
Step 1 Click External User Databases: Unknown User Policy.
Step 2 Click Check the following external user databases.
Step 3 If the databases you want to be checked are not in the Selected Databases column, click the name of the database and the right arrow key. To move a database out of the list, click the name of the database and the left arrow key.
Step 4 To move the position of a database within the list, click the name of the database and then click Up or Down until it is in the position you want.
You can change the order in which the Windows NT group mappings are checked.To sort the Windows NT group mappings, you must have already defined them in the Windows NT User database, and you must have already mapped them. Follow these steps:
Step 1 Click External User Databases: Database Group Mappings: Windows NT.
Step 2 Click the name of the group.
Step 3 Click Add Mapping.
Step 4 Make sure all the Windows NT groups you want to list are in the Selected column. If not, click the name of the group to move, then click the right arrow button.
Step 5 Click the name of the Windows NT group to move, then click Up or Down until it is in the position you want.
Windows NT does not allow fallback on rejection. If a user tries to authenticate against the Windows NT database and is rejected (for example, if the password is incorrect), authentication fails.
The default NAS timeout is 10 seconds. If you have the CiscoSecure ACS configured to search through several databases or if your databases are very large, you might need to increase this value in your NAS configuration file.
You can configure the CiscoSecure ACS 2.1 for Windows NT so that users who are not in the CiscoSecure ACS database are not allowed to authenticate. To do this, click External User Databases: Unknown User Policy: Fail the Attempt.
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 is not authenticated.
You might be able to work around this by having the user enter the domain name, including the backslash (\) character, when logging in using Windows 95 Dialup Networking.
It is important to remove usernames from a database when the privileges associated with it are no longer required.
|
|