Chapter 22
This chapter describes how to manage the TCPware Access Control Encryption (ACE) Client (ACE/Client) and how to set up user accounts in the Security Dynamics ACE/Server.
The TCPware Token Authentication system consists of Security Dynamics Corporation's Access Control Encryption Server (ACE/Server) authentication software running in a trusted environment and TCPware ACE/Client software on devices that are to be protected by SecurID authentication. A backup server that provides backup authentication services if the main server is not running, administration software, and audit trails are part of the server environment.
Security Dynamics' SecurID smart card and ACE/Server software produce a two-factor authentication process that can provide an effective, secure environment. The SecurID smart card contains a microprocessor that generates and displays a new, unpredictable password (card code) every 60 seconds. The card displays this unique password, which is different for each card, on a liquid crystal display. Each card is programmed with a unique seed number and Security Dynamics' powerful proprietary algorithm.
The following TCPware components and OpenVMS functionality use the TCPware ACE/Client to authenticate a user before allowing access:
|
FTP-OpenVMS |
TELNET-OpenVMS |
|
RLOGIN command |
SET HOST command |
The TCPware ACE/Client is designed to do the following:
• Monitor and control token-holders
• Authenticate for interactive logins
• Authenticate based on network logins
• Authenticate based on remote logins
Special terms used in this chapter include:
|
ACE/Client |
Computer or other device that is protected by the ACE/Server to prevent unauthorized access. Designated users of this computer must provide a valid SecurID PASSCODE in order to log in. |
|
ACE/Server |
Security Dynamics Corporation's authentication software running on a TCP/IP networked UNIX machine, providing authentication, administration, and audit trail services. |
|
CERT |
Computer Emergency Response Team. |
|
PASSCODE |
User's PIN plus the tokencode displayed in the SecurID token. |
|
PIN |
User's Personal Identification Number. The PIN is one factor in the Security Dynamics authentication system. |
|
sdadmin |
Program used on the main server to administer the ACE/Server system. |
|
sdconf.rec |
ACE/Server configuration file that contains information about the server that is distributed to the ACE/Clients. The ACE/Clients must have this file on their system in order to determine what parameters are needed to establish communication with the server. |
|
SDI Encryption |
Security Dynamics' proprietary encryption. |
|
securid. |
Node secret file that contains a random string only known between the client and server. Along with other information, securid. is used to encrypt and decrypt messages between the client and server. |
|
token |
Device that displays a SecurID tokencode. It may be a standard SecurID Card, a SecurID Key Fob, or a SecurID PINPAD card. The token is one of the factors in SecurID two-factor authentication. The other factor is the user's PIN. |
|
two-factor authentication |
Authentication method used by the ACE/Server in which the user must enter a secret, memorized personal identification number (PIN) and the current code generated by the user's assigned SecurID token. The PIN and tokencode make up the PASSCODE. |
See the following documents for more information:
ACE/Server v2.2 Administration Manual, August 1996
ACE/Client for OpenVMS v1.0, December 1995
ACE/Server v2.2 Installation Guide, August 1996
Developers' Guides to the ACE/Server v2.2 Database and Client API, August 1996
ACE/Server Client Implementation Guide, August 26 1996.
Security Dynamics SecurID FAQ, http://www.securid.com/service/FAQs/
To administer the ACE/Server functions, use the sdadmin program, which you can run either in graphical interface mode or in character mode. To use graphical interface mode, go to the proper directory location of the program on the server machine, and enter the following:
# directory-path/sdadmin
To use character mode, enter the following:
# directory-path/sdadmin -c
Note! See Security Dynamics' ACE/Server Administration Manual for full details on server administration. The following is only a review of the functions.
The following is a sequence of steps on the server:
|
Step |
Action |
Description |
|
1 |
Add token records to a new ACE/Server database |
From the Token pull-down menu, select Import Tokens, enter the path and filename of the token records file, and select List Tokens to verify. |
|
2 |
Create clients |
From the Client pulldown menu, select Add Client and add a client. To duplicate information activation information from one client to another, use the Copy Client selection. Repeat this as often as needed. |
|
3 |
Create groups |
From the Group pulldown menu, select Add Group and add a group (this is optional but useful) along with its members (although you can do this later). To duplicate information activation information from one group to another, use the Copy Group selection. Repeat this as often as needed. |
|
4 |
Set system PIN parameters |
From the System pulldown menu, select System Parameters and set the PIN parameters such as whether to allow alphanumeric or just numeric PINs, if they should all be the same character length, and whether the system generates them or the user can generate them. |
|
5 |
Create users and assign tokens to them |
From the User pulldown menu, select one of the following: Add User, Edit User, or Copy User to create users (this is also where you can determine group membership). |
The server administrator's responsibilities also includes distributing tokens to users and educating them about their security responsibilities (such as keeping PINs secret and securing and protecting their tokens).
The server administrator can also monitor the authentication process on the server and generate reports using sdadmin. Do this from the Report pulldown menu and by selecting Activity. Enter the parameters for the report and select OK. You can also log statistics.
The logicals listed in Table 21-1 define the ACE/Client environment.
Table 22-1 ACE/Client Logicals (Continued)
If there is a malfunction with the TCPware ACE/Client or if the main ACE/Server and the backup ACE/Server are not running and the TCPware ACE/Client is enabled, users who are designated for Token Authentication are not allowed access to the system. To disable the TCPware ACE/Client, perform the following command:
$ @TCPWARE:SHUTNET ACECLIENT
If you wish to disable the TCPware ACE/Client but cannot log in the system to do so, use the console to login. The console should be in a secure area and login is granted if the user password is correct. It does not prompt you for the PASSCODE:. Once you are logged in, you can disable the TCPware ACE/Client with the command described.
If you do not have a console, shut down the system and perform a minimum reboot. Log in and run CNFNET to disable the TCPware ACE/CLIENT for your particular configuration by responding with NO to the following prompt:
Do you want to use the TCPware ACE/CLIENT to authenticate user login ? NO
In the event that you cannot disable the TCPware ACE/Client using SHUTNET, you can do the following to manually disable it:
• Check the system, executive logical LGI$CALLOUTS to make sure that it does not include the TCPWARE_ACECLIENT_CL logical in its definition. If it does, redefine LGI$CALLOUTS to exclude TCPWARE_ACECLIENT_CL.
• Check the SYSGEN parameter LGI_CALLOUTS to make sure that it represents the correct number of shareable images as shown in the system, executive logical LGI$CALLOUTS. If it does not, set it to the correct value as follows in SYSGEN:
SYSGEN> USE ACTIVE
SYSGEN> SET LGI_CALLOUTS number-shareable-images
SYSGEN> WRITE ACTIVE
SYSGEN> EXIT
However, if you start TCPware as part of your site auto-startup, it enables the TCPware ACE/Client after rebooting. Use CNFNET to permanently disable the TCPware ACE/Client.
To use the ACE/Client, you must copy the ACE/Server configuration file, SDCONF.REC, from the ACE/Server to the ACE/Client machine. It must go into the TCPWARE_ACECLIENT_DATA_DIRECTORY described in the previous section.
If the TCPware ACE/Client and the ACE/Server do not have the same SDCONF.REC file, communication between them will be impossible. To view the SDCONF.REC file to make sure it matches the one on the server, run the TCPWARE:ACEMAIN_CL.EXE utility on the client, as follows:
$ RUN TCPWARE:ACEMAIN_CL
Here is sample output:
Configuration file is version 6
Maximum number of ACE/Servers is 2
Maximum number of ACE/Client retries is 3
ACE/Client timeout is 10 seconds
DES has been disabled
Duress mode has been disabled
The ACE/Server is a trusted server
Number of bad Tokencodes allowed is 3
Number of bad PIN allowed is 3
ACE/Server service name is securid
Master ACE/Server protocol is udp
Master ACE/Server port 5500
Master ACE/Server is fred
Master ACE/Server address is 192.168.142.63
Slave ACE/Server is wilma
Slave ACE/Server address is 192.168.95.82
Slave ACE/Server port is 5510
If the display contains garbage characters, the SDCONF.REC file is corrupted. If the file is corrupted or the entries do not match those of the SDCONF.REC file on the ACE/Server, recopy the server file using FTP in binary mode.
The TCPware startup process:
• Checks to see if the ACE/Client is enabled.
• Defines the logicals described in the previous section.
• Installs the TCPWARE_ACECLIENT_SHR.EXE and TCPWARE_ACECLIENT_CL.EXE shareables.
• Defines the LGI$LOGINOUT_CALLOUTS to include TCPWARE_ACECLIENT_CL.
• Increments the SYSGEN parameter LGI_CALLOUTS by one.
The following NETCU commands are available to monitor and control which users should be authenticated before granting access:
|
Adds the username to the ACE/Client database. The ACE/Server authenticates the user. |
|
|
Removes the username from the ACE/Client database. The ACE/Server no longer authenticates the user. |
|
|
Displays the ACE/Client database and lists the usernames that are being authenticated. |
|
|
Creates a new ACE/Client database and renames the old database if there was one. |
The TCPware ACE/Client supports the following functions:
1 Enter PASSCODE: prompt to authenticate users by challenging them for SecurID PASSCODE information
2 New PIN operation
3 Next Tokencode operation
4 Backup servers
5 Encryption algorithm
The first three functions requires user interaction. Support of an optional backup ACE/Server is transparent to the users.
This is the challenge for the SecurID authentication. Users must respond by entering their SecurID PASSCODE, comprised of their secret PIN, followed by the tokencode currently displayed on the user's SecurID token. PINPAD tokens require that the user's PIN be entered into the PINPAD token itself; the result that is displayed on the user's token is the complete PASSCODE and is entered as displayed. The PASSCODE prompt is normally displayed after the user has responded to the usual login prompts.
When a SecurID token is first assigned to a user, a PIN is not yet associated with it. A SecurID token cannot be used for authenticating until a PIN is assigned to it. When using their SecurID token for the first time, or in cases when a new PIN must be assigned to an existing user, users need to interact with the ACE/Server. This interaction is known as "New PIN mode."
"Next Tokencode mode" requires that the user input a second successive tokencode from their SecurID Token. The ACE/Server puts a token into Next Tokencode mode if it has drifted out of synchronization with the server system's clock, or a PIN has been compromised and a hacker is attempting to guess a valid tokencode. Requiring two consecutive token-codes ensures that the user actually has possession of the SecurID token associated with the PIN that was entered. This feature must be supported for the ACE/Server to properly identify a user whose SecurID token clock may have drifted out of synch with the ACE/Server's clock. It is also required to allow the ACE/Server to perform evasive-action processing, as is the case when someone has learned a user's PIN and is attempting to guess the valid tokencode without having possession of the associated SecurID token.
The optional backup ACE/Server runs on a second UNIX machine and acts as a temporary backup to the ACE/Server. Backup ACE/Server software runs on any platform that can run the ACE/Server, but does not have to be the same operating system as that running the ACE/Server software. The backup ACE/Server is in regular communication with the ACE/Server via a dedicated TCP/IP socket. In the event of a failure of the ACE/Server platform or of the network connection, the backup ACE/Server processes authentication requests and generates audit trail records. The backup ACE/Server has all the features of the main ACE/Server except the administrative capabilities.
The ACE/Server supports Security Dynamics' proprietary encryption. The ACE/Server system uses this method to secure transmissions between the ACE/Server, ACE/Client and backup ACE/Server.
FTP, RLOGIN, TELNET, and SET HOST provide different login prompts for Token Authentication.
The user must first log in on a terminal session (such as TELNET, RLOGIN, or SET HOST) to obtain a new PIN if assigned for token authentication. The user cannot be in PIN mode (Next Tokencode or New PIN mode) when in FTP, since there is no interaction between the FTP user and the ACE/Client.
When in FTP, the user must enter the username prompt and the PASSCODE at the usual Password: prompt. If the user is not assigned for token authentication, the user provides their password when FTP prompts for it.
A user running TELNET, RLOGIN, or SET HOST must provide login information in order to be authenticated before access is allowed. In addition to the username and password information, the user is also asked to provide the PASSCODE.
Following are the messages that the ACE/Client will display to the user who is attempting to authenticate.
• Enter PASSCODE:
This is the ACE/Client prompt the user usually sees when attempting to authenticate. (New PIN mode, Next Tokencode mode and certain authentication failures are the exceptions). At this prompt, users must enter their SecurID PASSCODE. The PASSCODE is comprised of the secret PIN and the current tokencode displayed on the user's SecurID token. The two values, when combined, are referred to as a PASSCODE. The format of the PASSCODE is dependent on the type of SecurID token being used.
• PASSCODE accepted
This message is displayed on users' screens when they enter a valid PASSCODE. The user is successfully authenticated and now has access to the ACE/Server-protected environment.
• Access denied
The ACE/Client uses this message to indicate a failed authentication request (an invalid PASSCODE). The individual is denied access to the SecurID-protected system. After this message is displayed, the user may be prompted with another Enter PASSCODE: prompt. This message may be displayed for a number of reasons such as:
– The user entered a valid PIN followed by an invalid tokencode. The entered value could be a previously used code or a guessed number.
– When using a PINPAD token, the user entered an invalid tokencode.
– The user entered an invalid PIN followed by a valid tokencode. The user entered a number other than the PIN associated with the token they are attempting to use.
– When using a PINPAD token, the user entered an invalid PIN.
– The user's SecurID token is disabled, either automatically to evade a system attack, or by administrative action.
– A person attempting to gain unauthorized access is guessing PASSCODEs.
– The user is not activated on the Client.
– The Client was not found in the ACE/Server database.
– Access was attempted with a PASSCODE already in use.
– Mismatch of node secret or encryption type.
– The token, or the user's temporary access period, expired.
• Press Return to generate a new PIN and display it on screen
or
Ctrl/D to cancel the New PIN procedure:
This message is displayed when the user's SecurID token is in New PIN mode and the user entered the current tokencode (or tokencode and PIN). This prompt indicates that the ACE/Server is ready to generate a new PIN for the token and display it to the tokenholder, unless the process is aborted by pressing Ctrl/D
• Enter your new PIN, containing 4 to 8 characters, or Press Return to generate a new PIN and display it on screen or Ctrl/D to cancel the New PIN procedure:
A message similar to this is displayed when the user's SecurID token is in New PIN mode and the user initiated a SecurID authentication. This prompt indicates that the ACE/Server is ready to generate a new PIN for the token or to allow users to create their own PIN.
• Enter your new PIN, containing 4 to 8 characters, or <Ctrl d> to cancel the New PIN procedure:
This prompt appears when the user's SecurID token is in New PIN mode and the user initiated a SecurID authentication. In this case, the user MUST create a PIN or abort the operation using Ctrl/D. The ACE/Server does not generate a PIN automatically. Pressing Return at this point re-displays the prompt. The new PIN, whether
ACE/Server-generated or user-created, is displayed to the tokenholder, unless the process is aborted by pressing Ctrl/D.
• PIN rejected
The user selected an unacceptable PIN. The PIN specified by the user must conform to the system PIN specifications for length and allowable characters (digits only or letters and digits). PIN numbers must be composed of digits (0-9) or letters A-Z. PINPAD cards require that the PIN be composed exclusively of digits 0-9, the PIN cannot begin with zero, and the PIN length cannot exceed the length of the tokencode.
• Please enter the next code from your token:
SecurID authentication is based on a patented time synchronization technology. If users have not used their SecurID token for an extended time, the SecurID token's clock may appear to the ACE/Server to be out of synch, or beyond the limits of normal synchronization. This is usually a result of mutual drift between the SecurID token's clock and the time source for the ACE/Server. In this event, the user will be prompted to enter the next tokencode.
Each of the following error messages indicates some failure with the ACE/Client, where xxx indicates the cause of the error:
|
ERRSDCONF |
<Error reading xxx> |
|
NOCLISERCOM |
<Cannot initialize client-server communications> |
|
FAILSYNCSER |
<Failed to synchronize with server> |
|
GTHOSTFAIL |
<gethostname failed> |
|
GTHOSTBYFAIL |
<gethostbyname failed for host xxx> |
|
ERRSELECT |
<Error from select> |
|
EXPSELECT |
<Exception from select> |
|
UNLOCUNIXFL |
<Unable to locate xxx in the TCPware services file> |
|
UNCRESOCK |
<Unable to create ACE/Server socket> |
|
UNBINDSOCK |
<Unable to bind ACE/Server socket> |
|
UNLOCSERHT |
<Unable to locate ACE/Server host> |
|
UNSNDSERV |
<Unable to send to the ACE/Server> |
|
ASSIGNFL |
<SYS$ASSIGN failed: > |
|
QIOWFAIL |
<SYS$QIOW failed: > |
|
CRENODESECR |
<Can not create service file xxx> |
|
PASSCODETO |
<PASSCODE Timeout, you have xxx seconds to input the PASSCODE> |
If the user is experiencing login failures, check the ACE/Server activity menu for additional information. Run sdadmin on the ACE/Server system and select the Report menu.
See the ACE/Server Administration Manual for details about authentication and ACE/Server errors.
