test

SunScreen 3.2 Administrator's Overview

SecurID User Authentication Processing Details

SecurID is a one-time password mechanism supplied by RSA Security. SecurID is a leading form of hardware-based authentication.

SecurID authentication involves three components: a user-held hardware device (token), client software that solicits input from the token-holding user, and server software that verifies the user authentication information supplied by the token-holder through the client software. The client software runs on a variety of standard operating system platforms (those capable of providing user-level security) and other imbedded system applications. The server software runs on a more restricted set of standard operating systems.

The client software portion (when installed on the Solaris operating system) is known by two names: ACE/Client and ACE/Agent. Versions of the RSA Security offering before v3.2 used the former name; version 3.2 and later use the latter name (the renaming reflects an extension of functionality). Regardless of version, the server component is known as ACE/Server. ACE/Client or ACE/Agent software from any version 3.x can properly communicate with any ACE/Server version 3.x system with a version greater than or equal to it (the client version is less than or equal to the server version).

SunScreen is compatible with ACE/Server version 3.0.1 and greater.

The SunScreen product does not include the ACE/Server product, which must be purchased separately.

Typical SecurID authentication involves a hardware device (token) that generates a pseudorandom value. That value is combined with a personal identification number (or PIN) to realize a two-factor authentication scheme. The algorithmic data for computing the pseudorandom value as well as a user's PIN are known only to the token-holder and the ACE/Server. There are several styles of SecurID token device as well as a software implementation, but all operate in basically the same fashion.

In interfacing SecurID to SunScreen, you are expected to understand the ACE/Agent and ACE/Server implementation to a level sufficient to install and configure the SunScreen system as a client of ACE/Server. Further details of the complete SecurID facility, token types, options, and so forth, should be referred to your ACE/Server administrator.

ACE/Client, ACE/Agent, and the SunScreen Stub Client

Configuration of SecurID for use within SunScreen is relatively complex. This complexity is due partly to the third-party nature of SecurID, partly to a larger selection of options for its setup and use, and partly because the authentication provided by SecurID is robust.

The first several sections following this one discuss the various components and choices for setup that are possible. Those sections are not written in a task-oriented fashion; rather, they attempt to bridge the gap in understanding SunScreen mechanisms and the third-party offerings of SecurID.

The section "Typical SecurID Configuration" presents an almost maximal configuration. The setup and initial testing of SecurID depends on following the applicable steps in that section.

The RSA Security ACE/Agent software offering is only supported on SPARC versions of the Solaris software through version 2.6 (SunOS 5.6). Yet, SunScreen is supported on Solaris 2.6 software and beyond, and on both SPARC and the Intel platforms. To complete the SunScreen support matrix, Sun has developed a stub client installation mechanism.

The stub client allows SunScreen to be configured with a minimum of information such that it can communicate with an ACE/Server for purposes of authenticating users of SunScreen-protected resources. The stub client does not provide the full suite of functions available within the ACE/Agent, nor does it supplant the need to purchase and deploy the ACE/Server software and SecurID tokens from RSA Security.

In summary, for SecurID support for SunScreen, if you are installing SunScreen on a SPARC-based Solaris machine which has a supported ACE/Agent implementation, you can choose either the stub client or the complete ACE/Agent installation on the Screen. For SunScreen on other Solaris platforms or versions, you must use the stub client.

SecurID ACE/Agent

The installation of ACE/Agent can be performed before or after the installation of SunScreen. The SecurID stub client configuration step can be performed any time after SunScreen installation. SunScreen does not require SecurID to function, so you can perform basic installation and configuration of the Screen first and, once running, add SecurID authentication as needed before full-scale deployment.

For purposes of SunScreen and its usage of SecurID authentication, the SecurID client software must be installed on any Screens that use SecurID authentication. For example, if only users of proxies are authenticated using SecurID, then the client software need only be installed on Screens that run proxy servers. If SecurID is used for authentication of SunScreen administrators, then the client software must be installed on all Screens. You do not have to install SecurID software on the SunScreen Administration Station platform (for remote administration), or on the end-systems of users of SunScreen-protected resources (for example, proxy clients or backend servers).

For information on installing ACE/Agent, see the documentation for that product. One important note regarding ACE/Agent use on SunScreen is that you do not have to actually create Solaris user accounts on the Screens that are protected by ACE/Agent login mechanisms to enable the authentication of SunScreen users by that Screen. (You should use ACE/Agent authentication to secure the Solaris platform of a SunScreen system in any way deemed important for administration of that system as a Solaris platform; but you do not have to make any changes to the Solaris user configuration to use SecurID fully within SunScreen itself.)

With those notes, all other issues regarding use of SecurID within SunScreen are common to both types of client software installation. The following section discusses the stub client.

SecurID Stub Client

Two files required for the SecurID stub client are loaded onto the Solaris system when the SunScreen packages are added. They are:

In addition, the stub client installation requires a file called sdconf.rec that is created on the ACE/Server.

