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 Dan Merillat shaped the electrons to say...
> >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.
> 
> This works for one case.
> 
> But what about those who wish to sell 4 login business accounts?  You can't
> just go nuke things.  We get a lot of requests for that kind of thing - 
> allowing 'X' numnber of logins, no more.

Oh sheesh... If the account is limited to 4 logins, nuke the first when
the fifth connects.  I thought that was obvious enough. ;-)

Probably should have added "Limiting people to X accounts left as an
excercise to the reader."  ;-)

> There is also, as you bring up, the multiple server case.

That's the hard part... Question, is RADIUS accounting guarenteed to get
there, eventually?  (As long as the NAS stays up, anyway.)

> Our nextgen RADIUS server handles these cases by:
> 1. Being backended by a distributed database.  Records are kept in the DB
> and can be accessed by multiple servers, and/or synced to multiple databases
> for full redundancy.

Thats the way to do it... one DB server on each RADIUS server.  Keeps it
synced well.

> 2. If an auth-req comes in, AND the account is at it's limit, the server
> makes an SNMP query to determine if the current logins are really there.
> ie, the NAS hasn't crashed, the stop record didn't get lost/delayed, etc.
> If they are still active, the new login is denied.  If not, the old record
> is closed and marked so you know it was closed by the server, and the new
> login is permitted.
> 
> >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)
> 
> Livingston's do send a 'happy birthday' packet as I like to call it when
> they reboot.

Heh. ;-)  Accounting and/or auth?

> >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.
> 
> It is being hit from different sides.  There are SNMP client and server
> MIBs for auth and accounting being worked on.  

Hmm... we still need a resource management protocol... for things like
bandwidth allocation with dial-to-frame ISDN, how many lines on a single
connection someone can have using analog MPP or MP+...

> But there is nothing standard for something like filter distribution.
> Livingston has ChoiceNet, but that's the only product of its kind I know
> of.  And it is only Livingston products.

Filter distibution would be nice to have in the standard... that way I
don't have to use the binary filters hack that ascend uses...

Of course, that would imply that filtering METHODS are the same, or at
least similar, so I can see the problem there.

Kevin: Is binary filters the only Ascend add-on to RADIUS?  (Well, that
and the dictionary)

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