Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) How to reject multiple logins from RADIUS?

> Yes the GNU version of Cistron RADIUS server does this with no problem. It uses
> SNMP to keep accurate count of who is logged in where and how many times.
> 
> http://homepage.cistron.nl/~miquels/radius/
> 
> Hope this helps you out.

Unfortunately, my question stands.

Whether you use SNMP or RADIUS accounting or anything else to actually
remember who's logged in where, you still have to use that information
coupled with the information presented in a RADIUS authentication request
packet to decide whether to allow a login, and the required information
just doesn't seem to be there.

(Of course you can "notice" an active login that shouldn't have been
allowed after the fact and kill it, but that's "correcting an error",
not enforcing correct behavior in the first place -- quite a kludge)

-Phil

> -----Original Message-----
> From: Phillip Vandry <vandry@mlink.net>
> To: ascend-users@bungi.com <ascend-users@bungi.com>
> Cc: pascal@mlink.net <pascal@mlink.net>
> Date: Saturday, October 17, 1998 3:45 PM
> Subject: (ASCEND) How to reject multiple logins from RADIUS?
> 
> 
> >As we know, the Shared Prof parameter can be used to tell a Max to
> >reject a new session if there's already one with the same username.
> >
> >But that only works within a Max.
> >
> >I can't figure out how a RADIUS server might to the same thing (so that
> >it can work across multiple NASes). I looked at the contents of an
> >Authentication request packet coming from a Max, and it contains the
> >following attributes:
> >
> >User-Name, Password, NAS-Port, NAS-Port-Type, User-Service,
> >Framed-Protocol, Acct-Session-Id, State, Client-Port-DNIS,
> >NAS-Identifier, Caller-Id.
> >
> >That isn't enough information for the RADIUS server to decide
> >whether to reject the call, since it may refer to a new extra
> >channel on a Multilink session (should always allow this), or
> >it may instead refer to a new session (should only allow this if
> >there is no other session).
> >
> >The information is present in the accounting request packet that
> >comes later (in the form of a Ascend-Num-In-Multilink sttribute)
> >but by the it's too late to reject the call if it turned out to
> >be a new session.
> >
> >I know there are RADIUS servers that do this, so I cannot help but
> >assume that they reject multilink calls as well duplicate sessions!
> >(Or what am I missing?)
> >
> >-Phil
> >++ Ascend Users Mailing List ++
> >To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> >To get FAQ'd: <http://www.nealis.net/ascend/faq>
> 
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
References: