test

SunScreen EFS Release 3.0 Reference Manual

User Authentication

SunScreen EFS 3.0 provides the ability to configure user entities. These entities are used to authenticate administrators of Screens and to allow access through the Screen when using proxied services.

Authentication provides the ability to verify the identity of users. The user facilities of SunScreen EFS 3.0 employ both internal and external means of proving user identity. Further, user entities can be configured in various ways depending on the role or roles they are to play with respect to SunScreen EFS 3.0 administration and use.

SunScreen EFS 3.0 proxies provide a means to validate, regulate, and extend the abilities of certain services beyond those afforded by kernel-based stateful packet filtering.

SunScreen EFS 3.0 User Model

The SunScreen EFS 3.0 user model provides two levels of user identification. These are the Authorized User (abbreviated authuser) and the Proxy User (abbreviated proxyuser).

Authorized Users

The Authorized User is represented as a named common object. Each such object is intended to describe an individual human user distinct from all others. The attributes of an Authorized User provide a repository for demographic and authentication data about that individual.

Authorized User objects contain information sufficient to allow authentication of users of SunScreen EFS 3.0. Validation information can either be: (1) simple text password or (2) SecurID(R) token PASSCODE; users can also be configured to have both means of authentication.

Access to and use of the administrative functions of SunScreen EFS 3.0 require the establishment of the Authorized User identity before administration is allowed. Both the Login Screen of the administration GUI and the login sub-command of the ssadm command line facility reference an Authorized User object.

Authorized User authenticity establishes only the identity of a user, but does not itself describe any of the various roles a user can play in use of SunScreen EFS 3.0. Role establishment is afforded in one of two ways: (1) reference within the User field in the administrative access rules of a policy, (2) reference from a packet filtering rule that utilizes user authentication (proxies).

Proxy Users

The Proxy User is a named common object, and is distinct from the Authorized User. Proxy Users are either SIMPLE or GROUP objects. A SIMPLE object is used to provide for and establish an association between an individual human and a role that human plays in usage of the facilities controlled by SunScreen EFS 3.0. GROUP objects are used to allow creation of collections of SIMPLE Proxy Users that share common access to facilities; GROUPs streamline the task of allowing or removing access to established facilities.

Some special Proxy User objects also provide the means to map external collections of users into the access control facilities of SunScreen EFS 3.0. In SunScreen EFS 3.0, external access to SecurID(R) 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 following diagram summarizes the relationship between Rules, Authorized Users, Proxy Users, and external user databases:

Graphic

The names of Authorized Users and Proxy Users are distinct, and it is perfectly allowable to have objects with identical names in each. You should 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 (distinguished names, employee numbers, etc.) and Proxy Users by names that reflect their normal user login names deployed on server systems (for example: Unix login name). Names cannot contain any of the following characters:

