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 you
want, not kick them off after they are already logged in and authenticated.

Tim Jung
System Admin
Internet Gateway Inc.
tjung@igateway.net


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