readme.lucent

This program is a RADIUS RFC-compliant daemon, which is derived from original Livingston Enterprise

$Id: README.LUCENT,v 1.1 2002/01/19 16:38:56 kiavik Exp $

1999/6/23

		RADIUS Server 2.1 Release Note

 
The Lucent Remote Access 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.

IBM RS6000 AIX 4.2
Alpha Digital UNIX 4.0
BSD/OS 3.0
HP-UX 10.20
Slackware Linux 2.0
Redhat Linux 5.2
SGI IRIX 6.3
SunOS 4.1.4
Solaris 2.5.1
Solaris x86 2.5.1

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 Remote Access 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 Features
	Y2K compliant
	Proxy RADIUS
	ActivCard
	iPass Support
	Accounting Signatures Now Required
	Vendor-Specific Attributes
	Virtual Ports
	Alternate Password File
	Address Binding
	Improved Messages
	Enhanced Debugging
Bugs Fixed
RADIUS test program radtest
How Proxy RADIUS Works and How to Configure It
Upgrading
Support

_______________ RADIUS Server Features

RADIUS server 2.1 supports the following features:


	Y2K Compliance

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

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.


	ActivCard

RADIUS server 2.1 now supports ActivCard as well as SecurID for
authentication. Do the following to authenticate a user with ActivCard:
 
1. Install the new ActivCard server on the same host as the RADIUS
   server or another host.
2. Create the /etc/raddb/config.aeg file on your RADIUS server host
   describing the parameters used to connect to the ActivCard server.
3. Use "Auth-Type = ActivCard" as a check item for the user.


	iPass Support

RADIUS server 2.1 now supports the iPass protocol. Do the following
to use iPass:

1. Register at the iPass website http://www.ipass.com/.
2. Add the "ipass" keyword to the appropriate entries in your
   /etc/raddb/proxy file.
3. Run the iradiusd binary instead of radiusd.

Direct any problems with the iPass support to iPass technical support
first; iPass will contact Lucent Remote Access, if necessary.


	Accounting Signatures Now Required

Earlier releases of the Lucent Remote Access RADIUS server logged
RADIUS accounting packets even if their request authenticators were
invalid. This behavior provided backwards compatibility with ComOS 3.3
and earlier releases. RADIUS server 2.1 now discards invalid accounting
packets and logs an error message. 

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.


	Vendor-Specific Attributes

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.


	Virtual Ports

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.


	Alternate Password File

You can use the -f flag with radiusd to specify an alternative to the
password file /etc/passwd.


	Address Binding

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.


	Improved Messages

* 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.


	Enhanced Debugging

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:

* x is the number of data structures allocated but not yet freed.
* y is the high-water mark (the most structures ever allocated but not
    freed at one time).
* z is the total number of structures allocated.


_______________ 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 radtest


RADIUS 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 -v prints the version.
radtest -h prints help:
 
./radtest -d called_id -f -g calling_id -h -i id -p port -s secret
	-t type -v -x -u username password
 
The other flags work as follows: 
-d Called Station Id
-f Send framed dialin hint 
-g Calling Station Id 
-i Use id as the packet identifier
-p Use port as the port (defaults to definition in /etc/services, or 1645)
-s to specify shared secret (defaults to "localkey")
-t send type as service type (overrides -f)
-u Specifies username and password (notice that this takes two arguments)
-x debug option (doesn't do anything currently)


_______________ How Proxy RADIUS Works and How to Configure It

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 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." 

	
	Realms

A realm can be either of the following: 

* The part following the "at" sign (@) in a username (a "named realm")
* A Called-Station-Id (a "numbered 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 Remote Access 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.


	Accounting Information

RADIUS accounting-request packets are logged by both the forwarding
server and remote server, but are acknowledged to the NAS only when the
remote server sends an accounting-response back to the forwarding server.

NOTE!  The remote server places the accounting information in a
directory under /usr/adm/radacct named after the forwarding server, NOT