"!", "#", "$", "%", "^", "&", "*", "{", "}", "[", "]", "<", ">", """, "', "?", "`", "/", "@", or NUL characters.

Space, tab, and other whitespace characters are allowed in names, but in doing so you should be prepared to supply quotation marks in some situations in order to protect such whitespace within names.

Note -

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.

Authorized User Object Definition

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:

The password= and securid= items define authentication methods for the Authorized User.

The password= item has the following sub-items:

"passwd"-- the plain-text password string; should either be empty (for example, "") or contains a one to eight character password; if this field is non-empty, then the next sub-item (crypt_password=) should not occur.

crypt_password="cryptpasswd" -- (optional) the encrypted version of the plain-text password string; if this sub-item is present, then the plain-text password string (above) should be empty enabled | disabled enablement flag for this simple-text password authentication method; if disabled, any password presented for authentication of this user is not compared against this sub-item; the default is enabled.

Note -

The processing of passwd and crypt_password= sub-items 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 plain-text using the (non-empty) passwd sub-item. Thereafter (for example, whenever the object is edited), the crypt_passwd= sub-item can be used to retain a password without having to know (or retype) the plain-text 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 EFS 3.0 user descriptions without the SunScreen EFS 3.0 administrator needing to know the users plain-text passwords. This fact also means that the content of the SunScreen EFS 3.0 Authorized User database is maintained with file permissions that prevent access from all but root users of the SunScreen EFS 3.0.

The securid= item has the following sub-items:

"securidname" -- User login name associated with this users SecurID token in the ACE/Server database enabled | disabled enablement flag for this SecurID authentication method; if disabled, any password presented for authentication of this user is not be 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.

Authorized User Object Creation

The Authorized User object is manipulated using the authuser sub-command 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 sub-items as defined above.

delete "name"-- deletes a named object

print[,sortopt] ["name"]-- display one or more objects; if an object name is given, then only that objects definition is displayed; otherwise all Authorized User objects are displayed

sortopt can be:

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

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 Initialedit> authuser print jeff.hogg"jeff.hogg" ENABLED
PASSWORD={ "" CRYPT_PASSWORD="s8Q2DZRw4tmGk" ENABLED }
DESCRIPTION="large and in charge" REAL_NAME="Jeff
Hogg"

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

Note -

Although the output produced by 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.

Also, although print outputs all tag names in capital letters (for example, REAL_NAME=), these tags are recognized in a case-insensitive manner on input (for example, real_name= and REAL_NAME= are equivalent.)

Note -

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 plain-text password. In fact, there are 4096 different encryptions of any given plain-text 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 Initialedit> 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 plain-text form.

An alternate means of (re)creating the above Authorized User object, while logged in to the primary Screen:


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

Note -

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

Tip -

It is not necessary to type save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered.

If you attempt to save without changing entities other than these types, you are reminded by a message:


edit> savelock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Note -

See Chapter 3, "Administration Graphical User Interface Reference" for more information regarding which common objects do not require the use of save.

Once changes have been made to Authorized User objects, the system configuration must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

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

The following is an example of what you type to re-create the above Authorized User object but causing it to be 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"

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 Initialedit> 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 Initialedit> 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 Initialedit> 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, then, 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 sub-item; 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.

Proxy User Object Definition

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 be used: (1) none, (2) an Authorized User object, (3) an external authentication mechanism.

The relationship between SIMPLE Proxy Users and authentication mechanism was shown in an illustration previously.

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 -

In SunScreen EFS 3.0, 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:

User object to be used to authenticate this user role; if absent, and if no SPECIAL item is present, then the Proxy User object requires no authentication:

A GROUP Proxy User object contains zero or more of the following items:

Proxy User Object Creation

The Proxy User Object is manipulated using the proxyuser subcommand of ssadm edit. proxyuser takes one of the following as commands:

sortopt can be:

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

The following is an example of what you type to display existing Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> 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"

The following is an example of what you type to create the above SIMPLE Proxy User object, while logged into the primary Screen:


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

The following is an example of what you type 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 Initialedit> proxyuser add proxyusers group description="users allowed through FTP and telnet proxies"

Note -

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

Next, is an example of what you type to add the members of the example GROUP:


edit> proxyuser addmember proxyusers radiusedit> proxyuser addmember proxyusers jdh

Note -

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.

Note -

It is not necessary to type save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered.

If you attempt to save without changing entities other than these types, you are reminded by a message:


edit> savelock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Note -

See Chapter 3, "Administration Graphical User Interface Reference" for more information regarding which common objects do not require the use of save.

Once changes have been made to Proxy User objects, the system configuration must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

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

The following is an example of what you type to remove a member reference from a GROUP Proxy User object, while logged into the primary Screen:


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

The following is an example of what you type to display all Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> 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"

The following is an example of what you type to display the names of all Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> 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 by the processing logic upon them.

There are fundamentally two types of authentication processing performed in SunScreen EFS 3.0. 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 you are 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," which follows.)

The first type of processing is the authentication of an Authorized User object directly. This form occurs when authenticating an administrator of SunScreen EFS 3.0, either through the administration GUI Welcome page or by the ssadm login sub-command. 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 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 pre-installed anonymous and ftp Proxy User objects are examples of this type of authentication.

Note -

There is nothing special about the names anonymous and ftp for these pre-installed objects. You can create additional null authentication Proxy User objects and use them in-lieu of or in addition to the pre-installed 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:


/extmethodname/backendusername

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


/radius/jeffh

/securid/jeffh

Note -

There is nothing special about the names radius and securid in these pre-installed SPECIAL objects; they are distinguished by their special radius or securid items. You can create additional SPECIAL authentication methods and use them in-lieu of or in addition to the pre-installed ones. This allows the creation of 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. Interestingly, note that there are two means for utilizing SecurID tokens for authentication: one within the Authorized User object, the other through SPECIAL external Proxy User object. 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 EFS 3.0 Authorized User object and a specific SecurID tokenholder. The SPECIAL external authentication mechanism allows, in essence, any user that SecurID authenticates to satisfy its rigor.

Thus, depending upon the security requirements of your site, you can choose the mechanism to employ. Notably, the ability to establish authenticity for purposes of SunScreen EFS 3.0 administration is never available to SPECIAL external authentication.)

User Access Control Processing Logic

As previously referenced, once an identity is supplied, the would-be user is authenticated. It is still required that this (now authentic) user be allowed to perform the operation presently being attempting. 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 EFS 3.0 administrative activities and usage of network facilities controlled by FTP and telnet proxies.

Access control logic regarding SunScreen EFS 3.0 administration is covered in various other sections of this and other manuals. However, 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 EFS 3.0 proxies that perform user authentication do so by requiring a Proxy User object to be referenced by their rules. 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 referenced by the rule; if so, then the associated rule matches. (See below for more details regarding proxy rule matching.)

RADIUS User Authentication Processing Details

The RADIUS protocol provides the ability to centralize user authentication databases for widespread uniform deployment throughout organizations. RADIUS was originally developed for use by terminal-server devices, but its open specification and reference implementation have allowed it to achieve a sort of universal joint interconnection status in the world of external authentication mechanisms. 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 EFS 3.0 to tap into authentication using LDAP user databases.

With respect to a RADIUS server, the Screen plays the role of a client host or, for our purposes, a RADIUS Requestor.

Note -

The term client is quickly subordinated here, to avoid any confusion with clients of SunScreen EFS 3.0-provided services.)

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 server(s) 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 EFS 3.0 comes installed with nearly all parameters prefigured for immediate use. Four remaining configuration elements needing post-installation attention are:

The SunScreen EFS 3.0 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 -

It is suggested that a single Address group object be defined to collect all RADIUS servers for ease in creating server access rules.

To allow the RADIUS Requestor to function, the Screen must be configured to allow it access to the server(s) through the radius service Common Object, which comes pre-installed.

RADIUS Server Configuration

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

The "RADIUSServers" variable can either be global or Screen-specific.

It contains the following items:


sys=Screen				(optional)

prg=auth

name=RADIUSServers

values={ host=server ... }		(name(s) of address object(s)

of RADIUS server(s))

description="descriptive text"	(optional)

enabled | disabled			(default is enabled)

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 global "RADIUSServers" variable. Another is to use "avoid SCREEN" attributes on Address objects and instead use the sys= item to create Screen-specific "RADIUSServer" variables. Of course, combinations are also possible. And, naturally, the logic prefers Screen-specific Address objects and variables, over global ones.

The Address object(s) (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 -

Due to the way SunScreen EFS 3.0 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 sub-items in the values={...} of the RADIUSServers 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(s). Because of the way RADIUS operates, only the RADIUS Requestors have node secrets (not the servers).

The same value configured for "RADIUSNodeSecret" 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.)

The "RADIUSNodeSecret" variable is normally Screen-specific. It contains the following items:


sys=screen				(optional)

prg=auth

name=RADIUSNodeSecret

value="nodesecret"			(node secret string)

description="descriptive text"	(optional)

enabled | disabled			(default is enabled)

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

Caution - Caution -

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

Once Addresses, Rules, and variables have been established, the configuration must be activated 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.

The following is an example of what you type to create address objects, while logged into the primary Screen:


admin% ssadm -r primary edit ConfigNameedit> 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 } { } ...

The following is an example of what you type to create a rule to allow RADIUS-Requestor-to-server access, while logged into the primary Screen:


edit> add rule radius localhost radsvrs ALLOW

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

The following is an example of what you type to create RADIUS node secret variables, while logged into the primary Screen:


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

Save and activate the configuration:


edit> saveedit> quitadmin% ssadm -r primary activate configname

For example, given a valid, RADIUS-hosted user gooduse 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 goodpassUser  /radius/gooduser
 authenticated and mapped to backend user  gooduser

admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduseranythingelse

User  /radius/gooduser  failed authentication.

admin% ssadm -r la-screen lib/user_authenticate -v /radius/baduseranything

User  /radius/baduser  failed authentication.

Note -

lib/user_authenticate is a low-level program used internally to perform user authentication; its interface is not supported for general use. It echoes the password as it is typed.