|
|
This chapter describes the Cisco Secure ACS 2.3 for Windows NT Server (CiscoSecure ACS) external authentication procedures. Step-by-step procedures for authentication configuration follow the description.
The Sophisticated Unknown User Handling (unknown user) feature allows CiscoSecure ACS to use a variety of external databases instead of, or in addition to, its own internal database to authenticate incoming user requests. This allows 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 CiscoSecure ACS. This provides 2 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 CiscoSecure ACS to forward authentication of the incoming username and password to the available external databases if authentication against the CiscoSecure ACS database fails.
CiscoSecure ACS determines 3 categories of users. Each category is treated slightly differently:
The external database search process controls:
To enable unknown user processing, click Check the following external user databases. To disable unknown user processing, click Fail the attempt. This causes CiscoSecure ACS to check incoming authentication requests against its own database only and not consult the other listed external databases.
To select an external database for use in unknown user processing, highlight the database in the External Databases list and click the right arrow (>). The name of the database is transferred Selected Databases list. To remove an item from the list of databases, highlight the item and click the left arrow (<). To change the order of the list of installed databases, highlight the item and click Up or Down to move the item to the desired location.
If CiscoSecure ACS has unknown user processing configured, when it receives an authentication request, it attempts to authenticate the request as follows:
1. CiscoSecure ACS checks its own internal database. If the user exists in the CiscoSecure ACS database (that is, is a known user), CiscoSecure ACS tries to authenticate the user using the specified password type against the appropriate database. Authentication for that user either passes or fails, depending on other procedures in the normal authentication process.
2. If the user does not exist in the CiscoSecure ACS database (that is, is an unknown user), CiscoSecure ACS tries each of the configured external databases in the order specified in the Selected Databases list. If the user passes authentication against one of the external databases, CiscoSecure ACS automatically adds the user to its own database, with a pointer to use the appropriate password type and database. This unknown user has been converted by CiscoSecure ACS and is now a known user.
3. When the known user tries to authenticate in the future, 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. This lets you differentiate between users added via unknown user processing and those added explicitly through CSAdmin. Cached users are treated the same as all other users in the CiscoSecure ACS database (known users).
4. If the user fails authentication against all configured external databases, the user is not added to the CiscoSecure ACS database, and the authentication request is rejected.
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 databases, CiscoSecure ACS correctly authenticates only the first instance it tries, unless the user is found in the Windows NT User Database. (See the "Database Authentication Request Handling and Rejection Mode When Using the Windows NT User Database" section for information on Windows NT authentication order.)
CiscoSecure ACS always tries the external databases in the order specified; therefore, if CiscoSecure ACS is configured to access the Windows NT user database first and, for example, an SDI database second, and user1 exists in both databases, when the SDI user1 tries to authenticate with an SDI token, authentication will always fail. If the order of databases listed is reversed (that is, SDI is listed first), the Windows NT user1 would always fail authentication, because CiscoSecure ACS attempts to authenticate that username and password against the SDI server first.
Because it is a native Windows NT application, CiscoSecure ACS, when using Windows NT as an external database, treats it as a special case, providing numerous public API calls that can be exploited to access its native security database. This adds functions to the remote access authentication process. Perhaps the most important of these capabilities is support for multiple occurrences of the same username across the Trusted Domains against which CiscoSecure ACS authenticates access requests.
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 2 possible scenarios to consider: a scenario in which the domain is supplied as part of the authentication request and one in which it is not.
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 environment, the local copy of Windows NT (on the same system on which CiscoSecure ACS is running) attempts a more complex authentication process. It first attempts to authenticate the user against its local domain controller. If the user does not exist in that database, it progresses down the list of all of its Trusted Domains trying the username against each one. If Windows NT does not find the username, it then tries the credentials against its local accounts database. If it does not find the user there, it rejects the authentication request. If authentication succeeds against either the local domain, any of the Trusted Domains, or the local Windows NT accounts database, the user is granted access.
If the username 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 returns a rejection message to CiscoSecure ACS indicating the failure was due to an incorrect password. It then stops attempting to authenticate that user against any other domains, and does not grant that user access.
Adding external databases against which to process unknown users can significantly increase the time needed for each individual authentication. At best, the time needed for each authentication is the time taken by the external database to authenticate, plus some latency for CiscoSecure ACS processing. In some circumstances (for example, when using a Windows NT user database), the extra latency introduced by an external database can be as much as tens of seconds. If you have configured multiple databases, this number is multiplied by the time taken for each one to complete.
 | Caution If the network access server (NAS) timeout value is not set high enough to cope with this delay, the NAS times out the request and every authentication fails. If a secondary AAA server is configured, the NAS then redirects the request to it. If the secondary server is configured the same as the primary, the request fails again. The result is that all authentications fail, network traffic increases, and server workload increases. If you use external database(s), be sure to increase the NAS timeout to a value high enough to accommodate it. |
