Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) RADIUS - Blocking multiple logins by same user (fwd)
MegaZone writes:
> Once upon a time RG shaped the electrons to say...
> >If you are using 1 authentication server, you may consider
> >building a hash table that RADIUS will build upon authenticating,
> >and checks the table to see if the login exists. If so, it will
> >not proceed with the login.
>
> My standard rant on this:
> ---cut---
> RADIUS is NOT good at simultaneous user restrictions - at the protocol level.
<Snip completely correct reasons why RADIUS auth won't do it>
Hmm, yes, but there is a sneaky way around it....
Don't worry about multiple logins at the AUTH level... but, when the
second "start" packet comes in at the Accounting level, SNMP (or RADIUS)
nuke the _FIRST_ login.
Why?
Simple: This fixes most of the major failure modes.
First: the default case, someone is sharing an account
8:00 ACCT-Start "luser" session=12345
8:15 ACCT-Start "luser" session=54321
Now, RADIUS or SNMP kill session 12345... and log the attempt for Support
to call them back and harass them.
Next, another common problem: Loss of a Max/Livingston with people on it
8:00 ACCT-Start "joe" session=12345
8:10 Server dies
8:15 ACCT-Start "joe" session=54321
Now, you attempt to kill session 12345, but nobody is there anymore
(server rebooted, and session ID's are based on time (right?)
Result? log of a mess of people all multiply dialed in. You might even
tweak accounting to notice the max reboot based on something (I think some
packets go to acct on reboot, dunno though)
Either way, the automated half gets it right.
--- snip again ---
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.
--- snip ---
I dunno... I think doing it via the accounting works fairly well, for this
_SPECIFIC_ resource management. resource management is needed for other
things as well, so a good protocol is needed for that.
Note this is based on having _ONE_ accounting server. If you are going to
balance it out between 2 or more, you are going to need to add a TCP
syncronization channel between them... and only ACK to the NAS once you
have sent it out via the sync channel... otherwise you end up with very
inconsistant scenarios.
And, since the sync backchannel will have to be independently invented
by EVERYONE making a radius auth/acct server, it's obviously better to
have a standard on it. It should work a lot better then hacking it into
the auth half, anyway.
So, anyone want to tack this unto theirs? What, no vict^H^H^Holunteers?
;-)
MZ: did I miss any failure states? I'm working on our radius for other
reasons, and I'll probably put something like this in... But I can't
believe nobody has thought of this already, so I may have missed something
that'll throw this all off.
--Dan
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>