1999/6/23RADIUS Server 2.1 Release NoteThe Lucent InterNetworking Systems RADIUS server 2.1 with support for RADIUS proxy, iPass roaming, and ActivCard is now available in binary form for the following platforms, and in source form.
NOTE! This release removes the obsolete RADPASS feature. In addition, User-Name values with embedded "at" signs (@) are now treated as proxy realms. RADIUS server 2.1 includes a new dictionary file with support for the Class, LE-Advice-of-Charge, and LE-Terminate-Detail attributes added in ComOS(R) 3.8. Attributes added in ComOS 3.9 and 4.1 are also included. The sradiusd daemon provides support for ActivCard on platforms supported by ActivEngine 2.1: AIX, HP-UX, SunOS, and Solaris. All other files are the same as in RADIUS server 2.0.1. Support is available only for customers owning Lucent PortMaster products. Information on contacting Lucent InterNetworking Systems technical support is listed at the end of this release note. The radiusd daemon uses GDBM 1.7.3 instead of NDBM on some systems; the source for GDBM is available for free from ftp://ftp.gnu.org/pub/gnu/gdbm/ and other Free Software Foundation (FSF) distribution sites.
Contents
RADIUS SERVER FEATURESRADIUS server 2.1 supports the following features: RADIUS server 2.1 is Y2K compliant. It treats all dates internally as 32-bit unsigned integers or time_t, and prints years in 4-digit format (for example, 1999). You must ensure that the operating system you are running the RADIUS server on is also Y2K compliant. All PortMaster products are Y2K compliant because they do not track the year. Proxy RADIUS is a feature in which one RADIUS server can forward an authentication request to a remote RADIUS server, and return its reply to the network access server (NAS). A common use for proxy RADIUS is roaming. Roaming permits two or more ISPs to allow each other's users to dial in to either ISP's network for service.For more information on proxy RADIUS, see "How Proxy RADIUS Works and How to Configure It" later in this release note. RADIUS server 2.1 now supports ActivCard as well as SecurID for authentication. Do the following to authenticate a user with ActivCard:
CAUTION! If you have any PortMaster running ComOS 3.3 or earlier, you must upgrade it to ComOS release 3.3.1 or later to use RADIUS server 2.1. The -o flag is provided for backwards compatibility with noncompliant RADIUS clients. If radiusd is run with the -o flag, it logs unsigned accounting records, and flags them with "Request-Authenticator = None". If radiusd is run without the -o flag, it does not log unsigned accounting records. RADIUS server 2.1 supports vendor-specific attributes in accounting-request packets to support the LE-Advice-of-Charge and LE-Terminate-Detail attributes added in ComOS 3.8. ComOS releases are available at http://www.livingston.com/forms/one-click-dnload.cgi and via FTP at ftp://ftp.livingston.com/pub/le/upgrades/.The dictionary file uses the following syntax to define vendor-specific attributes that follow the suggested format in RFC 2138: # # Vendor-Specific attributes use the SMI Network Management Private # Enterprise Code from the "Assigned Numbers" RFC. # VENDOR Livingston 307 # Livingston Vendor-Specific Attributes (requires ComOS 3.8 and RADIUS 2.1) ATTRIBUTE LE-Terminate-Detail 2 string Livingston ATTRIBUTE LE-Advice-of-Charge 3 string Livingston LE-Terminate-Detail is a string, included in RADIUS Accounting Stop records generated by ComOS 3.8, that contains a detailed description of the reason for session termination. LE-Advice-of-Charge is a string containing the Advice of Charge information (if any) provided on the ISDN D channel by the telephone company. If the file /etc/raddb/vports exists, it restricts the number of logins to each telephone number listed in the file. The first column of the file contains the Called-Station-Id, and the second column contains the number of logins permitted into that telephone number.This "virtual ports" feature provides only an approximate access control. Logins occurring before radiusd starts running are not considered in the count, nor are accounting records that go to the backup accounting server. To use this feature you must run radiusd with the -s (single-threaded) flag, and your must run the authentication and accounting servers on the same host. This feature does not provide simultaneous login limits for users. It is based on Called-Station-Id, not Calling-Station-Id. You can use the -f flag with radiusd to specify an alternative to the password file /etc/passwd. The -i <Address> flag to radiusd instructs the RADIUS server to bind to the specified IP address to listen for requests, instead of binding to any address. This address binding is useful for running radiusd on multihomed hosts. * The Calling-Station-Id, where known, is now included in the syslog message for many kinds of rejected access-requests, to help you identify where failed login attempts are dialing from. Currently, this value is logged to syslog for unknown users and for failed "Auth-Type = System" logins. For example:Jul 10 21:10:50 ra radius[14870]: unix_pass: password for "bob" at 5551234 failed The actual syslog message appears on one line, but is broken into two lines here for legibility. * Other log messages are now more detailed. For example: Jul 10 21:10:50 ra radius[14870]: forwarding request from 192.168.96.6/1093.139 to 172.16.3.24/1645.17 for edu.com The numbers after the slash are the UDP port (1645) and the RADIUS message ID (17) for easier tracking. The actual syslog message appears on one line, but is broken into two lines here for legibility. Sending a SIGUSR1 signal to radiusd now turns on debugging, and sending SIGUSR2 turns off debugging. Either signal, or exiting radiusd, logs a short summary of the daemon's activity. The format is subject to change, but for this release the summary looks like the following examples. The actual syslog message appears on one line, but is broken into two lines here for legibility.Example 1 Mar 19 23:10:50 ra radius[14870]: counters 5 8 / 2 4 / accept 4 reject 1 challenge 0 response 8 In this example, five packets were received on the RADIUS port (usually 1645 unless changed with the -p flag), eight packets were received on the RADIUS accounting port. Two RADIUS proxy replies were received, and four RADIUS accounting proxy replies were received. The RADIUS server sent four access-accepts, one access-reject, no access-challenges, and eight accounting responses. Example 2 Jul 28 09:56:01 ra radius[19340]: memory usage = pair 8/35/4784 peer 0/0/0 req 1/4/570 buf 1/4/570 This memory usage summary displays allocations for each of the four major data structures used by radiusd, in the format x/y/z:
Bugs Fixed* A misconfigured user entry that has a check item of Auth-Type = Local with no Password check item now rejects the user with the debug message "Warning: entry for user <name> is missing its Password check item". * An unknown Auth-Type check item now generates an error message and rejects the user. * A memory leak that resulted from the use of multiple DEFAULT user entries is fixed. * The password decryption code no longer calculates the next RSA Data Security, Inc. MD5 Message-Digest Algorithm (MD5) digest when it does not need to. * The radiusd daemon is now strictly compliant with RFC 2139 and discards accounting-request packets with invalid request authenticators. As a result, you must run ComOS 3.3.1 or later to use RADIUS accounting with RADIUS server 2.1. The -o flag is provided for backwards compatibility with noncompliant RADIUS clients. * Assorted memory leaks and pointer problems have been corrected. RADIUS test program radtestRADIUS 2.1 includes a simple example client program called radtest, that sends a RADIUS packet to a server running on the same host as radtest, and prints out the attributes returned. It doesn't support accounting packets yet. It always fills in the NAS-IP-Address as 127.0.0.1 and the NAS-Port as 1. Passwords longer than 16 characters are not supported. It looks for its dictionary in the same directory it is run from.
./radtest -d called_id -f -g calling_id -h -i id -p port -s secret -t type -v -x -u username password
How Proxy RADIUS Works and How to Configure ItProxy RADIUS is a feature in which one RADIUS server can forward an authentication request to a remote RADIUS server, and return its reply to the NAS. A common use for proxy RADIUS is "roaming." Roaming permits two or more ISPs to allow each other's users to dial in to either ISP's network for service. The "network access server (NAS)" (PortMaster) sends its RADIUS access-request to the "forwarding server," which forwards it to the "remote server." The remote server sends an access-accept, access-reject, or access-challenge resonse back to the forwarding server, which sends it back to the NAS. The choice of which server to forward the request to is based on the authentication "realm."
The forwarding server checks for a numbered realm before checking for a named realm. Frequently, a domain name is used as the named realm to provide uniqueness. The RADIUS server 2.1 radiusd daemon also supports the "realm/user" style of username, but Lucent InterNetworking Systems recommends that you avoid this username style. Support is provided for older RADIUS servers that require it. However, because the "at" sign (@) always takes precedence over the slash (/), radiusd interprets the username "a/b@c" as user "a/b" in the named realm "c", for example. Such mixtures are strongly discouraged and might not be supported in future releases.
NOTE! The remote server places the accounting information in a directory under /usr/adm/radacct named after the forwarding server, NOT the NAS.
Any other vendor's conforming RADIUS proxy server is likely to work as either the forwarding server or remote server if that vendor has implemented proxy correctly. Lucent InterNetworking Systems RADIUS server versions 2.0.1 and earlier do not support proxy RADIUS, but can still be used as a remote server through the use of the "old" flag in the proxy file on the forwarding server.
For example, if you run "radiusd -p 1812", then radiusd uses UDP ports 1812, 1813, 1817 and 1818.
To use proxy, you set up RADIUS as you do normally. In addition, to form the communication between the forwarding and remote servers, you must define the following information in the clients and proxy files in /etc/raddb: On the forwarding server:
radius.edu.net secretupto16char edu.net s134.net.com someothersec2ret 5551134 net54.edu.net bettersecretthan 5555454 rad.edu.com chsebetterth edu.com 1645 rad7.com.net lx4zDFapa3ep com.net 1645 1646 old radius.edu.net eajsdfljasep 5551234 1812 1813 secure eg.edu.net e997asepdflj edu.net old secure
old Strips the realm from the username and does not attach
Proxy-State when forwarding. This keyword is useful for
forwarding requests to older RADIUS servers.
secure Allows the remote server to authorize administrative
logins for your client. If this keyword is not present,
access-accepts from the forwarding server that
grant Administrative or NAS-Prompt access are treated
as access-rejects instead. If you use this keyword,
you are allowing the remote server to let someone log
in to your NAS as an administrator, so use it with
caution!
ipass Uses the iPass protocol (instead of RADIUS) to
communicate with the remote server. See
http:/www.ipass.com/ for more information.
The optional fields can be specified in any order, separated by blanks or tabs, after the first three mandatory fields. If you specify a single UDP port, it is used for the RADIUS port. If you specify two ports, they are used as the RADIUS port and RADIUS accounting port in that order. If you specify no ports, they default to the same ports used by the RADIUS server itself. If "secure" is not specified for a remote server and it replies with Service-Type = Administrative-User or NAS-Prompt-User, the forwarding server treats it as an access-reject and logs the following message to syslog: Jul 10 21:10:00 ra radius[14870]: remote server 192.168.96.6/1645.4 returned insecure service for client 172.16.3.24/1039.17, sending reject instead If the hostname (or IP address) listed in the proxy file is the same as the primary hostname or IP address of the host running the RADIUS server, and the UDP port in the entry matches the UDP port the message was received on, radiusd determines that the user is local, strips off the "@domain" portion, and processes the request locally.
center.com.net e199aespfdx4 DEFAULT The special named realm "NOREALM" (all uppercase) matches any user that has no realm. If more than one NOREALM entry exists in the proxy file, only the last one is used. For example: others.com.net e19aepsfd9x4 NOREALM
Equipment:
In a real configuration, you must use IP addresses or fully qualified domain names as hostnames.
1. Configure the contents of clients and proxy files of the server
called "forward" as follows:
/etc/raddb/clients
------------------
pmtest sharedsecret
/etc/raddb/proxy
----------------
remote testsecret com.net
2. Configure the contents of clients and proxy files of the server
called "remote" as follows:
/etc/raddb/clients
------------------
forward testsecret
/etc/raddb/proxy
----------------
remote doesntmatter com.net
3. On the PortMaster "pmtest", enter the following commands to set the
authentication and accounting servers:
set authentic 192.168.10.2
set secret sharedsecret
set accounting 192.168.10.2
save all
4. For a user to be authenticated via the remote server, define a
profile for this user in the users file of the remote server. A user
profile is defined in the following format. Note that the remote
server strips the named realm from the username before looking it up in
the users file.
test Password = "testing"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Framed-Routing = None
Alternatively, if the test user's password is stored in the /etc/passwd
file, the example user profile is the following:
test Auth-Type = System
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Framed-Routing = None
5. Run the radiusd daemon on both "forward" and "remote" servers.
The RADIUS accounting records are logged in the detail file of each
server.
A user dialing in to the PortMaster must enter "test@com.net"
at the login prompt and a password at the password prompt.
This limitation is a problem only if your situation includes ALL of the following:
UpgradingRADIUS server 2.1 is available in source form at ftp://ftp.livingston.com/pub/le/radius/radius21.tar.Z and in binary form for the following platforms at ftp://ftp.livingston.com/pub/le/software/: IBM RS6000 AIX 4.2 aix/radius21.tar.Z Alpha Digital UNIX 4.0 alpha/radius21.tar.Z BSD/OS 3.0 bsdi/radius21.tar.Z HP/UX 10.20 hp/radius21.tar.Z Slackware Linux 2.0 linux/radslack21.tar.Z Redhat Linux 5.2 linux/radhat21.tar.Z SGI IRIX 6.3 sgi/radius21.tar.Z SunOS 4.1.4 sun4/radsun21.tar.Z Solaris 2.5.1 sun4/radsol21.tar.Z Solaris x86 2.5.1 sun86/radius21.tar.Z For other flavors of UNIX, including Linux, FreeBSD, NetBSD, and BSD/OS 4.0, get the source and compile from that. RADIUS 2.1 is not available for Windows NT. To upgrade, do the following:
Copyright and TrademarksCopyright 1999 Lucent Technologies. All rights reserved. PortMaster, ComOS, and ChoiceNet are registered trademarks of Lucent Technologies Inc. PMVision, IRX, and PortAuthority are trademarks of Lucent Technologies Inc. PolicyFlow is a service mark of Lucent Technologies Inc. All other marks are the property of their respective owners.
Internet service providers (ISPs) and other end users in Europe, the Middle East, Africa, India, and Pakistan should contact their authorized Lucent InterNetworking Systems sales channel partner for technical support; see http://www.livingston.com/International/EMEA/distributors.html. For North and South America and Asia Pacific customers, technical support is available Monday through Friday from 7 a.m. to 5 p.m. U.S. Pacific Time (GMT -8). Dial 1-800-458-9966 within the United States (including Alaska and Hawaii), Canada, and the Caribbean and Latin America (CALA), or 1-925-737-2100 from elsewhere, for voice support. For email support send to support@livingston.com (asia-support@livingston.com for Asia Pacific customers). |