We use a distributed RADIUS implementation within our DiaLinx private IP
network. It works like this:
1. The end user dials into his/her local POP, requesting access to the
network via their PPP/SLIP dialer script.
2. The NAS (Network Access Server) at the POP receives the request and
initiates a dialog with BBN's Central RADIUS using a shared secret which
will encrypt the authentication request.
3. BBN's Central RADIUS server receives the request and examines the realm
or domain name in the login.
4. Based on the realm or domain name, BBN's Central Radius Server initiates
a dialog with the Customer's Radius Server using the shared secret known
only to both servers, which will encrypt the authentication request.
5. The Customer's RADIUS Server examines the user login and password and
sends an "Access allowed"(ACK) or "Access Reject"(NAK) message to BBN's
Central RADIUS..
6. BBN's Central RADIUS Server forwards the ACK or NAK message to the NAS.
7. If Access is granted, the NAS allows the user to log on to the Network.
8. If Access is denied, the user is disconnected.
How the customer sets up their RADIUS SERVER:
The user file is an ASCII text file listing user login IDs and passwords.
The format is:
userlogin (tab) password
framed user=PPP
The user login includes
user name@realm(or domain).com
The user login must not exceed thirty-two(32) bytes in length and the first
bit must be a character. The realm can be an actual Internic-registered
domain name or a group defined by the customer and verified by BBN. An
example of a generic realm is kate@technogeeks.com.
The Client file contains information about the server that will send
authentication requests. The format is:
NAS ID: Central Radius
Primary and Secondary IP address of BBN's Central RADIUS servers
Shared Secret (known only to BBN Central RADIUS server and the customer's
RADIUS server)
And that's it.
=============
Now as I interpreted the original request for information, I assumed the
request came from an IPASS customer. In the distributed security model,
like how we do it - the customer is responsible for maintaining their own
users database. For the Clients file - instead of inserting information in
regards to an actual NAS like an Ascend, Livingston, Cisco, whatever - they
instead put the IP address of the IPASS Radius server and the shared secret
(password). RadiusNT, on the customer side, handles this just fine. It
will exchange information with IPASS Radius and back to us.
Now for using RadiusNT as the distributed central server - no, it can't
handle proxies. We use a merit version. Because merit's is still available
in source code - one can "redesign" the implementation for specific
functions - like examining the realm name and forwarding to the Radius
server of that realm for actual authentication of that particular end user,
et all. Plus it runs on UNIX (which is my own personal favorite) - but am
growing to appreciate NT :')
For the end user - other than changing the phone number of where they are
dialing - nothing changes - whether they dial directly into their home-based
ISP - or on the road in a different region or even different country.
So from our prospective - we have not seen many basic problems with IPASS
or other customers who use RadiusNT for maintaining their users databases.
Regards,
Kate