The instructions for creating this file are found in the ACE/Server documentation and your ACE/Server administrator must provide this file. sdconf.rec contains addressing information for your ACE/Servers (master and slave) as well as cryptographic data that enables the SecurID client to establish secure and authentic communication with the ACE/Server.

When ACE/Server administrators create sdconf.rec, they must first inform the server of the SunScreen system. The ACE/Server must consider the Screen to be a client (specifically, a UNIX client system). The ACE/Server must also be configured to know the IP addresses of the Screen. All of the IP addresses that the Screen will use to access the ACE/Server must be configured into the server.

Once the above configuration is performed on the ACE/Server and is saved, the sdconf.rec file contains the information needed to run the stub client installation. You must get the sdconf.rec file from your ACE/Server administrator and onto the system.

To complete the stub client installation, you must be root.

Change into the directory where you loaded sdconf.rec and execute the setup script by typing:


# /usr/lib/sunscreen/lib/securid_stubclient_setup sdconf.rec

The script creates and deposits a few files into the /opt/ace directory and creates the /etc/sdace.txt file. It also edits /etc/inet/services to add a pair of service definitions required by SecurID.

SecurID Access Paths

The protocol used to communicate between the SecurID client and its servers is based on UDP datagrams. This protocol typically uses port 5500, although this can be altered by changing the configuration on all client and ACE/Server systems. Awareness of this port number assignment on SunScreen is found in two places:

The protocol is named securid in both locations.

In more robust SecurID configurations, a slave ACE/Server is configured to serve as a backup to the master server.

As was previously described, the SecurID client software obtains the IP addresses of the ACE/Servers from the sdconf.rec file during client installation. Additionally, the SunScreen policy must contain rules that allow the SecurID client software on the SunScreen to access the master and slave ACE/Servers. This involves:

For the master and slave ACE/Server mode to function, all SecurID clients must be able to access both servers. Additionally, the servers communicate between themselves, using an additional path through a TCP connection (typically on port 5510). You can alter this by changing the configuration on both ACE/Servers. Awareness of this port number assignment is found in the same places as that of the UDP datagram securid service. This TCP server-to-server protocol is named securidprop in both locations.

Rules are needed to allow the master and slave servers to communicate using securidprop.

SecurID PIN Establishment

Part of the use of SecurID tokens involves the establishment of the personal identification number (PIN). A number of variations are possible in establishing a PIN; these are all determined by the choice of SecurID token device and ACE/Server administration policy regarding PIN formulation and mode of establishment.

ACE/Server administrative choice makes it possible for the token-holders to establish their own PIN. The experienced SecurID user knows that the standard ACE/Agent client software allows establishing a token-holder PIN using the shell surrogate program sdshell. SunScreen does not require the use of the shell surrogate to use SecurID authentication. This approach avoids the severe security problems and administrative difficulties that are associated with creating user accounts on the Screen for each token-holder. Token-holders must nevertheless be able to establish their PIN.

The SunScreen solution is to provide a daemon process, called the PIN server. This server is started automatically whenever a policy is activated if the Screen has been configured as a SecurID client (either through ACE/Agent or stub client installation). The PIN server normally listens on TCP port 3855 (in the standard installation). This port number assignment is found in:

In /etc/inet/services, it is named securidpin; in the active configuration, it is named SecurID PIN. In the proxy startup script, it is referenced by numeric value.

SecurID token-holders use the PIN server to establish a new PIN as necessary. Access to this server is obtained using a standard telnet client program, specifying the alternative port number (3855). For example, using the Solaris telnet program:


% telnet Screen 3855
Trying 1.2.3.4... 
Connected to Screen. 
Escape character is '^]'. 
SunScreen V3.2 SecurID PIN / Re-keying Server 
Enter SecurID login: loginname
Enter PASSCODE: passcode

The interaction is familiar to users of the sdshell and to ACE/Server administrators. Beyond the Enter PASSCODE: prompt, interaction varies depending upon the state of the SecurID token and the PIN options configured for that token on the ACE/Server.

An administrative task that must be performed on the Screen is the addition of policy rules to allow connections to the PIN server from hosts where you think allowing the PIN establishment is appropriate. For example, you may wish to require PIN establishment only from hosts behind your Screens and from external hosts whose traffic is protected by SKIP encryption.

Note -

Some SecurID installations may not allow token-holders to do PIN establishment, opting instead for use of PINs that are determined solely by the ACE/Server administrator. In such cases, access to the PIN server is not needed.

Typical SecurID Configuration

This section attempts to bring together the various configuration elements described in previous sections with an example setup that illustrates the pertinent details of establishing a working SunScreen policy utilizing SecurID authentication.

The example presumes the following preexistent state:

A standard (non-PINPAD) SecurID token is used, which has been given a login name of ssadmin. That login has been activated on screen on the ACE/Servers. The token has been configured for user establishment of a 4 to 8-digit PIN and is in new-PIN mode.

The overall steps performed are:

The command-line interface (using ssadm commands) is shown here for brevity; however, except for the stub client configuration, all other steps can be performed using equivalent administration GUI operations.

Examples: SecurID Configurations

The following are example of SecureID configurations.

To configure a SecurID stub client (while root in a shell on screen):


# cd /var/tmp
# /usr/lib/sunscreen/lib/securid_stubclient_setup sdconf.rec

To create the registry address objects to describe the ACE/Servers, while logged into the Screen:


admin% ssadm -r screen edit Initial
edit> add address acemaster HOST ....
edit> add address aceslave HOST ....
edit> add address aceservers GROUP { acemaster aceslave } { } ...
edit> save

To continue adding the SecurID client-to-server policy rule:


edit> add rule securid localhost aceservers ALLOW

To add the ACE/Server server-to-server policy rule:


edit> add rule securidprop aceservers aceservers ALLOW

To add two PIN server policy rules -- one that allows the end-user SKIP Administration Station to access the PIN server, the other for unencrypted access for inside hosts:


edit> add rule "SecurID PIN" admin localhost SKIP_VERSION_2 
remote screen.admin DES-CBC RC4-40 MD5 NONE ALLOW
edit> add rule "SecurID PIN" inside localhost ALLOW

You should place these rules early enough in the policy so that their action takes place before the action of other conflicting (DENY or less-secure) rules.

To augment the standard admin user to allow SecurID authentication (the existing value is first displayed for clarity):


edit> authuser print admin
"admin" ENABLED PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q" ENABLED } 
DESCRIPTION="(created by install)"  REAL_NAME="SunScreen Administrator" 
edit> authuser add admin password={ "" crypt_password="1hp1R.xm.w63Q" }  
securid={ ssadmin }  description="updated for either simple password or SecurID" 
real_name="SunScreen  Administrator"

To save and activate the augmented policy:


edit> save
edit> quit
admin% ssadm -r screen activate Initial

To perform PIN establishment of the token (from the Administration Station):


admin% telnet screen 3855
Trying 1.2.3.4... 
Connected to screen. 
Escape character is '^]'. 
SunScreen V3.2 SecurID PIN / Re-keying Server 
Enter SecurID login: ssadmin
Enter PASSCODE: 6-digit-passcode-from-token
New PIN required; do you wish to continue? (y/n) [n]: y 
Now enter your new PIN, containing 4 to 8 digits, or press 
Return to generate a new PIN and display it on the Screen, or 
end the connection to cancel the New PIN procedure: 4-digit-PIN
Please reenter new PIN: 4-digit-PIN
Wait for the code on your token to change, then connect again 
with the new PIN 
Connection closed by foreign host.

The configuration is now complete. After the code on the token changes (up to one minute later), administrative access to the Screen can be obtained using SecurID. The SunScreen administrative user's name is still admin, but you supply as the password the 4-digit-PIN value (established above) followed immediately by the 6-digit value displayed by the token.

In the example, the simple-text password can also be allowed to establish administrator authenticity.

Other SecurID Details

Use of SecurID authentication by SunScreen requires the UDP and TCP protocols and also that the Screen has at least one IP address. This implies that a Screen configured with no routing-mode interfaces cannot use SecurID authentication (as it lacks the ability to speak these protocols).

You should exercise caution when deploying SecurID authentication to protect SunScreen administration (and indeed any other critical SunScreen-control facility where authentication is required). Because the ability to authenticate using SecurID requires using policy rules in SunScreen, a mistake in configuring a policy can leave the Screen in a state where SecurID authentication is broken. Additionally, the ACE/Server could be down or inaccessible for other reasons, which can result in an administrative lockout. As a precautionary measure, at least one SunScreen administrator should always be configured with ALL access and a simple-text password (perhaps in addition to SecurID).

ACE/Server version 3.2 and newer can be hosted on some versions of SPARC-based Solaris. Because of the additional security features of SunScreen, you may be tempted to install ACE/Server on the SunScreen. This is a perfectly acceptable deployment, but you are cautioned to understand thoroughly the ramifications of installing ACE/Server on a multihomed host. There are numerous complexities to be dealt with on an ongoing basis if your SunScreen does not have a single IP address that can service all queries from other SecurID software components. (See your ACE/Server installation documentation for information about "Multiple Server IP Addresses.")

SecurID Usage

As discussed in earlier portions of this chapter, the SecurID authentication mechanism is used within SunScreen in the form of either an authorized user or a (SPECIAL) External Method. (See "Authorized User" and "SPECIAL External Method Authentication".)

You can use SecurID to authenticate administrative users as well as to authenticate authorized users for SunScreen proxies.

Use of SecurID in the authorized user context is provided by configuring authuser entities to include SecurID references (for example, login names known to the ACE/Server or Servers).

Use of SecurID in the (SPECIAL) External Method is permitted by connecting a SPECIAL proxyuser entity with one or more proxy policy rules. This connection can be directly in the rule or rules or by inclusion in a group used in the rule. (See "Proxy Users".)