RADIUS Node Secret Configuration

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 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 (The default is enabled.)

In multiple-Screen installations, the sys= item allows 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 proper handling of node secrets that are longer than 31 characters. If you intend to use longer values, determine that your server or servers 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 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 } { } ...

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--secret
edit> vars add sys=sf-screen prg=auth name=RADIUSNodeSecret
 value=sf--secret

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.

Other vars for RADIUS Configuration

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 requestor logic avoids contacting an unresponsive server for this many seconds:

edit> vars print PRG=auth
  PRG="auth" NAME="RADIUSHolddown" ENABLED VALUE="300" 
DESCRIPTION="seconds to ignore a non-responsive RADIUS server"

The requestor logic makes this many passes through the server list 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 amount of time to wait for each response 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 TIMES (#passes + 1) TIMES timeout

This is an upper-bound because of the way the first pass avoids recently unresponsive servers; a lower-bound would be:

# servers TIMES (#passes - 1) TIMES 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