Authorized Users

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: (1) simple-text password or (2) 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

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

The authorized user and proxy user objects can be created and managed by both the administration GUI and the command line interface. The administration GUI pages that manipulate these objects have already been elaborated in the administration GUI chapter. This section describes the attributes of these objects and their manipulation using the command line.

The authorized user object contains the following items:

• name  name of the entity (1 to 255 characters)

• enable | disable - the flag for the entire object. If disabled, authentication of the associated user is always denied. The default is enabled.

• password={ pwitem } - (optional) a simple-text password for this user.

• securid={ siditem } - (optional) a SecurID mapping for this user.

• real_name="rnstr" - (optional) a demographic string that can be used to identify the person in a more readable form.

• contact_info="cistr" - (optional) a demographic string that can be used to automate contact with the person (for example, electronic mailbox address).

• description="descstr" - (optional) a demographic string that can be used to store other notations about the person.

  ---

  Note -

  Either a password or securid item or both must be present for any authorized user object.

  ---

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

The password= item has the following subitems:

• passwd - the plaintext password string; should either be empty (for example, "") or contain a one-to-eight character password; if this field is nonempty, then the next subitem (crypt_password=) should not occur.

• crypt_password=cryptpasswd - (optional) the encrypted version of the plaintext password string; if this subitem is present, then the plaintext password string (above) should be empty

• enabled | disabled - the flag for this simple-text password authentication method. If disabled, any password presented for authentication of this user is not compared against this subitem. The default is enabled.

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 fact 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:

• "securidname" - User login name associated with this users SecurID token in the ACE/Server database

• enabled | disabled - The flag for this SecurID authentication method. If disabled, any password presented for authentication of this user is not submitted to the ACE/Server. The default is enabled.

  ---

  Note -

  If both simple-text and SecurID methods exist in a single authorized user object, the simple-text method should be presented first.

  ---

Creating an Authorized User Object

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

• add "name" item... - creates or overwrites an object; takes a complete description of the object, beginning with its name, followed by desired items and subitems as defined above.

• delete "name" - deletes a named object

• print[,sortopt] ["name"] - display one or more objects; if an object's name is given, then only that object's definition is displayed; otherwise all authorized user objects are displayed

• names [,sortopt] - display the names of all objects sortopt can be:

  • asc - ascending order by name (case-sensitive)

  • desc - descending order by name (case-sensitive)

  • iasc - ascending order by name (case-insensitive)

  • idesc - descending order by name (case-insensitive)

  • raw - order stored in database

    The default is asc.

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, it is unlikely that any add operation will yield a particular crypt_password= encoding of any given plaintext password. In fact, there are 4096 different encryptions of any given plaintext password.

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.

An alternate means of creating the above authorized user object, while logged in to 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.

The following is an example of what you type, while logged into the primary Screen, to re-create the above authorized user object so that it is disabled:

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"

The following is an example of what you type 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"

The following is an example of what you type 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"

The following is an example of what you type 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"

The following is an example of what you type 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"jeff.hogg" "admin"

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