test

SunScreen EFS Release 3.0 Reference Manual

SecurID authuser Entities

One or more authuser entities must be configured to use SecurID. The following is an example of what you type to edit the default Screen administrative user to use SecurID authentication:


edit> authuser print admin "admin" ENABLED PASSWORD={
"" CRYPT_PASSWORD="1hp1R.xm.w63Q" ENABLED } DESCRIPTION="(created
by install)" REAL_NAME="SunScreen Administrator (before)

edit> authuser add admin PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q" } SECURID={
screenadm } DESCRIPTION="(created by install)" REAL_NAME="SunScreen Administrator

where screenadm is the login name by the token as known to the ACE/Server. This string is not interpreted by the Screen logic in any way.

Note -

Configuring the Screen to use SecurID administration provides another way for you to, for example, inadvertently make a rule change that breaks SecurID authentication. Therefore, always have at least one last ditch simple password administration account configured.

SecurID now functions on the routing-mode Screen. By creating additional authusers that employ SecurID authentication, mapping them using proxyuser entities, and referring to those proxyusers in proxy rules, SecurID is used to authenticate users of the proxies as well.

SecurID User Authentication Processing Details

SecurID\256 is a one-time password mechanism supplied by Security Dynamics Technologies, Inc. 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\256 and ACE/Agent\256. Versions of the Security Dynamics offering before v3.2 used the former name, while v3.2 and thereafter use the latter (the renaming reflects an extension of functionality). Regardless of version, the server component is known as ACE/Server\256. ACE/Client or ACE/Agent software from any version 3.x can properly communicate with any ACE/Server v3.x system with a version greater than or equal to it (client version <= server version).

SunScreen EFS 3.0 is compatible with ACE/Server v3.0.1 and greater.

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

Typical SecurID authentication involves a hardware device (token) that generates a pseudo-random 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 pseudo-random value as well as a user's PIN are (idealistically) 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 EFS 3.0, you are expected to understand the ACE/Agent and ACE/Server implementation to a level sufficient to install and configure the SunScreen EFS 3.0 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 EFS 3.0 Stub Client

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

The stub client allows SunScreen EFS 3.0 to be configured with a minimum of information such that it can communicate with an ACE/Server for purposes of authenticating users of SunScreen EFS 3.0-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 Security Dynamics.

In summary, for SecurID support for SunScreen EFS 3.0, if you are installing SunScreen EFS 3.0 on SPARC-based Solaris 2.6, you can choose either the stub client or the complete ACE/Agent installation on the Screen. For SunScreen EFS 3.0 on other platforms or versions of Solaris, you must use the stub client.

The installation of ACE/Agent can be performed prior to or after the installation of SunScreen EFS 3.0. The SecurID stub client configuration step can be performed any time after SunScreen EFS 3.0 installation. SunScreen EFS 3.0 does not require SecurID to function, so it is possible (even recommended) to 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 EFS 3.0 and its usage of SecurID authentication, it is necessary that the SecurID client software be installed on any Screen(s) that makes use of 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 to be used for authentication of SunScreen EFS 3.0 administrators, then the client software must be installed on all Screens. It is not necessary to install SecurID software on the SunScreen EFS 3.0 Administration Station platform (for remote administration), nor on the end-systems of users of SunScreen EFS 3.0-protected resources (for example, proxy clients or backend servers).

The installation of ACE/Agent is not discussed herein, as it is detailed fully in the documentation for that product. One important note regarding ACE/Agent use on SunScreen EFS 3.0 is that it is not necessary to actually create Solaris user accounts on the Screens that are protected by ACE/Agent login mechanisms to enable the authentication of SunScreen EFS 3.0 users by that Screen. (It is certainly permissible and recommended to use ACE/Agent authentication to secure the Solaris platform of a SunScreen EFS 3.0 system in any way deemed important for administration of that system as a Solaris platform; but it is not required to make any changes to the Solaris user configuration to make full use of SecurID within SunScreen EFS 3.0 itself.)

With those notes, all other issues regarding use of SecurID within SunScreen EFS 3.0 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 EFS 3.0 packages are added; they are:

In addition, the stub client installation requires a file that is created on the ACE/Server; this file is called:

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 (primary and secondary) as well as cryptographic data that enables the SecurID client to establish secure and authentic communication with the ACE/Server.

When the ACE/Server administrator creates sdconf.rec, you must first inform the server of the SunScreen EFS 3.0 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; it is important that all IP addresses the Screen will use to access the ACE/Server 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 SunScreen EFS 3.0 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:


# /opt/SUNWicg/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 server(s) 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 EFS 3.0 is found in two places:

The protocol is named securid in both locations.

In more robust SecurID configurations, a secondaryACE/Server is configured to serve as a backup to the primary 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 EFS 3.0 policy must contain rules that allow the SecurID client software on the SunScreen EFS 3.0 to access the primary and secondary ACE/Servers. This involves:

For the primary and secondary 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; again, this can be altered 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 primary and secondary servers to communicate using securidprop.

SecurID PIN Establishment

Part of the use of SecurID tokens involves the establishment of the personal identification number or PIN. There are a number of variations possible regarding PIN establishment; 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 allows the possibility that the token-holder can establish their own PIN. The experienced SecurID user knows that the standard ACE/Agent client software allows token-holder PIN establishment using the shell surrogate program sdshell. SunScreen EFS 3.0 does not require the use of the shell surrogate to use SecurID authentication; this avoids the severe security problems and administrative difficulties that would be associated with creation of user accounts on the Screen for each token-holder. Each token-holder must nevertheless be able to establish their PIN.

The SunScreen EFS 3.0 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 3855Trying 1.2.3.4...

Connected to Screen.

Escape character is '^]'.

SunScreen V3.0 SecurID PIN / Re-keying Serve

Enter SecurID login: loginnameEnter 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 feel it is appropriate to allow PIN establishment. For example, you may wish to require PIN establishment to occur only from hosts behind your Screens and from external hosts whose traffic is protected by SKIP encryption.

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 EFS 3.0 policy utilizing SecurID authentication.

The example presumes the following pre-existent 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.

The following is an example of what you type to perform the SecurID stub client configuration (while root in a shell on screen):


# cd /var/tmp# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec

The following is an example of what you type to create the registry address objects to describe the ACE/Servers (while logged in to the Screen):


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

The following is an example of what you type to continue adding the SecurID client-to-server policy rule:


edit> add rule securid localhost aceservers ALLOW

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


edit> add rule securidprop aceservers aceservers ALLOW

And the PIN server policy rule (actually, two rules are shown being created, 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

Note -

These rules should be placed early enough in the policy to preempt other conflicting (DENY or less-secure) rules.

Now, 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"

Save and activate the augmented policy:


edit> saveedit> quit% ssadm -r screen activate Initial

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


% telnet screen 3855Trying 1.2.3.4...

Connected to screen.

Escape character is '^]'.

SunScreen V3.0 SecurID PIN / Re-keying Server

Enter SecurID login: ssadminEnter PASSCODE: 6-digit-passcode-from-tokenNew 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:

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-PINPlease re-enter new
PIN: 4-digit-PINWait 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 EFS 3.0 requires the UDP and TCP protocols and further 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).

Caution should be exercised in the deployment of SecurID authentication for protection of SunScreen EFS 3.0 administration (and indeed any other critical SunScreen EFS 3.0-control facility where authentication is required). Because the ability to authenticate using SecurID requires use of policy rules in SunScreen EFS 3.0, it is possible that 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. This can result in an administrative lockout. As a precautionary measure, at least one SunScreen EFS 3.0 administrator should always be configured with ALL access and a simple-text password (perhaps in addition to SecurID).

ACE/Server v3.2 and newer can be hosted on SPARC Solaris 2.6. Because of the additional security features of SunScreen EFS 3.0, it is tempting to install ACE/Server on the SunScreen EFS 3.0. This is a perfectly acceptable deployment, but you are cautioned to understand thoroughly the ramifications of installing ACE/Server on a multi-homed host. There are numerous complexities to be dealt with on an on-going basis if your SunScreen EFS 3.0 does not have a single IP address that can service all queries from other SecurID software components. (See your ACE/Server installation documentation regarding "Multiple Server IP Addresses.")