cc/td/doc/product/access/acs_soft/cs_unx
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Token Server Support

Authentication via a Token Server Example

Corresponding Administrator Requirements

Authenticating One-Time Password Cards via PPP

Configuring the NAS for Token Card Support

Enabling Token Caching

Working with CRYPTOCard Authentication

Obtaining CRYPTOCard RB-1 Tokens

Creating a CRYPTOCard Directory

Initializing the Physical CRYPTOCards

Using the CRYPTOCard in a Typical Logon Sequence

Working with S/Key Authentication

S/Key Example Login

Setting Up a CiscoSecure User for S/Key Use

Working with SecurID Authentication

About the SecureID ACE/Server

ACE/Server Setup

ACE/Server for Windows NT Setup

Configuring Users for Secure Computing Token Card Use

Setting a User's Initial SafeWord Configuration

Editing a User's Existing SafeWord Configuration

Configuring a User's SafeWord Authentication Method

Configuring a User's SafeWord Access (Authorization)

Configuring a User's SafeWord Aliases

Enabling Group Administrator Access to the SafeWord Configuration Pages

Using CiscoSecure's Token Card Support with RADIUS

Adding Token Card Support After Installing CiscoSecure ACS


Token Server Support

This chapter provides information on using token servers and one-time password authentication with the CiscoSecure Access Control Server (ACS) and includes the following sections:

• Authentication via a Token Server Example

• Configuring the NAS for Token Card Support

• Enabling Token Caching

• Working with CRYPTOCard Authentication

• Working with S/Key Authentication

• Working with SecurID Authentication

• Configuring Users for Secure Computing Token Card Use

• Using CiscoSecure's Token Card Support with RADIUS

• Adding Token Card Support After Installing CiscoSecure ACS

Token servers, used in conjunction with the appropriate token cards (also known as one-time password cards), add a new layer of security. Each token card, about the size of a credit card, is programmed to a specific user and each user has a unique personal identification number (PIN) that can generate a password keyed strictly to the corresponding card.

One-time password authentication takes place between the specified token server and the user. Figure 12-1 shows how a remote user can authenticate to the CiscoSecure ACS by means of a token card.

Figure 12-1 Remote Access to a CiscoSecure ACS via a Token Card

The token card database is usually considered part of the CiscoSecure ACS, although the two can be separate from each other depending on your preferences.

CiscoSecure ACS software supports authentication from these authentication servers:

•CRYPTOCard

•SecurID ACE/Server from Security Dynamics Inc. (SDI)

•SafeWord from Secure Computing (formerly known as Enigma Logic)

For each token server you plan to support, make sure you have properly installed the corresponding software before installing the CiscoSecure ACS. For example, if you plan to support the SecurID ACE/Server, confirm that you have installed ACE/Server software before installing the CiscoSecure ACS. Or, if you plan to support SafeWord from Secure Computing, confirm that you have installed SafeWord Access Server software before installing the CiscoSecure ACS.

Note Support for CRYPTOCard token cards is built into CiscoSecure ACS software. To configure CiscoSecure ACS expressly for CRYPTOCard support, follow the directions in the "Working with CRYPTOCard Authentication" section.

Authentication via a Token Server Example

To provide better understanding of using token servers with CiscoSecure ACS software, the following example shows the procedure for a user, Hank, who authenticates as an asynchronous user to the network's CiscoSecure ACS:

1. From a remote site, Hank runs remote-access software called CiscoRemote to set up a connection to his primary office in Miami. Within the Connect dialog box of CiscoRemote, Hank is required to enter a username and password. He enters his username, as follows:

User Access Verification
Username: Hank

Note Step 1 can represent a complete authentication process; this method is termed synchronous. Depending on your needs, you can direct users to authenticate by means of an asynchronous method; this requires an additional transaction specified in step 3. Refer to your Secure Computing documentation to set up synchronous or asynchronous authentication.

2. The CiscoSecure ACS detects that Hank is dialing in by means of a token card and issues a challenge and a subsequent field for the challenge response:

User Access Verification
Username: Hank
Challenge: 5128
Enter Response:

3. Hank takes up his token card again. He enters a secret PIN number, then enters the challenge number which will be translated into the response number:

User Access Verification
Username: Hank
Challenge: 5128
Enter Response:From the token card

This challenge-response password represents the final verification needed to authenticate Hank to the CiscoSecure ACS.

Corresponding Administrator Requirements

Based on the previous scenario, before the user Hank can attempt a remote connection, the administrator must first:

1. Confirm that SafeWord Server software or Secure ID ACE/Server is loaded.

Note Depending on how you configured the token card server software, you would have specified that users authenticate in synchronous or asynchronous mode. While the previous scenario shows the asynchronous mode, users in synchronous mode perform the same procedure but are not prompted for a challenge number.

2. Confirm that Hank's account is configured through the CiscoSecure ACS GUI so that he is required to use the DES Gold Card. In this case, the AAA database would be modified to display something like the following:

user = Hank {
password = Enigma
}

In this case, Hank would be required to give a different DES Gold Card password every time he logs in.

Authenticating One-Time Password Cards via PPP

If you configured the profile to use a token passcode (a secure username) and to use the Point-to-Point Protocol (PPP) with the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) for remote-node login, the user of that profile must supply the passcode in the username field in the format:

username* passcode

For example, consider a user profile called Joe. If you configure Joe's profile for Service-PPP, Password-PAP, and Password-crypto, Joe needs to enter the passcode in the User Name field in the following format:

Figure 12-2 Sample Login Screen for Profile Configured for Service-PPP (PAP) and Password-Crypto

Note Confirm that PPP users do not enter the token passcode in the password field. Make sure that PPP users enter their token passcodes only in their username fields; also make sure that users separate their individual usernames and token passcodes with the asterisk character (*).

Enter the PAP password in the Password field.

Figure 12-3 Sample Login Screen for Profile Configured for Service-PPP (CHAP) and Password-Crypto

Finally, consider that you configured Joe's profile to authenticate by means of a one-time password card in combination with Service-PPP and Password-CHAP. In this case, Joe needs to enter the passcode in the User Name field and enter the CHAP password in the Password field. Depending on what you specified for the CHAP password, Joe's login screen would look similar to the one shown in Figure 12-3.

Configuring One-Time Password Entry at the Password Prompt via PPP

It is now possible to assign TACACS+ attributes in such a way as to enable PPP and PAP protocol OTP users to log in with more convention entries, entering username at the username prompt and entering the OTP at the password prompt. For example:

username: pameagan
password: 546323

Using the Java-based CiscoSecure Administrator advanced configuration program, configure your PPP and PAP protocol OTP users with TACACS+ attributes.

Use the main options menu to configure your users with TACACS+ attributes (for example: Service-PPP, Password-PAP, Password-crypto).

•But instead of leaving the value for Password-PAP blank, specify a dummy password string.

•When your users log in, they will enter their username on the username line and their OTP on the password line.

Even though you've assigned a dummy string in your users' Password-PAP attribute, they do not enter it during login. In fact, users are not required to know what their dummy string is.

Configuring the NAS for Token Card Support

CiscoSecure ACS support for token card-generated one-time password (OTP) logins requires the host NAS be configured with a minimum 10 second TACACS+ timeout setting:

tacacs-server timeout 10

The default setting of one second will cause OTP logins to fail a large percentage of the time.

Enabling Token Caching

The CiscoSecure ACS token caching feature enables CiscoSecure to cache the one-time password (OTP) of users logging in through a token server, allowing those users to reuse their "one-time-password," for the duration of their original session, a specified length of time, or combination of both. The CiscoSecure ACS token-caching feature can apply to both TACACS+ and RADIUS-enabled network access servers (NASes) and the ACS.

To enable token caching:

Step 1 In the Members page of the Java-based CiscoSecure Administrator advanced configuration program, click the user profile you wish to enable for token caching and click the Profile icon.

Step 2 In the options menu, select server token caching, enter enable in the enable/disable field, and click Apply.

Step 3 In the options menu, select server token caching expire method, enter either session, timeout or both in the expire method field, and click Apply.

•Session—Enter this string to keep the cached password valid for the duration of the original session.

•Timeout—Enter this string to keep the cached password valid for a specified amount of time.

•Both—Enter this string to impose both session and time expiration on the cached password.

Step 4 If you entered either session or both for the server token expire method, select server token caching timeout in the Options menu, enter the time in seconds that you want the cached password to remain valid, and click Apply.

Caution This option can significantly increase time required for the export operation. It could, for example, increase the time required to export an SQLAnywhere database with 3,000 users from minutes to hours.

Working with CRYPTOCard Authentication

This section provides the instructions you need to use the CRYPTOCard token server with your CiscoSecure ACS.

Support for CRYPTOCard is built into the CiscoSecure ACS. However, before remote users can successfully dial in with CRYPTOCard, you need to perform three essential steps:

1. Obtain the physical token cards and issue them to users.

2. Create a CRYPTOCard directory.

3. Either you or the end user must initialize the token cards.

Obtaining CRYPTOCard RB-1 Tokens

To obtain your CRYPTOCard RB-1 token cards, send your request directly to:

CRYPTOCard, Inc. at 1649 Barclay Blvd., Buffalo Grove, IL 60089
Telephone: 847-459-6500 or toll free 1-800-307-7042
Fax: 847-459-6599
e-mail: token@cryptocard.com.
http://www.cryptocard.com/

After receiving your request, a CRYPTOCard representative will quickly refer you to the proper distributor or reseller in your area. CRYPTOCard is free from export controls.

While you are waiting to receive the physical CRYPTOCard RB-1 token cards, you can create a CRYPTOCard directory so that you can establish users within the CiscoSecure ACS database, as described in the next section.

Creating a CRYPTOCard Directory

In order to use the CRYPTOCards, you must establish a unique directory within your CiscoSecure ACS database. This directory will store the names of CRYPTOCard users.

To create a CRYPTOCard directory that can be accessed by the CiscoSecure ACS database:

Step 1 In the /etc directory, create a directory called CC.

Step 2 In the /etc/CC directory, create a file (by using vi or similar text editor), called /ccsecret as shown in the following example:

# vi ccsecret

Step 3 Enter the string 123456 in the text editor and save it as ccsecret.

Step 4 Change directories to move to the directory where you have the CiscoSecure ACS daemon located. For example:

# cd /$base/CSU

This is the directory where all CiscoSecure ACS files are stored. This directory contains two essential files that support CRYPTOCard: initcard and initfile.

Step 5 Enter ./initfile to initialize the token card:

# ./initfile

You are prompted to enter a username. This will be the name of the CiscoSecure ACS user who will authenticate to the CiscoSecure ACS by means of CRYPTOCard.

Step 6 Enter a username of at least 8 alphanumeric characters, for example:

# Enter username (7 or 8 alphanumeric characters): Frank12

You are next prompted to enter a value for Option Field 1, Option Field 2, and Option Field 3. After you enter a value for an option field, you are immediately prompted to enter a value for the next option value field.

Note The CRYPTOCard token has a number of operating parameters that you must set up prior to issuing the physical token cards to users. These parameters are summarized in Table 12-1, Table 12-2, and Table 12-3. They consist of option fields (each containing three digits) that must be entered into the server for each user and then entered into each user's card.

For each option field, you will select three digits from the corresponding range of values shown in parentheses. Use commas to separate values.

Step 7 For the server, enter values for Option Field 1, Option Field 2, and Option Field 3, as shown in the following example (you should record the option values for later reference):

Enter 3 digits for Option Field 1 [(0-3), (1), (0)] 1,1,0

Enter 3 digits for Option Field 2 [(0-3), (0-7), (0-7)] 1,3,5

Enter 3 digits for Option Field 3 [(0-1), (0-7), (1)] 1,0,1

Step 8 After you enter values for the three option fields, the following displays:

Enter the user key, most significant byte first...

You are now asked to enter values that will be used later when you initialize the physical token cards. The user key entered in the database and the user key loaded in the token must be identical. The whole key is 64 bits long, and it is entered as eight fields of 3 octal digits each, with each field representing one byte. Just as you were prompted previously to enter digits from a given range, you will once again enter values. This time, however, you will be prompted for key bytes rather than option fields, as shown in the following example:

Enter the key byte 1 in 3 octal digits (000 to 377) 111
Enter the key byte 2 in 3 octal digits (000 to 377) 111
Enter the key byte 3 in 3 octal digits (000 to 377) 111
Enter the key byte 4 in 3 octal digits (000 to 377) 111
Enter the key byte 5 in 3 octal digits (000 to 377) 111
Enter the key byte 6 in 3 octal digits (000 to 377) 111
Enter the key byte 7 in 3 octal digits (000 to 377) 111
Enter the key byte 8 in 3 octal digits (000 to 377) 111

After entering key byte 8, you are prompted to enter the user ID, as follows:

Enter userid: Frank12

Step 9 Enter PIN: 8888

Step 10 Enter the serial number of the CRYPTOCard, as prompted (the serial number is found on the reverse side of the CRYPTOCard):

# Serial Number: 310104001

At this point, you have completed the process of enabling the CRYPTOCard token card for the user Frank.

The following will display:

File /etc/CC/CCinit is updated for user Frank
Want to update /etc/CC/ccinit for another user? [Y/N]

If you enter Y, you return to step 6 where you can specify another CRYPTOCard user. If you enter N, you return to the UNIX prompt.

Step 11 Enter Y to repeat this process for each user who needs to authenticate to the CiscoSecure ACS by means of CRYPTOCard.

Step 12 Execute the initcard file by entering the following command:

$BASE/CSU/initcard -u Frank12

Initializing the Physical CRYPTOCards

You need to issue a physical CRYPTOCard to each user that you specified in the CRYPTOCard directory from the previous section. Furthermore, you need to initialize each CRYPTOCard, as follows:

Step 1 Press the ON button of the CRYPTOCard.

You see the word "locked" to indicate that the card is ready to be initialized. The cards display this prompt when they are new or when someone has entered a number of incorrect PINs that exceeds the limit.

Step 2 Press the ENT button.

You are prompted for options regarding your preferences for certain operating parameters including PIN Entry Feedback, challenge-response mode, invalid PIN entry limit, minimum PIN length, automatic switch-off timeout and prompt language. The options for operating parameters are shown in Table 12-1, Table 12-2, and Table 12-3.

Table 12-1 CRYPTOCard Option Field 1

Option Field 1
Digit Value
Meaning

First Digit (MSB)

-PIN entry feedback options

0

No PIN entry feedback, PIN is fixed at time of issue

1

PIN entry feedback, PIN can be changed

2

Not valid

3

PIN entry feedback, PIN is fixed at time of issue

Second Digit1

1

Must be set to 1 for CiscoSecure ACS

Third Digit (LSB)

0

Must be set to 0 for CiscoSecure ACS

1 These settings affect the operation of the CiscoSecure ACS as well as the CRYPTOCard RB-1 token. All other settings affect operation of the token only.


Table 12-2 CRYPTOCard Option Field 2 

Option Field 2
Digit Value
Meaning

First Digit (MSB)1

-Authentication Mode and User ID Options

0

Full challenge mode, no user ID required

1

Full challenge mode, user ID required

2

Event synchronous mode, no user ID required

3

Event synchronous mode, user ID required

Second Digit

-Number of PIN Entry Attempts

0

Unlimited number of attempts allowed

1-7

Indicates number of failed attempts allowed before token reverts to `Locked' state

Third Digit (LSB)

-Minimum PIN Length

0

8-digit PIN required

1

Not allowed

2

Not allowed

3-7

Indicates minimum number of digits in PIN

1 These settings affect the operation of the CiscoSecure ACS as well as the CRYPTOCard RB-1 token. All other settings affect operation of the token only.


Table 12-3 CryptoCard Option Field 3

Option Field 3
Digit Value
Meaning

First Digit (MSB)

0

Turn off token after 30 seconds of inactivity

1

Turn off token after 60 seconds of inactivity

Second Digit

Prompt Language

0

English 1

1

English 2

2

French

3

German

4

Italian

5

Portuguese

6

Swedish

7

Spanish

Third Digit

1

Must be set to 1 for the CiscoSecure ACS


Step 3 Enter the 3-digit option fields by pressing numeric keys on the CRYPTOCard keypad followed by the arrow key. The option field values are the same as those entered into the CRYPTOCard database for each particular user. See the following example:

Enter 3 digits for Option Field 1 [(0-3), (1), (0)] 1,1,0 `
Enter 3 digits for Option Field 2 [(0-3), (0-7), (0-7)] 1,3,5 `
Enter 3 digits for Option Field 3 [(0-1), (0-7), (1)] 1,0,1 `

After the arrow key is pressed for each option field, a prompt appears indicating the number of the next option field.

Step 4 When the number 4 appears, press ENT.

The prompt Key1 appears.

Step 5 Enter the same eight 3-digit octal values that you entered in the database; press the arrow key after each entry. See the following example:

Enter the key byte 1 in 3 octal digits (000 to 377) 111 `
Enter the key byte 2 in 3 octal digits (000 to 377) 111 `
Enter the key byte 3 in 3 octal digits (000 to 377) 111 `
Enter the key byte 4 in 3 octal digits (000 to 377) 111 `
Enter the key byte 5 in 3 octal digits (000 to 377) 111 `
Enter the key byte 6 in 3 octal digits (000 to 377) 111 `
Enter the key byte 7 in 3 octal digits (000 to 377) 111 `
Enter the key byte 8 in 3 octal digits (000 to 377) 111 `

The display on the token card should go blank.

Step 6 Press ENT.

The prompt UserID appears.

Step 7 Enter the user ID in the same way as the user key.

In other words, enter the user ID as a series of eight, 3-digit octal values each terminated by the arrow key. Each 3-digit value represents a standard ASCII-designated character and the valid octal values range from 040 to 177.

This includes the uppercase and lowercase alphabet as well as numbers, punctuation marks, and special characters. Leading zeros must be entered explicitly. See the following example:

Enter character 1 (most significant) in 3 octal digits (000 to 377) 106 `
Enter character 2 in 3 octal digits (000 to 377) 162 `
Enter character 3 in 3 octal digits (000 to 377) 141 `
Enter character 4 in 3 octal digits (000 to 377) 156 `
Enter character 5 in 3 octal digits (000 to 377) 153 `
Enter character 6 in 3 octal digits (000 to 377) 071 `
Enter character 7 in 3 octal digits (000 to 377) 067 `
Enter character 8 in 3 octal digits (000 to 377) 040 `

