Chapter 7 Using the RADIUS Server

The RADIUS server provided with Sun Directory Services offers an authentication service for remote users. It also collects accounting information on remote user connections.

This chapter presents the RADIUS authentication and RADIUS accounting architecture, and explains how to configure the RADIUS server. It also describes the mapping of RADIUS attributes to LDAP directory attributes.

RADIUS Authentication Architecture

The RADIUS server provided with the Sun Directory Services is an authentication and authorization information server for a Network Access Server (NAS). A NAS is a device that provides an access point to the network for remote users connecting using SLIP, PPP, or any other remote access protocol. The NAS transmits the information provided in the connection request from the remote user to the RADIUS server. The RADIUS server checks this information against the entry for the remote user in the directory. It then returns to the NAS an authorization or denial for the remote user connection. It can also provide the appropriate connection parameters for the remote user connection.

The RADIUS server logs information on remote user access requests in the dsradius.log file in the directory /var/opt/SUNWconn/ldap/log.

A NAS is also often referred to as a remote access server or RAS.

The authentication architecture is illustrated in Figure 7-1.

Figure 7-1 RADIUS Authentication Architecture

The user is the entity requesting access to network resources. In the directory database, a user is identified by a unique uid. The uid attribute, and all other attributes describing a remote user, are defined in the remoteUser object class.

The Network Access Server, also called a client, is the device to which remote users connect. The client queries the RADIUS server for authentication status, user profiles and authorizations. In the directory database, a client is identified by a unique ipHostNumber. The ipHostNumber attribute, and all other attributes describing a RADIUS client are defined in the nas object class.

The RADIUS server authenticates the NAS, then checks the remote user's identity and authorization in the directory database. It returns the user's status and configuration information to the NAS.

If the RADIUS server is unable to authenticate the NAS, the request from the NAS is ignored. The RADIUS server does not respond, even with a connection rejection.

RADIUS Accounting

A NAS can send accounting information on remote user connections to the RADIUS server. This information is logged separately for each NAS in a log file called detail in a log directory called /var/opt/SUNWconn/ldap/radacct/nasname, where nasname is the value of the common name (cn) attribute in the directory entry for the NAS.

If the RADIUS server is unable to authenticate the NAS, accounting information is nonetheless logged, although it is marked as unverified in the nasname/detail file.

All the accounting information provided by the NAS is logged.

Accounting information can also be logged dynamically in the remote user's directory entry: it is added when the user connects, and deleted when the user disconnects.

To configure the RADIUS server to log dynamic accounting information, refer to "Configuring the RADIUS Server".

With dynamic accounting enabled, the following attributes are automatically added to a remote user's entry when the user connects, and removed when the user disconnects:

• Dynamic IP address -- the IP address assigned to the remote user connection

• Dynamic session ID --the accounting session ID assigned to a remote user for a given session

• Dynamic session counter --the number of concurrent open sessions

• Dynamic IP address binding -- the association between the IP address and the accounting session ID for a given session

You can specify other attributes to be added dynamically to remote users' entries by listing them in the acctattr file. Refer to "Configuring Dynamic Accounting" for details of how to modify this file.

RADIUS Entries in the Directory

In the directory, there are two types of RADIUS entries, represented by two object classes:

• nas object class for NAS entries

• remoteUser object class for remote user entries

The nas object class inherits from the device object class. The mandatory attributes of the nas object class are iphostNumber and sharedKey. Refer to "Attribute Reference" for a description of these attributes.

The optional attributes of the nas object are dictionaryFile and acctattrFile. The use of these attributes is described in detail in "Specifying a Dictionary File", and "Configuring Dynamic Accounting".

The remoteUser object class is an auxiliary object class that can be used with any structural object class, for example the person or organizational person object class. The remoteUser object class contains just two mandatory attributes, uid and groupCheckInfo. The uid is always passed in the connection request transmitted by the NAS to the RADIUS server. It is the key attribute used in the search filter applied by the RADIUS server to look for the remote user's entry in the directory. The groupCheckInfo attribute lists the attributes (except uid) that the RADIUS server must check before granting access to a user.

The optional attributes of the remoteUser object class are the LDAP translation of the RADIUS attributes. They define all the possible connection parameters that can be passed in a connection request transmitted by the NAS to the RADIUS server. The RADIUS server will check these parameters against the values of the attributes stored in the directory entry for the remote user, provided they are listed in the groupCheckInfo attribute.

For the full list of optional attributes of the remoteUser object class and their description, refer to "Object Class Reference" and "Attribute Reference".

