Don't call it session limit - there is something else entirely that is
already called that (limits the session time) so it'll confuse the issue.
Concurrent login preventin is *not* possible to do cleanly in RADIUS alone -
period. The protocol does not handle it. There are some hacks that work
with varying degrees of success, but all have failure states. IEA's
RadiusNT, Merit RADIUS, and ESVA RADIUS all have similar ways to do it I
believe.
Livingston's next generation server, which is a few months out yet, does
it using an external SNMP check. This avoids the racew conditions inherent
in the RADIUS protocol that all other systems to date suffer from.
Here's a little rant I wrote on this a while back.
---cut---
RADIUS is NOT good at simultaneous user restrictions - at the protocol level.
ALL of the RADIUS servers that attempt it have major failure states. This
is unavoidable. RADIUS was *deliberately* designed to *not* be a resource
management protocol. It was designed explicitly to be good at authorization
and accounting.
Issues:
RADIUS auth does NOT have ack packets from the NAS, nor does it have ANY way
of knowing the user has logged out.
Only RADIUS accounting says that a user logged in or logged out on the NAS.
That means you have to weld both servers together, when the protocol was
designed not to need this.
And even then it isn't good enough. RADIUS accounting packets have a
completely different - lower - priority than auth on all the NASes I know of.
That means the notification that someone logged out may lag for several
*minutes*, possibly quite a few, as retries are not as agressive. Acct was
written to NOT be time sensitive - to get the info there, eventually.
So there is a VERY common state where a user logs off, or is dropped, turns
around to log back in - and RADIUS thinks they are still in! So it denies
them.
If you offer ISDN connections this is *easy* - ISDN can take less than a
second to connect. Even if we used auth packets, they can take up to 30
seconds to get through.
And what if the NAS hard crashes? There is no provision in RADIUS for
keep alives - and quite deliberately so. They are not needed for what the
protocol is designed to do. If the NAS crashes uses will be dumped, and the
server receives no notice of this. So ALL of them will be denied when they
dial into another NAS to reconnect.
And there are more issues. This is just with one server - try coordinating
multiple servers for fallback.
People don't seem to understand these issues, so they keep asking the
protocol to do things it was deliberately designed NOT to do.
ESVA RADIUS has simultaneous limits - and you can only run ONE server to
use it. Even then all of the above failure states can, and will, bite you.
Merit RADIUS is a more robust, yet still doesn't adress most of the issues.
RADIUSNT also has major failure states.
This has come up in the IETF WG several times and the basic agreement is
there needs to be another protocol to handle resource management - RADIUS is
not suited to it and should not be kludged to do it.
No one, as of yet, has seriously pursued forming another WG to address this.
---cut---
-MZ
-- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588