CiscoSecure ACS 2.4 for Windows NT User Guide
User Databases

Table of Contents

User Databases
Selecting a Database for Authentication
Configuring a Master CiscoSecure ACS and Replicating the Configuration to Other CiscoSecure ACSes

User Databases


Selecting a Database for Authentication

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), Directory Services (DS), 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.

CiscoSecure User Database

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 CiscoSecure ACS 2.4 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.


Figure 3-1   Using the CiscoSecure User Database for Authentication

The CiscoSecure ACS user database draws information from a number of data sources, including a hash-indexed flat file, VarsDB.MDB (an Access MDB) and the Windows NT 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 allows the CiscoSecure user database to authenticate users quickly.

If you are using the CiscoSecure user database, there are three 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.


Note      Although using the CiscoSecure user database does not permit a single login, it does increase the level of network security.


Windows NT User Database

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 and 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.


Figure 3-2   Using the Windows NT User Database for Authentication

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 Handling of Unknown Users."

CiscoSecure ACS can also work across trusted Windows NT domains.

Windows NT User Manager

Before using the Windows NT user database for authentication:

  • Make sure the username exists in the Windows NT user database.
  • Clear the following User Properties check boxes:
    • User must change password at next logon
    • Account disabled
  • If you want to control dial-in access from within Windows NT, click Dial-in and select Grant dialin permission to user. You must also configure the option to reference this feature in CiscoSecure ACS in External User Databases: Database Group Mappings.

Trust Relationships

CiscoSecure ACS can take advantage of Trust relationships that have been established between Windows NT servers. This allows users of the Trusted domain to authenticate against a user account residing in another domain. CiscoSecure ACS can also reference the Grant dialin permission to user setting across Trusted domains. Only one of the servers in the Trust relationship needs to have Windows NT installed on it. There are two types of Trust relationships—one-way and two-way. See your Microsoft documentation for more information on Trust relationships.

Dial-up Networking Client

If you dial in to the NAS using the Windows NT Dial-Up Networking client, three fields appear:

  • username—Enter your username.
  • password—Enter your password.
  • domain—Enter your valid domain name. If you leave this field blank, CiscoSecure ACS will check the local Windows NT database and all trusted domains.

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/98 Dial-Up Networking client, two fields normally appear:

  • username—Enter your username.
  • password—Enter your password.

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/98 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/98 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/98 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.

ODBC Database

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.


Note      The ODBC worker thread count should be increased only if the ODBC driver you are using is certified thread safe. For example, the Microsoft Access ODBC driver is not thread safe and can cause CiscoSecure ACS to become unstable if multiple threads are used. Where possible, the driver is queried to find out if it is thread safe. The thread count to use depends on the time the DSN takes to execute the procedure and the rate at which authentications are required. The maximum thread count is 10.



Figure 3-3   Using the ODBC Database for Authentication

Type Definitions

The CiscoSecure ACS types and their matching SQL types are:

  • Integer—SQL_INTEGER
  • String—SQL_CHAR or SQL_VARCHAR

Procedure Parameters

The procedure should accept the following named parameters:

1. CSNTusername—String, 0-64 characters

2. CSNTpassword—String, 0-255 characters

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.

Procedure Results

The SQL procedure must return a single row containing the (non-NULL) fields. (See Table 3-1.)

Table 3-1   SQL Procedure Results 

Field Type Explanation

CSNTresult

Integer

See 3.4 Result Codes.

CSNTgroup

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.

CSNTacctInfo

String

0-16 characters. A third-party defined string is added to subsequent account log file entries.

CSNTerrorString

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.

Result Codes

You can set the result codes listed in Table 3-2.

Table 3-2   Result Codes 

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.

Directory Services

CiscoSecure ACS supports authentication via any supported version of Directory Services (DS), such as Netscape's.

You can manage your DS database via either the HTML interface or the manufacturer's interface. For more information on managing your DS database, see your manufacturer's documentation.


Figure 3-4   Using Directory Services for Authentication

DS Requirements

To use DS authentication, you must have a Directory Server installed.


Note      CiscoSecure ACS does not currently support password aging when using DS. To disable an account, use the Account Status settings on the DS server.


When you first install the DS 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 DS directory in clear-text format. If the DS 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 DS documentation for more information.

