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:

• Security Dynamics ACE/Server Version 3.2 and 3.3

• Sun Directory Services (SDS)

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.

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:

• Address object definition for the RADIUS servers

• Access rules allowing RADIUS protocol access to those servers

• Configure the RADIUS Requestor to use the defined server Address object(s)

• Configure the RADIUS Requestor with SunScreen EFS 3.0s node secret

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.

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.

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.

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.

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.

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.