CiscoSecure ACS 2.4 for Windows NT User Guide
Sophisticated Unknown User Handling

Table of Contents

Sophisticated Handling of Unknown Users
Known, Unknown, and Cached Users
External Database Search Process
Configuring the External User Database

Sophisticated Handling of Unknown Users


This chapter describes the CiscoSecure ACS 2.4 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 two advantages to the CiscoSecure ACS administrator:

  • Eliminates the time-consuming overhead of entering every user multiple times
  • Removes the possibility of data-entry errors inherent to manual procedures, making enforcement of security policy more consistent

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.

Known, Unknown, and Cached Users

CiscoSecure ACS determines three categories of users. Each category is treated slightly differently:

  • Known Users—Users explicitly added, either manually or automatically, into the CiscoSecure ACS database. These users can be added by the administrator typing them in through CSAdmin, by a relational database management system (RDBMS) application program using RDBMS Synchronization, by using database replication, or through a text file batch import using the CSUtil.exe utility. See "CiscoSecure ACS Command-Line Database Utility," for more information on CSUtil.exe. Each user must have a defined password type and be explicitly associated with a particular authentication database.
  • Unknown Users—Users who have no account entry existing in the CiscoSecure ACS database. Such users will never have previously authenticated against CiscoSecure ACS.
  • Cached Users—Users whose accounts have been automatically added to the CiscoSecure ACS database by the CiscoSecure ACS unknown user processing routines. See the "External Database Search Process" section for more information on this process. All cached users were once unknown users.

External Database Search Process

The external database search process controls:

  • Unknown User Policy—This defines what action CiscoSecure ACS will take if it does not find a matching username in its own database. There are two options:
    • Fail the authentication and reject the request; that is, fail all unknown users
    • Continue to search the list of external databases configured. This is where unknown user processing is enabled/disabled.
  • External Database Search Order—This defines which of the installed external databases to use to try to authenticate an unknown user. The order is important, because CiscoSecure ACS tries the external databases in the order specified in the External User Databases: Unknown User Policy window, starting at the top and working down. You can change the order of this list using the controls provided.

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.

General Authentication Request Handling and Rejection Mode

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.

Database Authentication Request Handling and Rejection Mode When Using the Windows NT User Database

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 two 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 domain name is supplied 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/98 dial-up networking client, there is no separate entry field; 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 was supplied and tries these authentication credentials against the specified domain. If the domain controller rejects the authentication request, CiscoSecure ACS logs the request as a failed attempt. If a domain name is supplied, CiscoSecure ACS can 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 this 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/98 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.


Note      If an organization allows multiple occurrences of a username across domains (for example, every domain has a user called Administrator) or users dialing in do not provide their domain as part of their authentication credentials, then only the user whose name and password Windows NT checks first will ever successfully authenticate. The order in which domains are checked is under the control of Windows NT networking, not CiscoSecure ACS. Therefore, if you need reliable support of multiple instances of a username across configured domains, users must always supply their domain membership as part of the authentication request.


Performance

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.


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.

External Database List Order

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.

Configuring the External User Database

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.

External User Databases Supported

Unknown users can be authenticated using one of the following external user databases. See the "Authentication" section for more specific information for each type of database.

  • Open Database Connectivity (ODBC)
  • Directory Services (DS) (LDAP)
  • Microsoft Commercial Information Server Lightweight Directory Access Protocol (MCIS LDAP)
  • CRYPTOCard
  • SafeWord
  • AXENT
  • SDI
  • Novell NDS
  • Windows NT User Database

Note      PAP authentication is supported for ODBC, DS, and MCIS LDAP user databases. CHAP, MS-CHAP, and ARAP are not supported with these databases.


Mapping an External Database to a CiscoSecure ACS Group

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.

Mapping a Database Group to a CiscoSecure ACS Group

You can map a Windows NT domain or Directory Services (DS) (LDAP), Novell Directory Services (NDS), Lightweight Directory Access Protocol (LDAP), or other database group 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 database 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.

Adding a New Domain to Map

You can define a mapping to the group level of a domain to map to a CiscoSecure ACS group.

No Access Group

To prevent remote access for all users of a group, assign the group to the CiscoSecure ACS No Access group. For example, you could assign all members of a 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. For information on preventing all unknown users from dialing in, see the "Turning off External Database Authentication" section.

Multiple Group Mappings

A user can belong to more than one 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."

Sort Order within a Group Mapping

When defining mappings for users who belong to multiple 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 this three-group combination are assigned to CiscoSecure ACS Group 2. Previously Mary was assigned to a combination of the two groups, Engineering and Marketing, but when she became a manager, the Administrator neglected to remove her from this two-group combination. Users who belong to those three groups are assigned to CiscoSecure ACS Group 1. When authenticating, if Group 1 is 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.

Remapping or Deleting an Existing Mapped Group

You can change or delete the mapping for an existing group. See the "Remapping an Existing Mapped Group" section or the "Deleting a Group Mapping Configuration" section for instructions.

Database Search Order

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.

Windows NT, ODBC, DS, and MCIS LDAP Group Mappings Order

You can change the order in which the group mappings for the Windows NT, NDS, DS, 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 Group Mappings Order" section.

Windows NT and Authentication Order

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.

Timeout

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.

Turning off External Database Authentication

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.

Users Listed in Multiple Databases or Domains

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 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/98 Dial-Up Networking.


Note      It is important to remove usernames from a database when the privileges associated with them are no longer required.