Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) How to reject multiple logins from RADIUS?
> Actually the Cistron RADIUS works to disallow the login before they get
> authenticated. Also the Esva-Net mods to Livingston RADIUS does the same thing.
> It checks a list to see who is currently logged in and then checks the value to
> see if they are already logged in and how many sessions they are allowed then
> fails or allows the authentication based on that information. It doesn't work
> 100% perfectly but it works pretty well. The Cistron version works much better
> and I hear the Merits works pretty well as well. So yes it does exactly what yo
> u
> want, not kick them off after they are already logged in and authenticated.
Thanks for the information, but I still want to know "HOW" :-)
For example:
User x is attempting to log on. There is already a session for user x and
the maximum for that user is set to 1 session. Should you reject the
login?
"No" is the wrong answer because while you might correctly reject a second
session, you might also reject the second call of a Multilink session,
which is not a second session.
"Yes" is the wrong answer because while you might correctly allow the
second channel of a Multilink call to connect, you are also neglecting to
reject a session (new) session.
-Phil
> -----Original Message-----
> From: Phillip Vandry <vandry@Mlink.NET>
> To: Tim Jung <tjung@igateway.net>
> Cc: ascend-users@bungi.com <ascend-users@bungi.com>
> Date: Saturday, October 17, 1998 4:33 PM
> Subject: 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>
Follow-Ups:
References: