SunScreen 3.2 Administrator's Overview

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.