test

SunScreen 3.2 Administrator's Overview

Chapter 9 Authentication

SunScreen provides the ability to configure user entities. These entities are used to authenticate individual administrators of Screens and to allow access through the Screen when using proxied services. This chapter discusses the following topics:

User Authentication

Authentication enables you to verify the identity of both internal and external users based on user name and a simple text password, or on a user name and SecurID token passcode, or both.

Proxies provide a means to validate, regulate, and extend the abilities of certain services beyond those afforded by kernel-based stateful packet filtering. (See Chapter 10, Proxies).

User Identification

SunScreen contains two aspects of user identification: authorized user (as defined in the authuser database) and proxy user (as defined in the proxyuser database). The authuser database describes unique individuals; the proxyuser database identifies mappings of individuals to roles, which specify what given users can do. In addition, there is an alias--administrative users--for authorized users. Administrative users are functionally identical to authorized users and their role is defined by the access rules.

The administration GUI edits authorized users, which are authuser objects; administrative users, which are adminuser objects; or proxy users, which are proxyuser objects.

Authorized User

"Authorized user"  is a named common object that describes an individual user who is distinct from all others. The attributes provide a repository for demographic and authentication data about that individual.

Access to and use of the administrative GUI functions require that you establish the authorized user identity before administration is allowed. Both the administration GUI Login screen and the login subcommand of the ssadm command line reference an authorized user object.

Authorized user objects contain information sufficient to allow authentication of users of SunScreen. Validation information can either be a simple-text password or a SecurID token passcode. Users can also be configured to have both means of authentication.

The authenticity of an authorized user only establishes the identities of individual administrators, not the various roles they may play while using SunScreen. Role is established in one of two ways: (1) reference within the User field in the administrative access rules of a policy, or (2) reference from a packet filtering rule that uses user authentication (proxies).

Defining an Authorized User Object

Note -

In examples, the names of authorized users, proxy users, and other user naming items are often different for purposes of clarity and illustration.

You can create and manage the authorized user and proxy user objects through the administration GUI and the command line interface. This section describes the attributes of these objects and their manipulation using the command line.

The authorized user object contains the following items:

The password= and securid= items define authentication methods for the authorized user.

The password= item has the following subitems:

The processing of passwd and crypt_password= subitems is special. When an authorized user object is first created (or whenever a new password is set for that user), the password can be presented in plaintext using the (nonempty) passwd subitem. Thereafter (for example, whenever the object is edited), the crypt_passwd= subitem can be used to retain a password without having to know (or retype) the plaintext form.

The encryption method used for these objects is identical to that used by Solaris to encrypt user passwords (those stored in /etc/shadow). This provides the ability to clone encrypted passwords from Solaris to SunScreen user descriptions without the SunScreen administrator needing to know the users' plaintext passwords. This also means that the content of the SunScreen authorized user database is maintained with file permissions that prevent access from all but root users of the SunScreen.

The securid= item has the following subitems:

Creating an Authorized User Object

The authorized user object is manipulated using the authuser subcommand of ssadm edit. The authuser subcommand takes one of the following verbs:

Example: Displaying An Authorized User

The following is an example of what you type to display an existing authorized user object while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser print jeff.hogg
"jeff.hogg" ENABLED PASSWORD={ "" CRYPT_PASSWORD="s8Q2DZRw4tmGk" ENABLED } 
DESCRIPTION="large and in charge" REAL_NAME="Jeff Hogg"

print surrounds the value of each item in double quotes. These are only necessary on input to protect embedded spaces within the values of items or to preserve null items.

print produces all tag names in capital letters (for example, REAL_NAME=). On input, the case for these tags is not important (for example, real_name= and REAL_NAME= are equivalent).

Because of the way in which passwords are encrypted, the add operation is unlikely to yield a particular crypt_password= encoding of any given plaintext password. There are 4096 different encryptions of any given plaintext password.

Examples: Creating Authorized User Objects

Following are examples of creating authorized user objects.

The following is an example of what you type to create the above authorized user object while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ "4flash" } 
description="large and in charge" real_name="Jeff Hogg"
edit> quit

This shows creation of the object by supplying the simple-text password in the plaintext form.

To create the above authorized user object, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ "" crypt_password="s8Q2DZRw4tmGk" } 
description="large and in charge" real_name="Jeff Hogg"
edit> quit

This shows creation of the object by supplying the simple-text password in its already encrypted form

In each of the above add operations, the items have been allowed to default to enabled.

To re-create the above authorized user object so that it is disabled while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg  disabled password={ "" crypt_password="s8Q2DZRw4tmGk" } 
description="large and in charge" real_name="Jeff Hogg"

To create an authorized user object defining a SecurID authentication method, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg securid={ "jeffh" } 
description="large and in charge" real_name="Jeff Hogg"

To create an authorized user object defining both simple-text password and SecurID authentication methods, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ "" crypt_password="s8Q2DZRw4tmGk" } 
securid={ "jeffh" }  description="large and in charge" real_name="Jeff Hogg"

To display all authorized user objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser print 
"admin" ENABLED PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q" ENABLED } 
DESCRIPTION="(created by install) REAL_NAME="SunScreen Administrator" 
"jeff.hogg" ENABLED SECURID={ "jeffh" ENABLED } 
DESCRIPTION="large and in charge" REAL_NAME="Jeff Hogg"

To display the names of all authorized user objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser names,raw
"admin"
"jeff.hogg"

Authorized User Authentication Processing Logic

Authentication processing is performed in the order of authentication methods in the authorized user object.

First, if the authorized user object itself is disabled, authentication fails.

Second, if the simple-text password method exists and is enabled, then the password supplied is encrypted and compared against the one stored in the method subitem. If they are equal, then authentication succeeds.

Third, if the SecurID method exists, is enabled, and the password presented appears to be a possible SecurID passcode (that is, ends in 6 decimal digits), then it is submitted to the ACE/Server along with the securidname for the method. If the ACE/Server indicates success, then authentication succeeds.

If none of the above yields success, then authentication fails.

Administrative User

The administrative user object identifies the SunScreen administrators that administer the Screen. The administrative user object is, in reality, a role of an authorized user.

After you create an administrative user object, you grant administrative access by creating an administrative access rule. The name that you create for the administrative user object is the same name that you use when you create administrative access rules.

Proxy Users

Proxy user is a named common object distinct from the authorized user. Proxy users are either SIMPLE or GROUP objects. SIMPLE objects are used to provide for and establish an association between individual authorized users and the role they play in using the facilities controlled by SunScreen. GROUP objects are used to allow creation of groups of SIMPLE proxy users that share common access to facilities. Thus, GROUPs streamline the task of allowing or removing access.

Some special proxy user objects also provide the means to map external collections of users into the access control facilities of SunScreen. In SunScreen, external access to SecurID users and RADIUS users is provided. (Access to other external user databases is afforded using RADIUS as an intermediary agent. For example, access to LDAP user databases stored through Sun Directory Services (SDS) are accessible through RADIUS.)

The figure below summarizes the relationship between rules, authorized users, proxy users, and external user databases.

Figure 9-1 Summary of the Relationship Between Rules, Authorized Users, Proxy Users, and External User Databases

Graphic

Authorized users and proxy users names are distinct, and you can have objects with identical names in each. Choose a naming strategy for each set that best reflects the naming systems already employed. For example, you can choose to name authorized users by employee identities, like distinguishing names or employee numbers, and proxy users by names that reflect their normal user login names deployed on server systems (for example: UNIX login name). Names may not contain the following characters:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

Names of authorized users, proxy users, and other user naming items are often deliberately chosen to be different for purposes of clarity.

The figure below shows the relationship of the proxy user to the authorized user and backend user name's password.

The records in the proxy-user database provide the link between the records in the authorized-user database and the backend user's name in the server's user database.

Figure 9-2 ProxyUser Example

Graphic

Defining a Proxy User Object

The SIMPLE proxy user object is used to define associations between user authentication mechanisms and the identity a user assumes when connected to a permitted network resource. This association is loosely dubbed a role.

A SIMPLE proxy user object can indicate one of three types of authentication to be used: (1) none, (2) an authorized user object, or (3) an external authentication mechanism.

The relationship between SIMPLE proxy users and the authentication mechanism was shown in Figure 9-1.

A SIMPLE proxy user object also indicates the user identity string to be supplied when establishing the user identity on a network resource. This network resource is dubbed the backend server and, by derivation, the identity established on the backend server is defined by the backend_user_name item.

Note -

The backend_user_name is only used by the FTP proxy.

A GROUP proxy user object is a collection of one or more references to other proxy user objects, either SIMPLE or GROUP.

Any proxy user object, either SIMPLE or GROUP, contains the following items:

A SIMPLE proxy user object contains the following items:

A GROUP proxy user object contains zero or more of the following items:

Creating a Proxy User Object

The proxy user object is manipulated using the proxyuser subcommand of ssadm edit. proxyuser takes one of the following as commands:

Examples: Displaying, Creating, Adding, Removing Proxy User Objects

Following are examples of displaying, creating, adding, and removing proxy user objects:

To display existing proxy user objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> proxyuser print jdh
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh" 
DESCRIPTION="Jeff Hogg as self on Solaris" 
edit> proxyuser print proxyusers
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies"

To create the above SIMPLE proxy user object, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> proxyuser add jdh auth_user_name=jeff.hogg 
backend_user_name=jeffh description="Jeff Hogg as self on Solaris"
edit> quit

To create the above GROUP proxy user object, while logged into the primary Screen. First create the initial group with no members:


admin% ssadm -r primary edit Initial 
edit> proxyuser add proxyusers group description="users allowed through FTP
 and telnet proxies"

The above empty group creation demonstrates a case where the GROUP type cannot be deduced from the other tags, since description= is a tag common to all proxy user object types.

To add the members of the example GROUP:


edit> proxyuser addmember proxyusers radius
edit> proxyuser addmember proxyusers jdh

Member names are stored in the order in which you add them to GROUP objects. The order is unimportant to authentication processing. This example also uses a SPECIAL object radius that is defined during initial installation.

In each of the above add operations, the items have been allowed to default to enabled.

Following are examples of displaying and removing proxy user objects.

To remove a member reference from a GROUP proxy user object, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> proxyuser deletemember proxyusers radius
edit> proxyuser print proxyusers 
"proxyusers" ENABLED GROUP MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies"

To display all proxy user objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> proxyuser print
"admin" ENABLED SIMPLE AUTH_USER_NAME="admin" DESCRIPTION="initial SunScreen 
administrator" 
"admin-group" ENABLED GROUP MEMBER_NAME="admin" DESCRIPTION="SunScreen administrators"  
"anonymous" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" 
DESCRIPTION="unauthenticated user, for anonymous FTP, etc."  
"ftp" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" 
DESCRIPTION="unauthenticated user, for anonymous FTP, etc."  
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh" 
DESCRIPTION="Jeff Hogg as self on Solaris"  
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies" 
"radius" ENABLED SIMPLE RADIUS DESCRIPTION="default, external, non-specific RADIUS 
proxy_user" "securid" ENABLED SIMPLE SECURID DESCRIPTION="default, external, 
non-specific SecurID proxy_user"

To display the names of all proxy user objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> proxyuser names,raw
"admin" 
"admin-group"  
"anonymous" 
"ftp" 
"radius" 
"securid" 
"jdh" 
"proxyusers"

Proxy User Processing Logic

In earlier sections, the relationship between authorized user objects and proxy user objects was described, as well as an introduction of external (SPECIAL) proxy user authentication methods. This section gives more specifics regarding these objects and mechanisms, and the sequence of steps performed upon them by the processing logic.

There are fundamentally two types of authentication processing performed in SunScreen. Whenever a user identity is required, authentication processing occurs first, using one of these two processes. After SUCCESS is obtained in the authentication of an identity you supplied, access control matching determines if the user is allowed to perform the operation being attempted; authentication FAILURE denies any requested operation. (Access control is described in the section "User Access Control Processing Logic".)

The first type of processing is the authentication of an authorized user object directly. This form occurs when authenticating an administrator of SunScreen, either through the administration GUI Login page or by the ssadm login subcommand. In these situations, the user name provided must match an ENABLED authorized user object. Authentication logic has been previously described (see "Authorized User Authentication Processing Logic").

The second type of processing is the authentication of a proxy user object. This form occurs when authenticating a user who desires access through the FTP or telnet proxies.

As previously introduced, authentication of a proxy user object can take one of three subpaths: (1) null authentication, (2) authorized user authentication, or (3) SPECIAL external authentication method processing.

Regardless of the proxy user authentication path, only ENABLED objects can be used for authentication. A DISABLED object always results in an authentication FAILURE if attempted.

Null Authentication

Null authentication occurs when a SIMPLE proxy user object named by the user contains no auth_user_name= item. In this situation, whatever input is given for the password is accepted without any checking. The preinstalled anonymous and ftp proxy user objects are examples of this type of authentication.

There is nothing special about the names anonymous and ftp for these preinstalled objects. You can create additional null authentication proxy user objects and use them instead of or in addition to the preinstalled ones. This allows the creation of null authentication paths that are private to your installation.

Referenced Authorized User Authentication

Authorized user authentication occurs when an auth_user_name= item is present. In this situation, authorized user authentication logic is performed on the authorized user object named in the item (see "Authorized User Authentication Processing Logic").

SPECIAL External Method Authentication

SPECIAL external authentication method processing occurs when you supply an identity, which is a compound name consisting of a SPECIAL external authentication method and a backend user name.

The syntax of this compound name is:


/ext_method_name/back_end_username

For example, compound names that use the preinstalled RADIUS and SecurID SPECIAL methods might be:


	/radius/jeffh 	/securid/jeffh

There is nothing special about the names radius and securid in these preinstalled SPECIAL objects; they are distinguished by their special radius or securid items. You can create additional SPECIAL authentication methods and use them instead of or in addition to the preinstalled ones. This enables you to create authentication paths that are private to your installation, perhaps to hide these paths or to abbreviate user input.

SPECIAL external authentication logic varies depending upon the method in question. More specifics about the two external methods (RADIUS and SecurID) can be found in later sections. There are two means for using SecurID tokens for authentication: one within the authorized user object, the other through SPECIAL external proxy user objects. The reason for this apparent redundancy lies in the level of trustedness of the two mechanisms. When using the authorized user path, an association is formed between a specific SunScreen authorized user object and a specific SecurID token holder. The SPECIAL external authentication mechanism allows, in essence, SecurID to authenticate any user who passes the challenges. The ability to establish authenticity for purposes of SunScreen administration is never available to SPECIAL external authentication.

You choose the mechanism to employ depending upon the security requirements of your site.

User Access Control Processing Logic

As previously referenced, once an identity is supplied, the would-be user is authenticated. This (now authentic) user must be allowed to perform the operation presently being attempted. The logic that determines the abilities of a user is loosely termed access control.

As with the initial nature of user authentication, there are two contexts within which access control is employed: SunScreen administrative activities and usage of network facilities controlled by FTP, Telnet, and (optionally) HTTP proxies.

Once an administrative user has been authenticated, access to administrative capabilities is controlled by the administrative rules for both remote and local use. Within each such rule, a user name is found. If the authorized user named within the rule matches the authenticated identity, then access is granted at the level the rule specifies. Alternatively, the rule can reference a proxy user object; if the authenticated identity is a member of that proxy user object, then the associated rule-specified access is likewise allowed.

SunScreen proxies that perform user authentication do so by requiring their rules to reference a proxy user object. Once the user-supplied identity has been authenticated, that identity (which is always a proxy user in this context) is evaluated to see if it is a member of the proxy user object that the rule referenced. If it is, then the associated rule matches. (See Chapter 10, Proxies.)

RADIUS User Authentication Details

The RADIUS protocol provides the ability to centralize user authentication databases for widespread uniform deployment throughout organizations. Many forms of external authentication processing, both proprietary and standard, provide the ability to configure a RADIUS agent, or gateway.

Among noteworthy mechanisms so endowed are:

The SDS gateway facility enables SunScreen to tap into authentication using LDAP user databases.

With respect to a RADIUS server, the Screen plays the role of a RADIUS Requestor.

Note -

The term client becomes confused with clients of SunScreen-provided services so the term requestor is used. It also describes the relationship between the RADIUS server and the Screen more accurately.

The RADIUS protocol uses UDP datagrams to perform user authentication. Each RADIUS Requestor is configured with a node secret that is known only to itself and the RADIUS servers from which it expects authentication. That node secret is used to encrypt requests and to decrypt and authenticate server responses.

The RADIUS protocol in SunScreen comes installed with nearly all parameters prefigured for immediate use. Four remaining configuration elements needing postinstallation attention are:

The SunScreen RADIUS Requestor can use up to eight different IP addresses for servers to be queried. These can be configured in one or more address common objects with arbitrary names.

Tip -

Define a single address group object to collect all RADIUS servers for ease in creating server access rules.

To enable the RADIUS Requestor to function, the Screen must be configured to allow it access to the servers through the radius service common object, which comes preinstalled.

RADIUS Server Configuration

The RADIUS Requestor learns of its RADIUS servers and node secret from the variables RADIUSServers and RADIUSNodeSecret, respectively.

TheRADIUSServers variable can either be global or Screen-specific.

It contains the following items:

For multiple-Screen installations, there are at least two approaches for dealing with the possible need to have Screens use different RADIUS servers. One is to employ the SCREEN attribute on address objects with the same name, and then use a globalRADIUSServers variable. Another is to avoid the use of SCREEN attributes on address objects and instead use the sys= item to create Screen-specificRADIUSServers variables. Of course, combinations are also possible. Naturally, the logic prefers Screen-specific address objects and variables over global ones.

The address object or objects (referenced by server name in the above) can be GROUP, RANGE, or SINGLE. server can also be a dotted-quad IP address; however, avoid such usage unless required. The first eight unique IP addresses produced during processing of the variable are used.

Note -

Because of the way SunScreen represents address objects, use of GROUP or RANGE objects results in server usage that is ordered by ascending IP address. The preference order of server use can be controlled precisely by the order of the subitems in the values={...} of theRADIUSServers variable.

RADIUS Node Secret Configuration

The RADIUSNodeSecret variable specifies a character string to use for security and authenticity when interacting with the configured RADIUS server or servers. Because of the way RADIUS operates, only the RADIUS requestors have node secrets (not the servers).

The same value configured forRADIUSNodeSecret must also be introduced into each RADIUS server through its own configuration mechanism. (For obvious reasons, this should be done in an out-of-band fashion.)

TheRADIUSNodeSecret variable is normally Screen-specific. It contains the following items:

In multiple-Screen installations, the sys= item enables you to configure different node secrets for each Screen.

Caution - Caution -

Because shortcuts were taken by some reference implementations, a common deficiency in RADIUS servers is the handling of node secrets that are longer than 31 characters. If you intend to use longer values, first determine that your server or servers can handle them correctly.

Once you establish addresses, rules, and variables, you must activate the configuration to propagate the changes.

Typical RADIUS Configuration

A typical RADIUS configuration scenario has two Screens that each protect a site. la-screen and la-radsvr are a Screen and RADIUS server in the la location, sf-screen and sf-radsvr are a Screen and RADIUS server in the sf location. Each site uses the RADIUS server of the other as a backup.

Note -

Ephemeral IP addresses are shown. Encrypted tunnels, or VPNs, are possible, perhaps likely, in such a configuration, but are not shown for purposes of clarity.

Examples: Typical RADIUS Configurations

The following are examples of typical RADIUS configurations:

To create address objects, while logged into the primary Screen:


admin% ssadm -r primary edit ConfigName
edit> add address la-radsvr HOST 1.2.3.4 ...
edit> add address sf-radsvr HOST 4.3.2.1 ...
edit> add address radsvrs GROUP { la-radsvr sf-radsvr } { } ...

To create a rule to allow RADIUS Requestor-to-server access, while logged into the primary Screen:


edit> add rule radius localhost radsvrs ALLOW

To create RADIUS variables, while logged into the primary Screen:


edit> vars add sys=la-screen prg=auth name=RADIUSServers 
values={ host=la-radsvr host=sf-radsvr } description="RADIUS servers for la site"
edit> vars add sys=sf-screen prg=auth name=RADIUSServers 
values={ host=sf-radsvr host=la-radsvr } description="RADIUS servers for  sf site"

To create RADIUS node secret variables, while logged into the primary Screen:


edit> vars add sys=la-screen prg=auth name=RADIUSNodeSecret value=la-secret
edit> vars add sys=sf-screen prg=auth name=RADIUSNodeSecret value=sf--secret

To save and activate the configuration:


edit> save
edit> quit
admin% ssadm -r primary activate ConfigName

For example, given a valid, RADIUS-hosted user gooduser with password goodpass and an invalid user baduser, while logged into the Screen la-screen:


admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduser  goodpass 
User /radius/gooduser authenticated and mapped to backend user gooduser 
admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduser anythingelse
User /radius/gooduser failed authentication. 
admin% ssadm -r la-screen lib/user_authenticate -v /radius/baduser anything
User /radius/baduser failed authentication.

Other vars for RADIUS Configuration

The following additional variables are preinstalled and used to control the RADIUS client protocol; they are pre-ENABLED and generally need not be altered.

The number of seconds that the requestor logic waits before contacting an unresponsive server:


edit> vars print PRG=auth
PRG="auth" NAME="RADIUSHolddown" ENABLED VALUE="300" 
DESCRIPTION="seconds to ignore a non-responsive RADIUS server"

The number of passes through the server list that requestor logic makes before giving up:


PRG="auth" NAME="RADIUSRetryPasses" ENABLED VALUE="3" 
DESCRIPTION="how many times to try each RADIUS server"

The name of the RADIUS server port, as given in the Service registry:


PRG="auth" NAME="RADIUSService" ENABLED VALUE="radius" 
DESCRIPTION="RADIUS service / port # at which to query server(s)"

The number of seconds for each response that requestor logic waits before sending another attempt:


PRG="auth" NAME="RADIUSTimeout" ENABLED VALUE="5" 
DESCRIPTION="seconds to await each RADIUS server response"

The requestor logic attempts to contact only servers that have not been held down during the first pass; subsequent passes contact each server regardless of previous nonresponsiveness. During the first pass, each server is contacted twice in a row before moving onto the next one. During subsequent passes, each server is only contacted once. A rough upper-bound on the overall time for total failure for all servers is:

#servers x (#passes + 1) x timeout

This is an upper-bound because of the way the first pass avoids recently unresponsive servers; a lower-bound would be:

#servers x (#passes - 1) x timeout

So, for example, with two servers configured and using the default time-outs, the overall failure time-out would be less than 2 x (3 + 1) x 5 = 40 seconds, and greater than 2 x (3 - 1) x 5 = 20 seconds

Other RADIUS Protocol Notes

The requestor implementation only attempts to use authentication. It does not ask the server to store any accounting information. It allows for a single node secret for each Screen. Theoretically you could use a distinct node secret for each server. This approach was not used. Rather than complicate configuration by allowing any given Screen to have multiple node secrets (one for each server), a simpler, easier to configure approach ws chosen.

RADIUS Testing

The requestor implementation has been tested against two commercial server implementations provided with BSDI's BSD/OS. The first version tested was included in BSD/OS Version 3.1, and is derived from the Livingston reference implementation. The second version is as delivered in BSD/OS Version 4.x; this version is based on the University of Michigan Merit AAA RADIUS server implementation.

Testing is done against Sun Directory Services (SDS) and ACE/Server 3.2 SecurID authentication.

RADIUS Usage

As discussed in the earlier part of this chapter, the RADIUS authentication mechanism is used within SunScreen in the form of a (SPECIAL) External Method. (See "SPECIAL External Method Authentication".)

You can use RADIUS authentication of a user only within the proxy context in SunScreen. You cannot use RADIUS authentication for authenticating an administrative user.

RADIUS users are permitted by connecting a SPECIAL proxyuser entity with one or more proxy policy rules. This connection can be directly in the rule or by inclusion in a group used in the rule. (See "Proxy Users".)

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".)