The order in which the databases are listed/tried is important. For best performance, authentications should be processed first against the external database where the highest number of authentications are likely to succeed (that is, get the highest level of successful cache hits). Always list the database that will allow most authentications to succeed 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 user databases. See the "Authentication" section of "Overview," for more specific information for each type of database.
You can map an external database to a CiscoSecure ACS group. Users who authenticate using the specified database automatically belong to, and inherit the characteristics of, the group. For example, you could configure CiscoSecure ACS so that all unknown users who authenticate via a certain token-card database belong to a group called "Telecommuters." You could then assign a group setup appropriate for users who are working away from home, such as MaxSessions=1. Or you could configure restricted hours for other groups, but give unrestricted access to "Telecommuters" group members.
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 group's 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" whose group settings differ from the default group's. 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 "Tokyo" groups. You could then configure different access times for the CiscoSecure ACS "Engineering-Tokyo" group than you would for an "Engineering-London" 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. For example, you could assign all members of a Windows NT group "Contractors" to the No Access group so they could not dial in to the network remotely. For information on assigning a No Access group, see the "Assigning a No Access Group" section in "Step-by-Step Configuration for CiscoSecure ACS." For information on preventing all unknown users from dialing in, see the "Turning off External Database Authentication" section.
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 3-group combination of Engineering, Marketing, and Managers. Users who belong to this 3-group combination are assigned to CiscoSecure ACS Group 2. Previously Mary was assigned to a combination of the 2 groups, Engineering and Marketing, but when she became a manager, the Administrator neglected to remove her from this 2-group combination. Users who belong to those 3 groups are assigned to 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 she will be assigned the Group 1 settings, rather than the Group 2 settings like the other managers.
You can change or delete the mapping for an existing group. See the "Remapping an Existing Mapped Group" section in "Step-by-Step Configuration for CiscoSecure ACS," or the "Deleting a Group Mapping Configuration" section in "Step-by-Step Configuration for CiscoSecure ACS," for instructions.
You can configure the order in which CiscoSecure ACS checks the external databases when users who are not in the CiscoSecure ACS database attempt to authenticate. If the first listed database does not recognize the user, CiscoSecure ACS checks the next listed database, and so on down the list, in the order listed, until the user authenticates. The exception to this is the Windows NT database. (For more information see the "Windows NT and Authentication Order" section.) If CiscoSecure ACS does not find the user in any of the databases, authentication fails. To configure the order of the databases, see the "Setting the Database Search Order" section in "Step-by-Step Configuration for CiscoSecure ACS."
You can change the order in which the group mappings for the Windows NT, ODBC, and MCIS LDAP databases are checked. To sort group mappings, you must have already defined them in the database, and you must have already mapped them. For details see the "Setting the Windows NT and MCIS LDAP Group Mappings Order" section in "Step-by-Step Configuration for CiscoSecure ACS."
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 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. See your Cisco IOS documentation for details.
You can configure CiscoSecure ACS 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 Dial-up Networking.
|
|