RADIUS Protocol
Novell BorderManager 3.7 Authentication Services enables remote users to dial in to NetWareŽ networks (version 5.1 or later) and access network information and resources such as files, databases, applications, e-mail, printing, and host/mainframe services. It maintains security by requiring users to authenticate to the NDS® or Novell eDirectoryTM database using the Remote Authentication Dial-In User Service (RADIUS) network security protocol before they can access these services.
Dialing in as a user to a network that uses Novell BorderManager 3.7 Authentication Services is not much different from dialing in to any other dial-in service, except users use the same account to access NetWare file and print services. You can use any client software that works with your network access server. The Novell BorderManager 3.7 Authentication Services user must know the syntax of the username:
Service_Name: eDirectory_UserName@ Domain
In the simplest case, Service_Name and @Domain are not required, and eDirectory_UserName is the common name of the user's object in eDirectory. eDirectory_UserName can be entered in distinguished name form or in common name form if you have configured Novell BorderManager 3.7 Authentication Services to accept common name login. For example, if Joe is an employee in the Sales department at Acme, the common name form would be joe and the distinguished name form would be .joe.sales.acme.
If a user is using a dial-in service other than the default, the user must add the name of the service as a prefix to the username followed by a colon (for example, ppp:joe selects the Point-to-Point Protocol [PPP] service configured for user joe).
If a RADIUS proxy is used to authenticate from a remote RADIUS server, users must append an at sign (@) followed by the proxy domain to the username (for example, joe@acme.com).
Novell BorderManager 3.7 Authentication Services implements RADIUS as the network security protocol to authenticate users for dial-in remote access.
A host server running the RADIUS protocol (the RADIUS server) retrieves all dial-in user and authentication information from a central database. A host server running the RADIUS accounting protocol (the RADIUS accounting server) is responsible for logging information about dial-in user connections. The accounting information is typically used for statistical analysis, troubleshooting, and billing.
Dial-in users access the Internet or corporate intranet through network access servers, which handle communication between the users and RADIUS servers. A dial-in user must provide authentication information (typically a username and password). The network access server forwards the information to the RADIUS server using the RADIUS protocol. The RADIUS server authenticates the user by comparing the user request to the user information in the central database. The RADIUS server then returns configuration information necessary for the network access server to deliver the requested service to the dial-in user. A RADIUS server can also communicate with a RADIUS proxy server to authenticate remote users who are not in its local database.
This concept is illustrated in the following figure.
Figure 30
RADIUS Protocol
The RADIUS protocol is supported by many network access server vendors and is an Internet Engineering Task Force (IETF) Proposed Standard (RFC 2138). The RADIUS accounting protocol is also an IETF Proposed Standard (RFC 2139). The key features of the RADIUS protocol are
The RADIUS protocol provides a central database to store all dial-in user information. This database can be used by all RADIUS-compatible network access servers.
The Novell implementation provides separate log files for system messages and accounting information. You can enable or disable the logging of system messages or accounting information from the server console. Likewise, you can specify the number of days that the log files should be maintained.
Network access servers act as clients to RADIUS servers. The network access servers authenticate users through the RADIUS server when users dial in to the network.
RADIUS servers receive user connection requests, authenticate each user, and then return all configuration information necessary for the network access server to deliver the requested service to each user.
A RADIUS server can also act as a proxy client to other RADIUS servers.
Transactions between the network access server and the RADIUS server are protected through a shared RADIUS secret. This shared secret is never sent across the network.
In addition, user passwords are encrypted, making it difficult for outsiders to decipher them. Novell BorderManager 3.7 Authentication Services implements the following dial-in user account and password restrictions:
When logging in through RADIUS, users will be notified of expired passwords if the network access server and the dial-up client networking software supports the reply message attribute. However, most users will not be notified of remaining grace logins.
RADIUS servers support Point-to-Point Protocol (PPP), Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and other authentication mechanisms such as tokens.
Novell BorderManager 3.7 Authentication Services maintains these usernames and passwords in the eDirectory database. Novell BorderManager 3.7 Authentication Services supports NDs or eDirectory-based user passwords for User objects in an NDS or eDirectory tree.
The network access server configures a user's connection and access to the network according to information provided by the RADIUS server when the user is authenticated successfully. Using Novell BorderManager 3.7 Authentication Services, all users in an NDS or eDirectory container object can use the same configuration information or have unique dial-in configuration settings.
Novell BorderManager 3.7 Authentication Services enables you to use the NDS or eDirectory application as the central database to manage all your dial-in users and services. With the RADIUS server component running on a NetWare server (version 5.1 or later) or a Windows* NT* server (version 4.0 or later), you can centrally monitor and control dial-in authentication and access to network services from the NDS or eDirectory database. From the administration workstation component (running Windows NT), you can centrally manage dial access services for users with the NetWare Administrator utility. Novell BorderManager 3.7 Authentication Services also enables you to take advantage of all the security, distribution, replication, and administration benefits that NDS or eDirectory has to offer. Licensing for each RADIUS server and dial-in user is also administered using NDS or eDirectory.
This concept is shown in the following figure.
Figure 31
Novell BorderManager 3.7 Authentication Services Configuration
The RADIUS protocol defines attributes that are used to control dial-in access to the network and user configuration. When the Novell BorderManager 3.7 Authentication Services server receives a request to authenticate a user, it determines whether the user is authorized to dial in (user exists, account is enabled, dial access is enabled, password is correct, and so on). If the user is authorized, the Novell BorderManager 3.7 Authentication Services server constructs a list of attributes to return to the network access server to configure the user dial-in session.
The list of attributes returned depends on the following:
You can configure Novell BorderManager 3.7 Authentication Services to allow common name logins, as well as distinguished name logins. A common name is the name displayed in the NDS or eDirectory tree (such as RJONES for the user Richard Jones). A distinguished name is the complete path (or context) from the object to the root of the NDS or eDirectory tree (such as .RJONES.HQ.ACME.US).
You can configure common name logins by specifying a list of lookup contexts (locations of an object within the eDirectory tree) in the Dial Access System object. The RADIUS server searches in these locations for any user who logs in without using a distinguished name. This feature is most useful if each User object in your NDS or eDirectory tree has been assigned a unique common name. Users who have names that are not unique must enter their distinguished names when logging in.
Refer to the NetWare Administrator online help for information about specific configuration procedures.
When you create a Dial Access System object, you must specify the password policy. Novell BorderManager 3.7 Authentication Services supports the following options:
When this option is selected, the NetWare password used for file and print services is used to authenticate dial-in access. This means that users are not required to remember or change additional passwords.
Separate passwords are encrypted in eDirectory in such a way that only an authenticated RADIUS server can easily decrypt them. The Password Authentication Protocol (PAP) algorithm causes the password to be visible in clear text to the network access server and all RADIUS servers that process the authentication request (such as proxy RADIUS servers and the authenticating RADIUS server). You might not want your eDirectory password to appear as clear text in these systems if they are not administered by you.
Separate passwords are encrypted in eDirectory in such a way that only an authenticated RADIUS server can easily decrypt them. The Challenge Handshake Authentication Protocol (CHAP) algorithm requires the RADIUS server to have access to the clear-text password. NDS or eDirectory passwords are not available in clear text, so they cannot be used in conjunction with CHAP.
The Authentication Constainer object contains tokens or smart cards from a single vendor. The Authentication Container object manages the common configuation tasks for these objects.
A user-assigned device is an Authentication Device object that contains information about a single token or other device. An Authentication Device object is created when you import or initialize a token.
The RADIUS accounting server is responsible for logging information about dial-in user connections. The accounting information is typically used for statistical analysis, troubleshooting, and billing.
The RADIUS accounting server is typically implemented as a separate process of the RADIUS authentication server. The RADIUS accounting server listens on User Data Protocol (UDP) port number 1813. When an accounting packet is received from a RADIUS client (such as a network access server), the RADIUS accounting server logs the information in an ASCII text file and returns an acknowledgment to the RADIUS client.
When a user session begins, an accounting request packet containing connection information about a dial-in user (such as the type of service being delivered) is generated by a RADIUS client (such as a network access server) and sent to the RADIUS accounting server to be logged. When a user session ends, another accounting request packet containing the type of service delivered and any optional statistics is generated and sent to the RADIUS accounting server.
The RADIUS audit log is a disk file that contains the system messages that are displayed in the RADIUS status display console. The RADIUS audit log is typically used for troubleshooting.
The RADIUS audit log file contains the same messages that are displayed on the status display (successes or failures). The status display is not required to be open in order for messages to be logged to the system log file.
The naming of the audit log file takes the form
YYYYMMDD.LOG
where YYYY represents the year, MM represents the month, and DD represents the day (for example, 19981120.LOG for an audit log file created on November 20, 1998). This convention keeps log files to a manageable size and enables you to group system log information by month, week, or day.
By default, Novell BorderManager 3.7 Authentication Services starts with the RADIUS audit log file enabled. The default location for the RADIUS audit log file is as follows: