authuser Database

authuser is intended to correspond one-to-one with actual persons. The authuser entity contains parameters that are required to verify the authenticity of a given individual authuser.

Entities do not reflect user roles; that is what the proxyuser entities are for.

authuser entities allow authentication by simple password or SecurID token PASSCODE (a given authuser can be configured for both types; satisfying either one is sufficient to cause authentication).

authuser entities provide for multiple simple passwords; however, the administration GUI is only prepared to deal with zero or one.

authuser entities have the following required items:

name -- However, to be of any great use, at least one of the following authentication mechanisms must also be given:

PASSWORD={ plain-text [ CRYPT_PASSWORD=crypt-text ] enabler }

SECURID={ securid-name enabler }

If the CRYPT_PASSWORD item is given, the plain-text is given as "" (empty placeholder string).

Any PASSWORD item(s) precedes a SECURID item, and only one SECURID item is allowed or used (ACE/Server contains a mechanism to allow a given user to use multiple token devices).

authuser entities have the following optional items:

• enabler

• CONTACT_INFO=contact-info-string

• DESCRIPTION=desc-string

• REAL_NAME=real-name-string

The administration GUI only expects zero or one of each of the above, but the command-line tools do not restrict their numbers.

authuser passwords are stored in encrypted form (DES Unix /etc/passwd style, up to eight characters).

When the configuration editor is presented with a plain-text password, it translates it into an encrypted item, because it cannot display plain-text form.

The configuration editor stores the encrypted items directly and uses them during database build operations. When you do not know a user password, they can also be used to paste-in user passwords from /etc/passwd.

authuser example with simple password authentication:

edit> authuser add harry.bovis password={ secret }edit> authuser print harry.bovis "harry.bovis" ENABLED
PASSWORD={ "" CRYPT_PASSWORD="upO7711Q0CRaA" ENABLED }

Output of print is actually a single, long line.

If you try this example, the password encryption logic will probably generate a different crypt-text string for the password "secret". There are 4096 different possible encryptions for any given plain-text password.

authuser example with SecurID authentication:

edit> authuser add larry.hovis securid={ lhovis }edit> authuser print larry.hovis "hovis" ENABLED SECURID={
"lhovis" ENABLED }

authuser example, with both simple password and SecurID authentication:

edit> authuser add ac-dc password={ rockU } securid={ acdc }
edit> authuser print ac-dc "ac-dc" ENABLED PASSWORD={
"" CRYPT_PASSWORD="fOE25hj8FhvIM" ENABLED } SECURID={ "acdc" ENABLED
} 

Output of print is actually a single, long line.

proxyuser is intended to provide the idea of user roles to control the inclusion of users within groups used by Screen rules (through the GROUP entity type); they provide a means of mapping authentic users into their roles (user identities) on backend server systems (through the AUTH_USER_NAME or BACKEND_USER_NAME items); and they provide inclusion of external user authentication means (through the RADIUS item).