The display on the token card should go blank.

Step 8 Press ENT.

The User ID just entered should appear.

Step 9 Press ENT.

The New PIN prompt should appear on the token display.

Step 10 Enter the PIN that was specified earlier in Step 9 of the "Creating a CRYPTOCard Directory" section.

Step 11 Press ENT.

The prompt Card OK appears.

Step 12 Turn off the card by pressing the ON/OFF key.

The initialization is complete.

For security reasons, the card and the PIN should be sent to the end user separately.

Note For details and related information, refer to CRYPTOCard User Authentication Token - Operation & Systems Guide, which is shipped with the CRYPTOCard.

Using the CRYPTOCard in a Typical Logon Sequence

For the purpose of example, a remote user, Hank will go through the following logon sequence when dialing in to CiscoSecure ACS by means of a CRYPTOCard:

1. Hank turns on the card and sees the PIN? prompt.

2. Hank enters the secret PIN and presses ENT.

The user ID or username appears on the card.

Hank sets up a connection to his primary office using remote access software and enters his username as follows:

User Access Verification
Username: Hank

3. The CiscoSecure ACS detects that Hank is dialing in by means of a token card and issues a challenge and a subsequent field for the challenge response.

The challenge is a string of 5 to 8 digits displayed on Hank's computer, as follows:

User Access Verification
Username: Hank
Challenge: 12345678
Enter Response

4. Hank presses ENT on his token card and then proceeds to enter the challenge number in the card. At the end, he presses ENT to generate a challenge response, which he transcribes into the Response field of his remote access software as follows:

User Access Verification
Username: Hank
Challenge: 12345678
Enter Response: 34567890

This challenge-response password represents the final verification needed to authenticate Hank to the CiscoSecure ACS.

Working with S/Key Authentication

The S/Key one-time password system from Bellcore provides secure authentication over networks that are subject to eavesdropping. S/Key prevents the user's secret password from ever crossing the network during authentication. Because S/Key is easy to integrate, many security-sensitive networks use it as their password security system.

S/Key user passwords are assigned through S/Key utilities.

Within the Java-based CiscoSecure Administrator advanced configuration program, you can configure a user profile to incorporate an assigned S/Key password, set a time limit on that password, and specify the CiscoSecure privilege level (user, group administrator, or system administrator) to which the password allows access.

S/Key Example Login

The following example shows the procedure for a user, identified as Sue, who authenticates to the CiscoSecure ACS NAS:

1. In response to the standard prompt for authentication, Sue identifies herself to the NAS:

User Access Verification
Username: sue
s/key 97 fr09072
Password:

CiscoSecure ACS observes that Sue needs to supply an S/Key password.

2. CiscoSecure ACS then issues a challenge including the sequence number of the one-time password expected and a "seed." The seed is a special value used by the S/Key algorithm as the starting point for the creation of an S/Key password. This seed will also allow Sue to securely use a single secret password.

Based on the verification display, CiscoSecure ACS instructed the NAS to display the sequence number, 97, and a seed, fr09072, which will be used by a separate program to initiate the encryption process leading to an S/Key password.

Sue notes the sequence number and seed, then pauses from her interaction with the NAS in order to generate a password. She will generate the password by entering the sequence number and seed, along with her secret password, into an S/Key calculator program.

3. Sue enters 97 and fr09072 into her S/Key calculator program at the UNIX prompt, as shown in the example display. (On UNIX, the S/Key calculator program is called key.)

% key 97 fr09072
Enter secret password: <secret_password>

The secret password is any string of at least 10 alphanumeric characters generated by Sue, for Sue, and known only by Sue.

4. The secret password triggers the creation of a second password, as follows:

CRAG BAKE MOLT JEAN JIBE OFT

The one-time S/Key password is always expressed as a sequence of six short English words. Note how the one-time password is generated without any secret information crossing the network.

This second password will be used to authenticate Sue to the CiscoSecure ACS. Sue now returns to her interaction with the NAS. She enters the S/Key password and is authenticated, as follows:

Password: CRAG BAKE MOLT JEAN JIBE OFT

5. The next time Sue attempts network access, she will be prompted for the one-time password sequence number 96. The sequence number is one less than what was used for the previous authentication. In the case of Sue, her last sequence number was 97, so the next required sequence number will be 96. When the sequence number reaches 0, Sue will not be able to log on without reinitializing the S/Key system.

Setting Up a CiscoSecure User for S/Key Use

Use the Java-based CiscoSecure Administrator advanced configuration program to incorporate a user's S/Key assignment into CiscoSecure.

In Figure 12-4, the CiscoSecure Administrator settings specify the time period during which CiscoSecure ACS allows Sue to login to the network with her S/Key generated password.

Figure 12-4 S/Key Time Period Specification

In Figure 12-5, the CiscoSecure Administrator settings specify the CiscoSecure privilege level that user Sue is granted after she inputs the correct S/Key-generated passwords.

Figure 12-5 S/Key Privilege Level Specification

In this case, Sue would be required to give a different S/Key password every time she logs in and every time she enables at level 15.

Follow the procedures in the next section, " Establishing S/Key Users" to set up the actual S/Key passwords that your users will use.

Establishing S/Key Users

After setting up your CiscoSecure users for S/Key usage (see " Setting Up a CiscoSecure User for S/Key Use"), take the following steps to prepare to install and use S/Key:

Step 1 Start the CiscoSecure ACS by entering the startup command:

# /etc/rc2.d/S80CiscoSecure

Step 2 Instruct the S/Key users to run the keyinit program (detailed in the next step) on the CiscoSecure ACS. Alternatively, you can run the keyinit program for each S/Key user (detailed later in this step).

The keyinit program initializes the S/Key system for that user.

If you want S/Key users to run keyinit, first confirm that all S/Key users have UNIX accounts on the system from which they are running keyinit and the CiscoSecure ACS daemon. In addition, you should inform the S/Key users about the following points prior to running keyinit:

•When running keyinit, each user will be prompted for two passwords. The first is the UNIX logon password. The second is the secret password used with S/Key.

•For security purposes, the UNIX password and the secret password should not be the same.

