test

Sun Directory Services 3.1 Administration Guide

Configuring the RADIUS Server

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

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.

Note -

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:

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:

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:

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:

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

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:

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.

Note -

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.

Table 7-1 RADIUS Server Internal Attributes 

#	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:

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

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.