RSA Security LRS1 Product’s ACE/Agent configuration, Figure Configuring the LRS to Use SecurID

RSA SecurID Ready Implementation Guide

5. Product’s ACE/Agent configuration

The LRS supports the ACE/Server security system manufactured by RSA Security Inc. ACE/Server is a system of client-server software and accompanying token cards.

Note: Refer to your RSA Security documentation for ACE/Server installation instructions.

The SecurID card generates single-use, unpredictable numerical codes. These "tokencodes," together with the user's PIN, form the basis of the SecurID authentication. The PIN and generated tokencode are referred to collectively as SecurID PASSCODES. To gain access to a network protected by SecurID, both elements of the PASSCODE must be entered correctly.

The RSA Security SecurID system requires certain communication between the ACE/Server and the end-user. For example, the user must enter a new PIN when a SecurID card is first used, and a second PASSCODE when locked out.

PAP does not allow for these types of messages or additional user input. Therefore, it is strongly recommended that SecurID be run from character mode only. It is possible to use SecurID with PAP, provided that situations like those mentioned above are either prevented or handled in text mode on the next call.

To log into the LRS, the user must enter a username at the username prompt, and the PASSCODE at the password prompt.

To specify the SecurID ACE/Server for authentication of username/ PASSCODE, use the Set/Define Authentication SecurID command:

Figure: Configuring the LRS to Use SecurID

Local>> DEFINE AUTHENTICATION SECURID PRECEDENCE 1 Local>> DEFINE AUTHENTICATION SECURID PRIMARY 192.0.1.50 Local>> DEFINE AUTHENTICATION SECURID SECONDARY 192.0.1.51

After SecurID is configured on the LRS, the LRS will receive further configuration information from the ACE/Server. However, this only happens the first time that the LRS and ACE/Server communicate. If you purge the authentication information on the LRS or change the precedence of SecurID, this learned information will be lost. You will need to have your ACE/Server administrator reinitialize the LRS with ACE/Server for SecurID to function properly again.

If SecurID receives repeated authentication requests for an invalid username/password pair, it assumes that a login attack is taking place. SecurID will react by continually slowing its responses to the LRS. This problem can be avoided by ensuring that SecurID has the highest precedence number. For example, if you're using SecurID, Kerberos, and a UNIX password file, set SecurID's precedence to 3.

4