•The secret password must be at least 10 characters.

Note The command line options for the S/Key utilities are found on the man pages included in the file skey-cs.tar, available at the Cisco web page: http://www.cisco.com/cgi-bin/tablebuild.pl/ciscosecure

As an option to having users initialize their own S/Keys, you can initialize their S/Keys for them. As an administrator logged in as root, you can initialize S/Key passwords for established users by entering the following command:

# keyinit username

In the next step, each S/Key user will run the keyinit program to initialize the S/Key system for that user.

Step 3 Have the CiscoSecure ACS users who will use S/Key enter the keyinit command at the UNIX prompt, as in the following examples for the user Sue:

% keyinit
Password: <UNIX password>
[Adding sue]
Enter secret password: <secret password>

When the keyinit program asks Sue for a secret password, she can supply any mix of 10 or more alphanumeric characters.

Again secret password: <secret password>

ID sue s/key is 99 fr05065
Next login password: SKI INCA HONE NEE MESS LEAF

Now Sue can use S/Key with the CiscoSecure ACS software.

S/Key also accounts for previous iterations of keyinit, providing assurance for the user that someone has not altered the system. As a result, the next time that Sue enters the keyinit command, she will see a display similar to the following:

% keyinit
Password: <UNIX password>
[Updating sue]
Old key: fr05064
Enter secret password: <secret password>

Again secret password: <secret password>

ID sue s/key is 99 fr05065
Next login password: SKI INCA HONE NEE MESS LEAF

Note When Sue enters her secret password, she is entering a personal identification number in order to generate another password. The secret password could be the same as her UNIX password, or it might be any string of characters. This secret password does not change. Sue, as an S/Key user, must remember her S/Key password in order to generate the second password used for S/Key authentication to the CiscoSecure ACS.

Working with SecurID Authentication

To use CiscoSecure ACS with the SecurID ACE/Server, you must purchase and install SecurID ACE/ Server software and obtain SecurID one-time-password tokens. This section summarizes setup information for a SecurID server and client to function with CiscoSecure ACS. However, always refer to the documentation that came with your SecurID ACE/Server software for details or questionable procedures.

About the SecureID ACE/Server

During the installation of your ACE/Server software, if you elect not to use the Secure Dynamics, Inc. (SDI) default directory name recommended by the SDI installation documentation, then you must set up the /etc/sdace.txt directory as described in the following procedure.

During the installation of the SDI ACE/Server software, you will have configured a way to resolve host names and services. The following installation prompt will have been displayed:

Do you want to resolve hosts and services by name?

•If you responded no—the client, server, and administrator will not use the /etc/hosts file, /etc/services file, or name server to resolve the names of servers and services.

•If you responded yes—the names are resolved at run time through the /etc/hosts file, /etc/services file, or information service.

Depending on how you elected to resolve hostnames and services, follow these steps:

Step 1 Make sure that the /etc/hosts file has the name of the SDI ACE/Server and that the SDI ACE/Server /etc/hosts file has the name of the CiscoSecure ACS (the CiscoSecure ACS acts as the client to the ACE/Server).

Step 2 Make sure that the definition "securid 5500/udp" found in the /etc/services file of the ACE/Server, is the same as the /etc/services file of the CiscoSecure ACS.

Step 3 Copy the sdconf.rec file from the ACE/Server to the CiscoSecure ACS. This file might be in the default directory /sdi/ace/data, or a directory that is established while installing the SDI ACE/Server software. In either case, make sure that the file is copied to the same path used during the ACE/Server software installation. You can specify the location of the sdconf file to the CiscoSecure ACS (the libsdi.so library) in one of two ways:

•Set up the environmental variable VAR_ACE to access the directory that libsdi.so can access to find the sdconf.rec file.

•Include this same VAR_ACE record in a file named /etc/sdace.txt (a fixed name for libsdi.so to search for in case the environmental variable is not found). In this way, the SDI library software in CiscoSecure ACS will search for the environmental variable VAR_ACE first; if not found, it will next search in the /etc/sdace.txt file for the VAR_ACE definition. If found, the SDI library software in CiscoSecure ACS will then set up an environmental variable. (Otherwise, if the environmental variable cannot be found, the library cannot continue and will fail with an error in syslog.)

ACE/Server Setup

This section summarizes the CiscoSecure ACS configuration for ACE/Server setup.

Step 1 Run sdadmin.

Step 2 Use the Add Client option to add the CiscoSecure ACS to the client list.

Step 3 Select the User Activation check box.

Note Set "VAR_ACE=/sdi/ace/data" if the default directory was selected during the installation of the ACE/Server software; otherwise set "VAR_ACE=/xxx/ace/data" where xxx is the root path where the ACE/Server software was loaded.

When the first authentication takes place from the CiscoSecure ACS to the ACE/Server, the ACE/Server sends the node secret file to its client, the CiscoSecure ACS. The application programming interface of the CiscoSecure ACS stores this node secret file in the same directory as the sdconf.rec file. The name of this node secret file corresponds to the name used in the /etc/services file to associate a name, port number, protocol, and alias name to a service.

For example, if you set up a service name of "eatabug 5566/udp," then the name of the secret node file on the client (the CiscoSecure ACS) will be "eatabug." This name is in the sdconf.rec file so the SDI API can function.

Note The directory that is set up to store the node secret file must have proper read/write permission by anyone to ensure that when the secret is passed, the node secret file can be created without a permission error by libsdi.so.

When you run the sdadmin program, use the Add Client option to add the CiscoSecure ACS to the client list. Also, enable the User Activation option to ensure that all users configured on the ACE/Server are granted access to the CiscoSecure ACS.

The sdconf.rec file is encrypted and this is why the CiscoSecure ACS installation does not attempt to recreate this record based on queries and answers from the user during installation. To ensure that the client is working properly with the sdconf.rec file of the SDI ACE/Server, you must copy sdconf.rec to the specified directory of the CiscoSecure ACS during installation.

If you need to set up CiscoSecure on a ACE/Server for Windows NT, go to the next section.

ACE/Server for Windows NT Setup

Before you configure CiscoSecure ACS for UNIX with ACE/Server for Windows NT, first make sure these conditions are met:

•Install the ACE/Server for Windows NT according to instructions in the SDI ACE/Server installation manual.

