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.
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.
Without changing your basic configuration, you can allow temporary access to a remote user whose entry is in a different naming context.
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
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.
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.
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
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.
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.
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
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
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.
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 |
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.
Create an LDAP attribute for the connection parameter that you want to record.
This modifies the schema. See "To Create a New Attribute".
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.
Add the attribute to the list in the acctattr file using a text editor.
You need to be logged in as root.
Restart the dsservd daemon so that the new accounting attribute is logged in the log file and recorded dynamically in remote user entries.
Restart the dsradiusd daemon so that the new mapping file is taken into account.
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.
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.