Setting up XAuthRadius to connect to a Radius Server on a non-default port.

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

Description:

A SiteMinder component exists for extended Radius authentication. This document describes how to configure it for a non-default port as well as additional troubleshooting information.

Solution:

A SiteMinder component exists for extended Radius authentication. This component adds additional functionality to the default out of box implementation of the RADIUS authentication scheme.

There is currently a logging bug in the latest XAuthRadius dll. This bug results in an incorrect port being printed out in the SiteMinder policy server trace file (smtracedefault.log). The offending line is below:

SmAuthUser.cpp:287][ServerTrace][][][][][][][][Server and Port are '127.0.0.1:12345', 1645.
Secret is 9 bytes (output suppressed for security)][][][][XauthRADIUS: Server and Port are
'127.0.0.1:12345', 1645.  Secret is 9 bytes (output suppressed for security)]

In order to properly configure XAuthRadius to connect to a non default port you must use the following configuration format:

default.ip=127.0.0.1:12345
default.secret=foosecret
default.timeout=10
default.retries=3

Notice that the IP field is in the form IP:Port. While the log may indicate that the port is not being taken it actually is being used internally in the code. This can be verified later on when the XAuthRadius module actually connects to the RADIUS server (a log statement will be printed out).

Other things to look for when configuring XAuthRadius:

• Check that the user can log in normally with basic authentication.
  
  
• Double check that the paths in the authentication scheme to the configuration file is correct. Sometimes people miss a dot or backslash.
  
  
• Make sure you are not missing any commas. While some of the values may be left blank you must include the comma. Check the official XAuthRadius documentation for more details.
  
  
• Make sure that there is no firewall between the policy server and the RADIUS server. Double check this by using telnet from the policy server.
  
  
• The second parameter in the RADIUS authentication scheme is the name of a attribute in LDAP. Common attributes are sn, mail, uid, audio, etc. This attribute is where XAuthRadius looks when you want to specify a specific XAuthRadius configuration for a user. For example the following configuration creates a RADIUS server named "jeff":

  jeff.ip=127.0.0.1:12345
  jeff.secret=foosecret
  jeff.timeout=10
  jeff.retries=3

If I wanted a LDAP entry to only use this server I would first specify an attribute in the authentication scheme. In a production environment the recommendation would be to modify the LDAP schema and create a new attribute such as 'radiusserver'. Put this attribute name in the authentication scheme. The entry would then have radiusserver=jeff. This would cause the authentication scheme to use the specific RADIUS server in the configuration file.

Environment

Release:
Component: SMXRDS