•Make sure the ACE/Server's hosts file has the CiscoSecure's host name (case sensitive). If the CiscoSecure server is multi-homed, make sure that you have all necessary host names and IP addresses exactly as they are written to the CiscoSecure ACS.

Then take the following steps:

Step 1 Install the ACE/Server client on the CiscoSecure ACS from the ACE/Server CD-ROM making sure to do these things:

a. From the aceclnt/sol/ directory on the CD-ROM, copy sol_clnt.tar to a temporary directory on your hard disk.

b. From the temporary directory, enter:

tar -xvf col_clnt.tar

c. Enter:

./sdsetup -client

d. Follow the prompts to install the client software. Choose / as the directory to install.

Step 2 Copy the sdconf.rec file from the ACE/Server located in /ace/data to the CiscoSecure machine /ace/data. This is the same directory structure created on the CiscoSecure machine during the client installation.

Step 3 From /ace/prog, enter: ./sdinfo to see what the client name is and what IP address is selected. For example:

Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997 by
Security Dynamics Technologies Inc.
ACE/Server v 2.3

---ALL RIGHTS RESERVED---

Client Configuration


ACE/Server VERSION: v 2.3 [011]
Config File Version: 7
CLIENT RETRY: 5 times
CLIENT TIMEOUT: 5 sec
DES ENCRYPTION: enabled
MASTER SERVER: HAL1
MASTER SERVER ADDRESS: 10.8.0.3
CLIENT NAME: TheRock
CLIENT ADDRESS: 171.69.188.235
SLAVE SERVER: not configured
AUTHENTICATION SERVICE: securid
PORT NUMBER: 5500
ADDRESSES: By IP address in ACE/Server database

Step 4 On the client (the CiscoSecure ACS), add the ACE/Server to the host's file.

Step 5 Create the client on the ACE/Server:

a. Run the ACE/Server Database Administration software.

b. Click Client.

c. Click Add Client.

Note Make sure to use the client name displayed when you invoked sdinfo in Step 3.

d. Client OK. You should see the IP address, which should match the one shown in sdinfo.

Step 6 If the client is multi-home, do this:

a. Click Secondary Nodes.

