The RADIUS protocol provides the ability to centralize user authentication databases for widespread uniform deployment throughout organizations. 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 to tap into authentication using LDAP user databases.
With respect to a RADIUS server, the Screen plays the role of a RADIUS Requestor.
The term client becomes confused with clients of SunScreen-provided services so the term requestor is used. It also describes the relationship between the RADIUS server and the Screen more accurately.
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 servers 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 comes installed with nearly all parameters prefigured for immediate use. Four remaining configuration elements needing postinstallation attention are:
Define address object for the RADIUS servers
Define access rules allowing RADIUS protocol access to those servers
Configure the RADIUS Requestor to use the defined server address object or objects
Configure the RADIUS Requestor with SunScreen's RADIUSNodeSecret
The SunScreen 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.
Define a single address group object to collect all RADIUS servers for ease in creating server access rules.
To enable the RADIUS Requestor to function, the Screen must be configured to allow it access to the servers through the radius service common object, which comes preinstalled.
The RADIUS Requestor learns of its RADIUS servers and node secret from the variables RADIUSServers and RADIUSNodeSecret, respectively.
TheRADIUSServers variable can either be global or Screen-specific.
It contains the following items:
sys=Screen (optional)
prg=auth
name=RADIUSServers
values={ host=server ... } --Address object names or IP addresses or both of one or more RADIUS servers
description="descriptive text" (optional)
enabled | disabled -- The 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 globalRADIUSServers variable. Another is to avoid the use of SCREEN attributes on address objects and instead use the sys= item to create Screen-specificRADIUSServers variables. Of course, combinations are also possible. Naturally, the logic prefers Screen-specific address objects and variables over global ones.
The address object or objects (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.
Because of the way SunScreen 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 subitems in the values={...} of theRADIUSServers variable.
The RADIUSNodeSecret variable specifies a character string to use for security and authenticity when interacting with the configured RADIUS server or servers. Because of the way RADIUS operates, only the RADIUS requestors have node secrets (not the servers).
The same value configured forRADIUSNodeSecret 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.)
TheRADIUSNodeSecret variable is normally Screen-specific. It contains the following items:
sys=screen (optional)
prg=auth
name=RADIUSNodeSecret
value="nodesecret"
description="descriptive text" (optional)
enabled | disabled -- The default is enabled.
In multiple-Screen installations, the sys= item enables you to configure different node secrets for each Screen.
Because shortcuts were taken by some reference implementations, a common deficiency in RADIUS servers is the handling of node secrets that are longer than 31 characters. If you intend to use longer values, first determine that your server or servers can handle them correctly.
Once you establish addresses, rules, and variables, you must activate the configuration to propagate the changes.
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 are examples of typical RADIUS configurations:
To create address objects, while logged into the primary Screen:
admin% ssadm -r primary edit ConfigName edit> 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 } { } ... |
To create a rule to allow RADIUS Requestor-to-server access, while logged into the primary Screen:
edit> add rule radius localhost radsvrs ALLOW |
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" |
To create RADIUS node secret variables, while logged into the primary Screen:
edit> vars add sys=la-screen prg=auth name=RADIUSNodeSecret value=la-secret edit> vars add sys=sf-screen prg=auth name=RADIUSNodeSecret value=sf--secret |
To save and activate the configuration:
edit> save edit> quit admin% ssadm -r primary activate ConfigName |
For example, given a valid, RADIUS-hosted user gooduser 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 goodpass User /radius/gooduser authenticated and mapped to backend user gooduser admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduser anythingelse User /radius/gooduser failed authentication. admin% ssadm -r la-screen lib/user_authenticate -v /radius/baduser anything User /radius/baduser failed authentication. |
The following additional variables are preinstalled and used to control the RADIUS client protocol; they are pre-ENABLED and generally need not be altered.
The number of seconds that the requestor logic waits before contacting an unresponsive server:
edit> vars print PRG=auth PRG="auth" NAME="RADIUSHolddown" ENABLED VALUE="300" DESCRIPTION="seconds to ignore a non-responsive RADIUS server" |
The number of passes through the server list that requestor logic makes before giving up:
PRG="auth" NAME="RADIUSRetryPasses" ENABLED VALUE="3" DESCRIPTION="how many times to try each RADIUS server" |
The name of the RADIUS server port, as given in the Service registry:
PRG="auth" NAME="RADIUSService" ENABLED VALUE="radius" DESCRIPTION="RADIUS service / port # at which to query server(s)" |
The number of seconds for each response that requestor logic waits before sending another attempt:
PRG="auth" NAME="RADIUSTimeout" ENABLED VALUE="5" DESCRIPTION="seconds to await each RADIUS server response" |
The requestor logic attempts to contact only servers that have not been held down during the first pass; subsequent passes contact each server regardless of previous nonresponsiveness. During the first pass, each server is contacted twice in a row before moving onto the next one. During subsequent passes, each server is only contacted once. A rough upper-bound on the overall time for total failure for all servers is:
#servers x (#passes + 1) x timeout
This is an upper-bound because of the way the first pass avoids recently unresponsive servers; a lower-bound would be:
#servers x (#passes - 1) x timeout
So, for example, with two servers configured and using the default time-outs, the overall failure time-out would be less than 2 x (3 + 1) x 5 = 40 seconds, and greater than 2 x (3 - 1) x 5 = 20 seconds
The requestor implementation only attempts to use authentication. It does not ask the server to store any accounting information. It allows for a single node secret for each Screen. Theoretically you could use a distinct node secret for each server. This approach was not used. Rather than complicate configuration by allowing any given Screen to have multiple node secrets (one for each server), a simpler, easier to configure approach ws chosen.
The requestor implementation has been tested against two commercial server implementations provided with BSDI's BSD/OS. The first version tested was included in BSD/OS Version 3.1, and is derived from the Livingston reference implementation. The second version is as delivered in BSD/OS Version 4.x; this version is based on the University of Michigan Merit AAA RADIUS server implementation.
Testing is done against Sun Directory Services (SDS) and ACE/Server 3.2 SecurID authentication.
As discussed in the earlier part of this chapter, the RADIUS authentication mechanism is used within SunScreen in the form of a (SPECIAL) External Method. (See "SPECIAL External Method Authentication".)
You can use RADIUS authentication of a user only within the proxy context in SunScreen. You cannot use RADIUS authentication for authenticating an administrative user.
RADIUS users are permitted by connecting a SPECIAL proxyuser entity with one or more proxy policy rules. This connection can be directly in the rule or by inclusion in a group used in the rule. (See "Proxy Users".)