Initializing the RADIUS Server

When you initialize the RADIUS server, both authentication and accounting are enabled. There are two separate dsradiusd processes for authentication and accounting.

You can initialize the RADIUS server provided by Sun Directory Services in two ways:

• From the Admin Console

• From the command line

To initialize the RADIUS server from the Admin Console:

In the Status section, highlight RADIUS in the list of services, and click Start.

The RADIUS service is started.

To initialize the RADIUS server from the command line:

As root, run this script to start the dsradiusd daemon:

# /opt/SUNWconn/ldap/sbin/dsradius start

Configuring the RADIUS Server

Through the Admin Console, you can configure the following parameters for the RADIUS service:

• The naming contexts that the RADIUS server will search for user information and for NAS information. These naming contexts must be part of the tree managed by the directory server.

• Blocking Mode: that is the number of permitted consecutive failures to authenticate a user based on the password provided. Any further attempt is systematically blocked, even if the connection parameters supplied are correct. The count is reset on first success. To disable blocking mode, write zero in the Blocking Mode field.

• Whether you want to record dynamic accounting data in the directory entries of remote users (see "Configuring Dynamic Accounting").

• The maximum number of threads that the RADIUS server will create.

• The ports on which the RADIUS processes listen for authentication requests and accounting reports.

• The directory where accounting information is stored.

• The maximum time a client will wait for a response from the RADIUS server.

The directory server queried by the RADIUS server is always localhost.

To configure these parameters, go to the RADIUS section in the Admin Console. The configuration is saved in the mapping file /etc/opt/SUNWconn/ldap/current/mapping/radius.mapping.

Blocking mode and dynamic accounting settings are not taken into account when the RADIUS search is performed on a referral server.

Advanced Configuration of RADIUS Searches

Through the Admin Console, you can perform a basic configuration of the naming contexts that the RADIUS server will search for user and NAS information. You can manually edit the radius.mapping file to:

• Provide temporary access to a remote user whose entry is not in the naming context normally searched for users

• Associate remote users with a particular NAS, and grant access through that NAS only

• Combine the options above to provide temporary access through a specified NAS

• Manage remote users connecting from a virtual domain

The naming contexts searched by the RADIUS server are specified in the /etc/opt/SUNWconn/ldap/current/mapping/radius.mapping file. In the Dynamic section of the USERS table, the following lines define access for remote users:

BaseDN= l=Paris, o=xyz, c=us
FILTER=(&(Objectclass=remoteUser)(uid=$UserID))

In this example, the RADIUS server searches for the user ID passed in the request from the NAS in the naming context l=Paris, o=XYZ, c=US among all entries with an object class of remoteUser.

Providing Temporary Access

Without changing your basic configuration, you can allow temporary access to a remote user whose entry is in a different naming context.

1. In the Dynamic section of the USERS table, add a BaseDN and FILTER token to the configuration with the prefix TMP_ , and assign temporary values, using the following format:

   TMP_BASEDN = new_search_baseTMP_Filter = (&(Objectclass=remoteUser)(uid=$UserID)(uid=userid))

   where:

   • new_search_base is the naming context that holds the remoteUser entry for the person to whom you are granting temporary access. If this naming context is stored on a different server, ensure that a referral is defined between the two servers

   • userid is the actual userid of the remote user. This ensures that you grant access to that user alone, and not to all the entries with the object class remoteUser in the new search base

2. Restart the dsradiusd daemon so that the new configuration file is taken into account.

   # /opt/SUNWconn/ldap/sbin/dsradius stop
   # /opt/SUNWconn/ldap/sbin/dsradius start

   For example, if your Base DN for remote users is l=Paris, o=XYZ, c=US, and you want to provide temporary access to the remote user Felipe Gonzalez located in Madrid, you would change the local radius.mapping file to include:

   BaseDN= l=Paris, o=xyz, c=us
   TMP_BaseDN= l=Madrid, o=xyz, c=us
   FILTER=(&(Objectclass=remoteUser)(uid=$UserID))
   TMP_Filter=(&(Objectclass=remoteUser)(uid=$UserID)(uid=fgonzalez))

   This example assumes that a referral exists between the local directory server and the directory server holding the naming context l=Madrid, o=XYZ, c=US.

   If you want to temporarily extend permission to all remote users within the XYZ corporation, you would use the following temporary base DN token:

   TMP_BaseDN= o=xyz, c=us

   This example assumes that there is a default referral from the server that holds the l=Paris, o=XYZ, c=US data store to the server that holds the o=XYZ, c=US data store. It also assumes that the o=XYZ, c=US data store contains referral entries to all data stores held on other servers.

Restricting Access through a Specified NAS

You may want to ensure that remote users always connect to a specific NAS. For example, if you want to control communications costs, you can ensure they connect to the NAS that is geographically closest to them.

1. In the Dynamic section of the USERS table, add a BaseDN and FILTER token to the configuration with the suffix _nasname, and assign temporary values, using the following format:

   BASEDN_nasname= search_baseFilter_ nasname= (&(Objectclass=remoteUser)(uid=$UserID))

   where:

   • nasname is the name of the NAS (value of the cn attribute in the directory entry for the NAS)

   • search_base is the naming context that holds the directory entries for the remote users to whom you are granting access through the NAS

2. Restart the dsradiusd daemon so that the new configuration file is taken into account.

   # /opt/SUNWconn/ldap/sbin/dsradius stop
   # /opt/SUNWconn/ldap/sbin/dsradius start

   For example, your Base DN for remote users is l=France, o=XYZ, c=US, and you have remote users located in Paris, Lyon, and Toulouse who can connect to the network through a local NAS at each site. The NAS names are ParisNAS, LyonNAS, and ToulouseNAS respectively. You want to ensure that remote users always connect through the nearest NAS to save on communication costs.

   You would change the radius.mapping file to include:

   BaseDN= l=France, o=xyz, c=us
   BaseDN_ParisNAS= l=Paris, l=France, o=xyz, c=us
   BaseDN_LyonNAS= l=Lyon, l=France, o=xyz, c=us
   BaseDN_ToulouseNAS= l=Toulouse, l=France, o=xyz, c=us
   FILTER=(&(Objectclass=remoteUser)(uid=$UserID))

   When the RADIUS server receives a request from ParisNAS, it checks that the remote user belongs to the naming context l=Paris, l=France, o=XYZ, c=US.

Combining Temporary Access and NAS Restriction

You can combine temporary access permission and restrict access to a particular NAS by combining the TMP_ prefix and _nasname suffix on the BaseDN or the FILTER tokens.

For example, if you want to grant Felipe Gonzalez from Madrid remote access to the Paris NAS just for the duration of a business trip to Paris, you would modify the radius.mapping file to include the following lines in the Dynamic section of the USERS table:

BaseDN= l=France, o=xyz, c=us
TMP_BaseDN= l=Madrid, o=xyz, c=us
FILTER=(&(Objectclass=remoteUser)(uid=$UserID))
TMP_Filter_ParisNAS=(&(Objectclass=remoteUser)(uid=$UserID)(uid=fgonzalez))

In this example, the _nasname suffix is added to the temporary filter rather than to the temporary base DN. The reason is that you may want to grant other people from the Madrid office access through a different NAS from the Paris NAS. In this case, the temporary base DN remains valid, you just need to create the temporary filter with the appropriate _nasname suffix.

Managing Virtual Domains

You can manage remote user connections from users who belong to a virtual domain, that is, a domain that you manage on behalf of another organization.

For example, if ABC corporation decided to use ISP corporation to manage their internet mail service, ABC would be assigned a domain name such as abc.com, and a pool of IP addresses. ISP corporation manages user information, and remote user connections for ABC corporation. When an employee from ABC corporation connects to request remote access, the connection parameters are the user login and the user password.

For example, John Smith logs in with the following parameters:

• Login: jsmith@abc.com

• Password: secret

The RADIUS server of ISP corporation needs to separate the user ID from the domain information. The beginning of the USERS table and the variables defined in the Dynamic section are shown below:

Table: USERS
	Common:
		BaseDN= o=isp, c=us
	Dynamic
		userID=>$myID@$virtualDomainT || $myID
		FILTER=(&(Objectclass=remoteUser)(uid=$myID))

In this configuration example, the username variable accepts two alternative expressions so that it can handle equally well remote users who have a domain name appended to their user ID, and those who do not.

The domain name must be checked during the authentication procedure, therefore the directory entry of John Smith includes these attributes:

• uid: jsmith

• userPassword: * (protected)

• authSuffixName: @abc.com

• grpCheckInfo: userPassword, authSuffixName

Processing Order for RADIUS Search Parameters

During a search, the RADIUS server handles the BaseDN and FILTER tokens in the following manner: it first performs an ordinary search, then, if this search fails, it performs a search on temporary tokens.

The ordinary search starts from the most restrictive to the most general:

• FILTER_nasname

• FILTER

• BaseDN_nasname