b. Type the host name for the other interface (found in the host's file on the client). For example:

TheRock# more hosts
#
# Internet host table
#
127.0.0.1 localhost
171.69.188.235 TheRock loghost
171.69.188.231 sunfreak
10.8.0.1 therock-prv
10.8.0.3 HAL1

c. Click OK. The IP address should be displayed.

Step 7 Add users as you normally would on the ACE/Server Database Administration GUI.

Note Make sure the user is activated on the client.

Configuring Users for Secure Computing Token Card Use

If you have configured the CiscoSecure ACS to support the Secure Computing token card, you can use the CiscoSecure ACS SafeWord Profile web page to configure CiscoSecure users for Secure Computing token card authentication. After you configure a user for Secure Computing token card authentication through CiscoSecure ACS, that user is configured for both CiscoSecure and SafeWord. No further configuration of that user is necessary.

Caution The SafeWord Token Card server must be installed before the CiscoSecure ACS is installed or configured.

Setting a User's Initial SafeWord Configuration

To initially configure a user's SafeWord profile, you need to enable access to that user's SafeWord configuration pages.

Step 1 In the CiscoSecure ACS Edit a User or Add a User web page, click More to display the Enigma authorization option.

Step 2 Select Enigma and click Add or Save to save the profile.

Step 3 When you are prompted to configure the SafeWord profile, click Continue to display the current user's SafeWord Profile page.

Step 4 Edit the SafeWord Profile page as necessary.

The the SafeWord Profile fields include:

•UserID—The SafeWord profile user ID. The system generates the SafeWord user ID by copying the user's CiscoSecure user ID and modifying it, if necessary, to conform to SafeWord user ID requirements.

You can make additional modifications to this ID. See your SafeWord documentation for SafeWord constrictions.

•Group—The user group, if any, to which the current user belongs. This should not be changed.

•User Name—An arbitrary name that you can assign to the user for reference purposes.

•Comment—Any comment that you can insert for reference purposes.

Step 5 Click Next to display the SafeWord Menu page.

The following options are displayed.

•Authenticators—Click this option to display the SafeWord Authentication Controls dialog box. (See the "Configuring a User's SafeWord Authentication Method" section for details.)

•Access—Click this option to display the SafeWord Access Controls dialog box. (See the "Configuring a User's SafeWord Access (Authorization)" section for details.)

•Alias—Click this option to display the SafeWord Alias dialog box. (See the "Configuring a User's SafeWord Aliases" section for details.)

Editing a User's Existing SafeWord Configuration

To edit a user's existing SafeWord configuration, use the Edit Enigma Token button on the user's Edit a Profile web page.

Step 1 Bring up the user's CiscoSecure ACS Edit a User web page.

If a SafeWord profile has already been configured for that user, the Edit Enigma Token button is displayed.

Step 2 Click the Edit Enigma Token button to display the current user's SafeWord user ID (the CiscoSecure user ID, modified, if necessary, to conform to SafeWord user ID requirements).

Step 3 Make any additional desired changes to the SafeWord user ID (check your SafeWord documentation for constrictions) and click Next to display the SafeWord Profile web page.

Step 4 Edit the SafeWord Profile page fields as necessary.

The fields include:

•Group—The user group, if any, to which the current user belongs. This should not be changed.

•User Name—An arbitrary name that you can assign to the user for reference purposes.

•Comment—Any comment that you can insert for reference purposes.

Step 5 Click Next to display the SafeWord Menu page.

The following options are displayed:

•Authenticators—Click this option to display the SafeWord Authentication Controls dialog box. (See the "Configuring a User's SafeWord Authentication Method" section for details.)

•Access—Click this option to display the SafeWord Access Controls dialog box. (See the "Configuring a User's SafeWord Access (Authorization)" section for details.)

•Alias—Click this option to display the SafeWord Alias dialog box. (See the "Configuring a User's SafeWord Aliases" section for details.)

Configuring a User's SafeWord Authentication Method

Using the user's SafeWord Authenticators page, you can specify one or more SafeWord authentication methods to apply to the user profile, the order in which the authentication methods are applied, and the parameters for that method.

To configure an authentication method:

Step 1 Access the SafeWord Authenticators page as described in the "Setting a User's Initial SafeWord Configuration" section.

Figure 12-6 SafeWord Authenticators Page

Step 2 In the Authenticator 1 field, configure either the Fixed Password, DES - Gold, DES - Silver, or None as the authentication method.

•To configure a Fixed Password, select FixPwd and click the Configure button to the right. In the SafeWord Fixed Password page, specify the following settings. Click Next when finished:

Table 12-4 Configuring a Fixed Password

Device Enabled

Enables or Disables the fixed password requirement for the current user.

Password

The fixed password string for the current user.

Min Password Length

Specifies a minimum character length requirement for the current user's fixed passwords.

Max Password age (in days)

Specifies the maximum number of days through which the current fixed password is valid.

Number of previous passwords to remember

Specifies the number of previous passwords for SafeWord to retain in memory. The current user will not be able to reuse previous passwords as long as they remain in SafeWord memory.


•To configure a DES Gold authentication method, select DES-Gold and click the Configure button to the right. In the SafeWord DES Gold page, specify the following settings and click Next when finished:

Table 12-5 Configuring a DES Gold Authentication Method

Device Enabled

Enables or Disables the DES Gold authentication method for the current user.

Password Length

Specifies the length of the password needed to verify a User ID.

Challenge Length

Specifies the length of a challenge needed to generate a password. This does not apply to Tokens that need on challenge.

Key

Specifies the number that the SafeWord administrator assigns to uniquely identify the current user's Token.

Card Host No.

Specifies the host number necessary to support Token synchronization with multiple hosts.

X9.9 Host No.

Specifies the x9.9 host number, if the Token supports X9.9 mode.

ASCII Input for X9.9

Enables or disables ASCII input to a X9.9 device.

Asynchronous/Synchronous

Specifies asynchronous or synchronous password generation.

Normal/Friendly/Decimal

Specifies Token display mode: Normal (hexadecimal), Friendly (modified hexadecimal) or Decimal.


•To configure a DES Silver authentication method, select DES-Silver and click the Configure button to the right. In the SafeWord DES Silver page, specify the following settings and click Next when finished.

Table 12-6 Configuring a DES Silver Authentication Method

Device Enabled

Enables or Disables the DES Silver authentication method for the current user.

Password Length

Specifies the length of the password needed to verify a User ID.

Key

Specifies the number that the SafeWord administrator assigns to uniquely identify the current user's Token.

Normal/Friendly/Decimal

Specifies Token display mode: Normal (hexadecimal), Friendly (modified hexadecimal) or Decimal.


•To temporarily disable all authentication methods for the current user, select None.

Step 3 If you want to apply more than one authentication method to the current user, assign an authentication method to the Authentication 2 and Authentication 3 fields.

Step 4 If you configured more than one authentication method for the current user, use the Combinations: first field to specify the order in which to apply these authentication methods.

Step 5 You can also specify a second and third combination of authentication methods in the second and third fields. If you specify combinations in the second and third fields, the user will be asked which authenticator combination to use at login.

Step 6 Click Next to return the current user's SafeWord Menu page.

Configuring a User's SafeWord Access (Authorization)

Using the user's SafeWord Access page, you can specify the time conditions under which the user can access the network, set attack lock thresholds, set privilege levels, and set actions to be executed in event of login success or failure.

Step 1 From the user's CiscoSecure profile page, access the SafeWord Access page as described in the "Setting a User's Initial SafeWord Configuration" section.

Figure 12-7 SafeWord Access Page

Step 2 Edit the settings as necessary. The SafeWord Access fields are described in Table 12-7.

Table 12-7 SafeWord Access Fields 

Field
Description
Attack Lock Fields
 

Attack Lock Enabled

Enables or disables the SafeWord attack lock feature. Select this checkbox to lock the current user's account in the event of repetitive failed logins, most likely triggered by a software attack engine.

Attack Status

Indicates and toggles the On/Off status of the SafeWord attack lock feature. If the status is On the attack lock has been activated, and the current user is locked out. Click Off to enable the user to log in.

Access Quota Fields
 

Access Quota

Enables or disables the SafeWord Access Quota feature. Select the check box to limit the number of logins allowed the current user.

Quota Remaining

Indicates and sets the number of allowable logins remaining to the current user if the Access Quota feature is enabled. Enter the number of logins you wish to allow the current user before locking the account. You can reset this number at any time. If the Access Quota checkbox is selected, SafeWord will decrement the number in this field by one each time the current user logs in and will lock the account if the Quota Remaining number reaches zero.

Privileges
 

Supervisor

Grants the current user SafeWord Supervisor privileges.

Auditor

Grants the current user SafeWord Auditor privileges.

Import/Export

Grants the current user the privilege to invoke SafeWord Import/Export utilities.

User Database

Grants the current user the privilege to edit the SafeWord database records of users in their group.

Default

Grants the current user the privilege to edit the default SafeWord record template for the user's group.

View Database

Grants the current user the privilege to view the SafeWord database records of the users in their group.

Create Access

Grants the current user the privilege to create an Access Log of users in their group.

Attack Status

Grants the current user permission to toggle Attack Statuses to Off, in the event that a login attack locks user accounts.

Locks

Grants the current user permission to edit attack lock settings on user accounts.

Pass/Fail Action Status
 

Exit with Status

This option specifies a status number to be returned to the user when the user has been granted or denied access. Select this option, click Configure, enter a status code number, and click Next.

Execute Program

This option specifies a program to invoke in event of the user being granted or denied access. Select this option, click Configure, enter the path and file name of the executable program, enter any parameters in the Executable Program dialog box, and click Next.

Multiple Hosts

This option specifies actions to be carried out when specific hosts are successfully or unsuccessfully accessed. Select this option, click Configure, enter the Host Name and a startup shell, a binary executable file, or shell script in the Multiple Hosts dialog box, and click Next. You can also enter default for the host name to apply the associated action to all unspecified hosts.

Service Allowed

This option specifies the services that can be accessed when the current user is granted or denied access. Select this option, click Configure, enter the Host Name and any command lines in the Services dialog box, and click Next.

Time Lock Fields
 

Time Lock

Enables or disables the SafeWord time lock feature for the current user. Select this option to lock the current user from logging in to the network during specified hours.

Start Time

Sets the start time of user lockout.

End Time

Sets the end time of user lockout.

Date Lock Fields
 

Date Lock

Enables or disables the SafeWord date lock feature for the current user. Select this option to lock the current user from logging into the network during specified dates.

Start Date

Sets the start date of user lockout.

End Date

Sets the end date of user lockout.

Week Lock Fields
 

Week Lock

Enables or disables the SafeWord week lock feature for the current user. Select this option to lock the current user from logging into the network during specified days of the week.

Mon, Tues, Wed, Thur, Fri, Sat, Sun

Select the days of the week that you want the current user to be locked out of the network.


Step 3 Click Next to return the current user's SafeWord Menu page.

Configuring a User's SafeWord Aliases

Using the user's SafeWord Aliases page, you can specify the alternative names under which the current user can log in to the network.

To configure a user's alias:

Step 1 From the current user's CiscoSecure profile page, access the SafeWord Aliases page as described in the "Setting a User's Initial SafeWord Configuration" section.

Figure 12-8 SafeWord Aliases Page

Step 2 If you want to add a new alias, enter the alias in the text box in the Aliases dialog box and click Add.

Step 3 If you want to delete an existing alias, select the alias from the list box in the Aliases dialog box and click Delete.

Step 4 Click Next to return to the current user's SafeWord Menu page.

Enabling Group Administrator Access to the SafeWord Configuration Pages

When CiscoSecure is installed, only users with system administrator privilege can access the CiscoSecure ACS SafeWord Profile, SafeWord Authenticators, SafeWord Access, and SafeWord Aliases web pages.

The system administrator can grant users with group administrator privilege access to these pages by editing the turbo.conf file on the CiscoSecure ACS.

To enable group administrator access to the SafeWord configuration pages:

Step 1 Log in as [Root] to the SPARCstation where you installed CiscoSecure ACS.

Step 2 Locate the turbo.conf file in the ../FastAdmin directory of the CiscoSecure ACS.

Step 3 Using a text editor, open the turbo.conf file, locate the GroupAdminAllowed= parameter in the [SafeWord] section, and set it to yes, for example:

[SafeWord]
isInstalled=yes
GroupAdminAllowed=yes

Step 4 Save the changes and close the turbo.conf file.

Step 5 To effect the turbo.conf changes, invoke the script files to down and restart the CiscoSecure ACS from the SPARCStation's UNIX command line.

a. To stop the CiscoSecure ACS, enter:

# /etc/rc0.d/K80CiscoSecure

b. To restart the CiscoSecure ACS, enter:

# /etc/rc2.d/S80CiscoSecure

Using CiscoSecure's Token Card Support with RADIUS

Under most circumstances, the CiscoSecure ACS should support use of RADIUS with token cards. However, if you experience problems with the password—for example, if the program prompts you for the password 2 or more times—then you should try creating a new attribute to handle the problem, as follows:

Step 1 Create a new RADIUS dictionary by copying the Cisco RADIUS dictionary to a new file and giving it a new name.

Step 2 Create a new attribute, Cisco-Token-Immediate, in the new RADIUS dictionary. This attribute should have the same format as the Ascend-Token-Immediate attribute in the Ascend dictionary:

attr=200, type=enum...

Step 3 Change the NAS profile(s) so that they are directed to use this new dictionary instead of the default Cisco dictionary.

Step 4 In the user profile(s), add a Cisco-Token-Immediate attribute to the check items with an enum value of Tok-Imm-Yes.

Note This procedure will work with any token card that doesn't issue a challenge to the user.

Adding Token Card Support After Installing CiscoSecure ACS

The easiest way is to specify which token cards you want to support during the installation of CiscoSecure ACS. However, if you declined to specify token card support when you initially installed CiscoSecure ACS, you can still add support for Secure Computing (formerly Enigma Logic) or Security Dynamics (SDI) token cards by editing a configuration file, as described in the following steps.

Step 1 Locate the CSU.cfg file as shown in the following example:

ciscosecure-sun% cd $BASEDIR (where $BASEDIR is the directory where CiscoSecure ACS is installed)
ciscosecure-sun% ls
CSU DOCS bin config logfiles odbc utils
DBServer SYBSsa50 classes java ns-home sybase
ciscosecure-sun% cd config
ciscosecure-sun% ls
CSConfig.ini CSU.cfg DefaultProfile

Step 2 Make a copy of the CSU.cfg file. You can use this copy in case problems arise after editing the file.

Step 3 Use a text editor, such as vi, to edit the CSU.cfg file:

# vi CSU.cfg

Step 4 Update the CSU.cfg for one of the following supported token card servers:

•Security Dynamics—To add support for token cards from Security Dynamics, add the following lines to the CSU.cfg file after the AUTHEN statement as shown below:

AUTHEN config_external_authen_symbols = {

{

"./libsdi.so",

"sdi"

}

,

}

Note Be sure that the ACE/Server client is installed and running before you modify the CSU.cfg file for your Security Dynamics server.

•Secure Computing—To add support for token cards from Secure Computing, Inc., add the following lines to the CSU.cfg file after the AUTHEN statement as shown below:

AUTHEN config_external_authen_symbols = {

{

"./libenigma.so",

"enigma"

}

,

}

You must also update the libenigma.conf file located in $BASEDIR/CSU. The libenigma.conf file must contain the IP address of the Safeword Server, for example:

02 SafeWord Authen. Server Name: xxx.xxx.xxx.xxx 0 0 7482

where xxx.xxx.xxx.xxx is the server's IP address.

Step 5 Save the file and exit from your text editor.

Step 6 Stop CiscoSecure ACS by entering the following command:

# /etc/rc0.d/K80CiscoSecure

Step 7 Restart CiscoSecure ACS by entering the following command:

# /etc/rc2.d/S80CiscoSecure

Support for the token cards you specified is now available.

Step 8 Modify the TACACS+ timeout setting on any NAS host that your token card users will be logging in through to a minimum 10 seconds.

Send the following command to the NAS:

tacacs+ timeout 10

hometocprevnextglossaryfeedbacksearchhelp

Posted: Wed Feb 16 09:48:45 PST 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.