The DS directory instance should have Clear Text/Basic Authentication enabled.


Note      The password is in clear text and is not encrypted. To increase security, click the Use Secure Authentication check box.


Organizational Units and Groups

If a user is a member of a DS group, that group does not need to have the same name as the CiscoSecure ACS group; the DS 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 more information on DS group mappings and CiscoSecure ACS, see the "Directory Services Database Group Mappings" section.

Configuring CiscoSecure ACS to use the DS User Database

For information on configuring CiscoSecure ACS to use the DS user database, see the "Directory Services Database Configuration" section.

MCIS LDAP Database

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 the HTML interface or the Microsoft Management Console. For information on managing your MCIS LDAP database, see your Microsoft documentation.


Figure 3-5   Using the Microsoft MCIS LDAP Directory for Authentication

MCIS LDAP Requirements

To use MCIS LDAP authentication, you must have Microsoft Site Server 3.0 or MCIS 2.0 installed on the server.


Note      CiscoSecure ACS does not currently support password aging when using MCIS. To disable an account, use the Account Status settings on the LDAP 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.


Note      The password is in clear text and is not encrypted. To increase security, click the Use Secure Authentication check box, the Use Encryption check box, or both.


Members Container

User Objects in the LDAP directory must meet the following requirements:

  • User objects must be located in the Members container (ou=members). This container is created automatically when you install the LDAP directory. User objects added using the Microsoft browser-based HTML LDAP Administration tool are added to the Members container by default.

Note CiscoSecure ACS cannot authenticate user objects in the AnonymousUsers container (ou=Members,ou=AnonymousUsers).


  • User objects must be of the type "Member." This is the default user object type if users are added to the LDAP directory using the Microsoft HTML Administration tool.
  • CiscoSecure ACS compares the user object's common name (cn=JohnSmith) object property (attribute) to the username with which the user authenticates. CiscoSecure ACS ignores the user object's First and Last Name properties. The common name property must exactly match the username entered during dial-in. The attributes and values assigned to the user are located in the Members container.
  • The user object's user-password property is the password that is compared to the password entered by the user when attempting to authenticate. The Microsoft HTML Administration tool calls this user-password property "Password."
  • During authentication, CiscoSecure ACS evaluates the user-object's Account-Status property. This property can be set to several values, but users can authenticate only if the value is set to Active. If the Account-Status property is set to any value other than Active, the user fails authentication, even if the password is correct. A status of 1 indicates an active account.
  • CiscoSecure ACS uses the user-object's Groups property to determine the user's group membership. The groups property of a user object is a list of all the groups to which a user belongs. CiscoSecure ACS ignores all Windows NT Groups to which a user belongs. This is because CiscoSecure ACS uses "Membership Authentication," not "Windows NT Authentication."

Organizational Units and Groups

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.

Configuring CiscoSecure ACS to use the MCIS LDAP User Database

For information on configuring CiscoSecure ACS to use the MCIS LDAP user database, see the "MCIS LDAP Configuration" section.

Novell NDS Database

Novell users can use a Novell NetWare Directory Services (NDS) database.


Note      The Novell Requester must already be installed on the same Windows NT server on which you will install CiscoSecure ACS. You can download the Requester software from the Novell web site. See your Novell and Microsoft documentation for details.


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.

Token-Card Server User Databases

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.

CiscoSecure ACS supports several token servers, including Security Dynamics, CRYPTOCard, SafeWord, and AXENT. The CRYPTOCard token-card server is included with CiscoSecure ACS; other servers must be purchased separately. Both PPP (ISDN and async) and Telnet are supported for Security Dynamics, CRYPTOCard, and Safeword token-card servers. AXENT token-card server support includes only Telnet over async, not PPP with ISDN.

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.

Configuring a Master CiscoSecure ACS and Replicating the Configuration to Other CiscoSecure ACSes

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.


Note      The NAS must be configured to point to both the primary and secondary authentication, authorization, and accounting (AAA) servers.


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:

  • Defining the AAA Server table located in the Network Configuration window. If you are using network device groups (NDGs), click the name of the applicable NDG to display the AAA Server table.
  • The actual configuration of CiscoSecure Database Replication in the System Configuration window

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.) 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.