• BaseDN

If the ordinary search fails, the temporary search is handled in the same way:

• TMP_FILTER_nasname

• TMP_FILTER

• TMP_BaseDN_nasname

• TMP_BaseDN

Specifying a Dictionary File

The RADIUS server uses a dictionary file to analyze the parameters passed in the request from the NAS. The dictionary file contains RADIUS attribute and value pairs. A number of these attributes are defined in RFC 2138 Remote Authentication Dial In User Service, and RFC 2139 RADIUS Accounting. However, NAS vendors have also defined proprietary attributes.

Do not confuse the RADIUS dictionary file with the RADIUS mapping file which provides a translation between RADIUS attributes and LDAP attributes. For information on the RADIUS mapping file, refer to "RADIUS-to-LDAP Mapping".

Sun Directory Services is provided with a default dictionary that contains the standard attribute and value definitions. It also accepts the dictionaries from the following vendors:

• Livingston

• Ascend

• Cisco

• Shiva

• Bay Networks

The dictionary files provided by vendors contain both standard and proprietary definitions. Attribute and value definitions are identified by an OID which is the actual information passed in a RADIUS transaction. Due to a lack of standardization some proprietary attributes defined by different vendors use the same OID.

The RADIUS server can support any number of dictionary files from different vendors, but you must specify which dictionary to use with a particular NAS.

To Specify a Dictionary File for a NAS

Use the Deja tool to add the dictionaryFile attribute to the directory entry for the NAS.

The value you assign to this attribute must be the filename of the dictionary that the RADIUS server must use for communications with the NAS described by the entry.

If the dictionaryFile attribute is not specified, the default dictionary file is used. This file is located with all other configuration files under /etc/opt/SUNWconn/ldap/current.

If you use the dictionary provided by the NAS vendor instead of the default dictionary provided with Sun Directory Services, you must copy the attributes used internally by the RADIUS server from the default dictionary to the vendor-supplied dictionary. The list of attributes that you must copy is shown in Table 7-1.

#	Non-Protocol Attributes
#	These attributes are used internally by the server
#
ATTRIBUTE	Expiration	21	date
ATTRIBUTE	Auth-Type	1000	integer
ATTRIBUTE	Menu	1001	string
ATTRIBUTE	Termination-Menu	1002	string
ATTRIBUTE	Prefix	1003	string
ATTRIBUTE	Suffix	1004	string
ATTRIBUTE	Group	1005	string
ATTRIBUTE	Crypt-Password	1006	string
ATTRIBUTE	Connect-Rate	1007	integer
#
#     New SUN-DS Attributes for LDAP Integration
#
ATTRIBUTE	Login-Profile 	2000 	integer
ATTRIBUTE	Login-Passwd 	2001 	string
ATTRIBUTE	Login-Expiration 	2002 	date
ATTRIBUTE	PPP-Profile 	2010 	integer
ATTRIBUTE	PPP-Passwd 	2011 	string
ATTRIBUTE	PPP-Expiration 	2012 	date
ATTRIBUTE	SLIP-Profile 	2020 	integer
ATTRIBUTE	SLIP-Passwd 	2021 	string
ATTRIBUTE	SLIP-Expiration 	2022 	date
ATTRIBUTE	Auth-Failed-Access 	2100 	integer
ATTRIBUTE	Dynamic-Address-Profile	2200	integer
ATTRIBUTE	Dynamic-Session-Counter	2201	integer
ATTRIBUTE	Dynamic-SessionId	2202	string
ATTRIBUTE	Dynamic-IPAddress	2203	ipaddr
ATTRIBUTE	Dynamic-IPAddr-Binding	2204	string

Configuring Dynamic Accounting

You can use the RADIUS server to record connection parameters dynamically in the directory entry of a remote user. To enable dynamic accounting, in the RADIUS section of the Admin Console, set the Dynamic Data option to On.

The parameters recorded are dynamicIPaddress, dynamicSessionId, dynamicSessionCounter, dynamicIPaddressBinding, and all RADIUS attributes listed in the acctattr file. You must make sure that the NAS can provide the accounting parameters listed in the acctattr file. This file is located with other configuration files in /etc/opt/SUNWconn/ldap/current.

The dynamic accounting parameters listed in the acctattr file are RADIUS attributes that could be part of RADIUS accounting packets. The corresponding LDAP attributes are shown in Table 7-2. The default acctattr file contains examples of suitable RADIUS attributes commented out, except for User-Name. These are:

• Framed-IP-Address

• User-Name

• Acct-Session-Id

