readme.lucent

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

the NAS.


	Required Versions of RADIUS

Both the forwarding server and remote server must be running this
release of the Lucent Remote Access RADIUS server, or a current version
of Lucent PortAuthority(tm).

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


	Port Numbers Used

This RADIUS server listens on UDP port 1645 for access-requests and on
UDP port 1646 for accounting-requests. It sends proxy requests from UDP
ports 1650 and 1651 and listens for proxy responses on those ports. If
the listening port is set with the -p flag to radiusd, then radiusd
does the following:

* Listens on the specified UDP port for access-requests
* Listens on the port numbered 1 higher for accounting-requests
* Uses ports numbered 5 higher and 6 higher to send proxy requests

For example, if you run "radiusd -p 1812", then radiusd uses UDP
ports 1812, 1813, 1817 and 1818.


	Versatility

The forwarding and remote RADIUS servers can run on different operating
systems. A RADIUS server can function as both a forwarding server and
a remote server, serving as a forwarding server for some realms and a
remote server for other realms. Use care to avoid forwarding loops --
a packet passed back and forth between two misconfigured forwarding
servers. One forwarding server can forward to any number of remote
servers (one per realm). A remote server can have any number of
servers forwarding to it and can provide authentication for any number
of realms.


	Proxy Scenario

The following scenario illustrates the communication between a
PortMaster and the forwarding and remote RADIUS servers:

1.  A PortMaster sends its access-request to the forwarding server.

2.  The forwarding server forwards the access-request to the remote server.

3.  The remote server sends an access-accept, access-reject, or
    access-challenge back to the forwarding server. For this example,
    an access-accept is sent.

4.  The forwarding server sends the access-accept to the PortMaster.

5.  The PortMaster sends an accounting-request to the forwarding server.

6.  The forwarding server logs the accounting-request and forwards it
    to the remote server.

7.  The remote server logs the accounting-request and sends an
    accounting-response to the forwarding server.

8.  The forwarding server sends the accounting-response to the
    PortMaster.

To set up proxy, create a proxy file in the /etc/raddb directory on the
forwarding server. If named realms are used, a proxy file must also
exist on the remote server. If only numbered realms are used, the
remote server does not need a proxy file.

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:

o The clients file must have an entry for the PortMaster hostname or 
  IP address and its shared secret.

o The proxy file must have an entry for the remote RADIUS server's
  hostname or IP address, its shared secret, and its realm. The shared
  secret in the forwarding server's proxy file must match the shared
  secret in the remote server's clients file.

On the remote server:

o The clients file must contain the forwarding server's hostname or
  IP address and its shared secret. The shared secret must
  match the shared secret in the forwarding server's proxy file.

o If any named realms are used, the proxy file must contain the
  hostname or IP address of the remote server itself, an unused shared
  secret, and the realm this remote server is authoritative for. If
  only numbered realms are used, then no proxy file needs to be defined
  on the remote server.


	Proxy File Example

The /etc/raddb/proxy file contains proxy server hostnames (or IP
addresses), shared secrets, and realms, all separated by spaces or
tabs.  Each line describes one realm.  Here is a proxy file example:

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

o The first field is a valid hostname or IP address.
o The second field (separated by blanks or tabs) is the shared secret.
o The third field is the named or numeric authentication realm.
o The remaining fields can be empty, or can contain the RADIUS port
  number of the remote server, the RADIUS accounting port number of the
  remote server, and any of the following optional keywords:

       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.


	Special Named Realms

The special named realm "DEFAULT" (all uppercase) matches any named
realm not found in the proxy file. If more than one DEFAULT entry
exists in the proxy file, only the last one is used. For example:

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


	Example Configuration for Proxy RADIUS

The following example illustrates a typical proxy RADIUS topology
and the sample configuration of proxy and clients files.

Equipment:
o PortMaster named "pmtest" with IP address 192.168.10.1
o Forwarding server named "forward" with an IP address of 192.168.10.2
o Remote server named "remote" with an IP address of 172.16.25.5

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 "[e-mail]"
at the login prompt and a password at the password prompt.


	Limitation of Proxy

For the RADIUS server to handle numbered realms for points of presence
(POPs) from multiple area codes, the RADIUS server must be configured with
the area code of each PortMaster if that information is not included in the
Called-Station-Id. The ability to determine the area code is not
included in RADIUS server 2.1.

This limitation is a problem only if your situation includes ALL of the
following:

* You use the same 7-digit telephone number in multiple area codes to
  belong to different realms. 
* You use the same RADIUS forwarding server for all area codes and/or all
  realms.
* Your telephone company does not include the area code in the
  Calling-Station-Id.


_______________ Upgrading

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

1. Save a copy of your old dictionary file and radiusd daemon.

2. Copy the new dictionary file to /etc/raddb or whatever directory you use.

3. If you are using proxy, create a /etc/raddb/proxy file.

4. Kill your existing radiusd, and run the new radiusd.

    - If you are using SecurID or ActivCard for authentication, 
      run sradiusd instead of radiusd.

    - If you are using iPass, run iradiusd instead of radiusd.

    - If you are running iPass AND SecurID or ActivCard, 
      modify the Makefile to link all the appropriate libraries.
      Contact [e-mail] if you need assistance in doing so.

_________________________________________________________________

	Copyright and Trademarks

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

	Notices

Lucent Technologies Inc. makes no representations or warranties with
respect to the contents or use of this publication, and specifically
disclaims any express or implied warranties of merchantability or
fitness for any particular purpose. Further, Lucent Technologies, Inc.
reserves the right to revise this publication and to make changes to
its content, any time, without obligation to notify any person or
entity of such revisions or changes.

	Contacting Lucent Remote Access Technical Support

Lucent Technologies Remote Access Business Unit (previously Livingston
Enterprises) provides technical support via voice, electronic mail, or
through the World Wide Web at http://www.livingston.com/.
Please include the output of radiusd -v and uname -a when reporting
problems with this release.

Internet service providers (ISPs) and other end users in Europe, the
Middle East, Africa, India, and Pakistan should contact their
authorized Lucent Remote Access 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 [e-mail]
([e-mail] for Asia Pacific customers).