• NAS-Port

• NAS-Port-Type

• NAS-IP-Address

If you want to add accounting items to the list, check the following:

• At least one NAS can provide these items in an accounting packet

• There is an LDAP attribute for each RADIUS parameter that you want to record. If there is not, you must create the corresponding LDAP attribute. You must also create an entry in the mapping file to define the mapping between the RADIUS attribute and the LDAP attribute.

To Create a Dynamic Accounting Attribute

1. Create an LDAP attribute for the connection parameter that you want to record.

   This modifies the schema. See "To Create a New Attribute".

2. Add the attribute to the list in the radius.mapping file using a text editor.

   Make sure you add it in both the Import section and the Export section of the file. You need to be logged in as root to perform this operation.

3. Add the attribute to the list in the acctattr file using a text editor.

   You need to be logged in as root.

4. Restart the dsservd daemon so that the new accounting attribute is logged in the log file and recorded dynamically in remote user entries.

5. Restart the dsradiusd daemon so that the new mapping file is taken into account.

To Specify an acctattr File for a NAS

Use the Deja tool to add the acctattrFile attribute to the directory entry for the NAS.

The value you assign to this attribute must be the filename of the dynamic accounting attribute file that the RADIUS server must use to interpret the dynamic accounting information received from the NAS described by the entry.

If the acctattrFile attribute is not specified, the default acctattr file is used. This file is located with all other configuration files under /etc/opt/SUNWconn/ldap/current.

ACLs on RADIUS Information

RADIUS information in the LDAP directory is protected by a special set of ACLs. These are part of the dsserv.acl.conf file. The extract from this file is shown below.

# Radius ACLs
access to
attrs=chapPassword,radiusLoginPasswd,radiusPppPasswD,radiusSlipP
asswd
	by self write
	by * compare

access to attrs=sharedKey
	by self write
	by * compare

By default, users have write permission on the password and security attributes in their own entry, and read permission on all other attributes. All other users have compare permission on password and security attributes, and read permission on all other attributes.

RADIUS-to-LDAP Mapping

The RADIUS attributes and values defined in all of the dictionary files provided with the Sun Directory Services are mapped onto LDAP attributes. This mapping is defined in /etc/opt/SUNWconn/ldap/current/mapping/radius.mapping.

There is a one-to-one correlation between RADIUS attributes and LDAP attributes, therefore, the mapping syntax is very simple. You can easily add proprietary RADIUS attributes to the default mapping provided with Sun Directory Services.

The radius.mapping file is used by the RADIUS server to perform searches in the LDAP directory.

Default Mapping

Table 7-2 shows the one-to-one correspondence between RADIUS attributes and LDAP attributes. The table also indicates the origin of each RADIUS attribute. There are several kinds of RADIUS attributes:

• Standard attributes

• Vendor-specific attributes

• Sun Directory Services attributes

Standard RADIUS attributes are specified in RFC 2138 Remote Authentication Dial In User Service and RFC 2138 Remote Authentication Dial In User Service. Vendor-specific attributes are defined by NAS vendors and supplied in the dictionary file they provide with the equipment.

The LDAP attributes for the RADIUS service are specified in the schema attribute file dsserv.at.conf, under the section heading "Sun RADIUS Attributes". They are also listed in the schema object class file dsserv.oc.conf, under the comment line "Object classes for RADIUS".

The Sun Directory Services attributes are described in "Attribute Reference". They represent RADIUS user profiles, and dynamic accounting parameters.

Extending the Default Mapping

You can change the default mapping provided in radius.mapping to suit your own needs. If you want to add RADIUS attributes that are part of the dictionary file for your NAS to the default mapping, you must create an LDAP attribute for each RADIUS attribute missing in the radius.mapping file. You must then add the RADIUS-LDAP attribute pair to the radius.mapping file.

Creating RADIUS-LDAP Mapping Definitions

1. Create an LDAP attribute for the RADIUS attribute you require.

   This modifies the schema. See "To Create a New Attribute".

2. Add the attribute to the list in the radius.mapping file using a text editor.

   Make sure you add it in both the Import section and the Export section of the file. You need to be logged in as root to perform this operation.

3. Restart the dsservd daemon so that the modifications to the schema are taken into account, and the dsradiusd daemon so that the new mapping file is taken into account.

4. Run dejasync. As root type:

   # /opt/SUNWconn/ldap/sbin/dejasync

   For details on the options of the dejasync(1m) command, refer to the man page. You must run dejasync if you want to use the Deja tool to modify RADIUS entries in the directory.