Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) How to reject multiple logins from RADIUS?
Why don't you download the freely available source for
any of the many RADIUS servers given as examples and look
at how they implement the feature you are questioning? It
is frustrating to watch people try to help you and have you just
keep asking the same question in a more and more argumentative
tone. If you really NEED TO KNOW -- do a little research
with the tools people have offered to you!
The best thing for you to do is grab the source, unpack it,
type 'vi blah.c' and peer through the code. Even if you're
not a programmer, you may still be able to determine the
program logic by looking at the comments in the code or
by looking at the code and intrepreting it as pseudo-code.
Here's how I did it -- I figured it out in about 5 minutes
-- (please note I am NOT a C programmer in the least. If you
are, then you can probably figure this out in 1 minute):
1) I downloaded the source from the Cistron FTP site:
(see http://homepage.cistron.nl/~miquels/radius/ --
if you'll recall, some kind person who was trying to help
you provided that URL for your reference)
2) I unpacked the source distribution (using UNIX tools
'tar' and 'gzip')
3) I read through the README file noting the paragraph dealing
with "Simultaneous Use". I noted a new attribute named
"Simultaneous-Use" (that's in paragraph 4f) that seemed to
deal with the issue at hand.
4) I used the very powerful "grep" program on my UNIX system.
It searches for regular expressions in text files (or any
input stream... but let's not stumble over the details).
I typed:
grep Simultaneous-Use *
It matched one file -- auth.c
5) I opened auth.c using a text editor (vi - it's great...) and searched
for Simultaneous-Use. On line 629 the code snippet is found:
/*
* User authenticated O.K. Now we have to check
* for the Simultaneous-Use parameter.
*/
if ((r = rad_check_multi(namepair->strvalue, authreq->request,
check_item->lvalue)) != 0) {
(I'm guessing even non-programmers can figure out that this code is
calling the subroutine rad_check_multi())
6) rad_check_multi() is in the same file (auth.c). Here's
the code snippet:
/*
* See if a user is already logged in.
*
* Check twice. If on the first pass the user exceeds his
* max. number of logins, do a second pass and validate all
* logins by querying the terminal server (using eg. telnet).
*
* Returns: 0 == OK, 1 == double logins, 2 == multilink attempt
*/
int rad_check_multi(char *name, VALUE_PAIR *request, int maxsimul)
{
Ok, so from not even looking at the subroutine's code -- I can logically
guess that the program keeps some kind of internal state file for active
sessions, and if a duplicate login is found, it brute-forces it's way
back to the RAS and attempts to validate a session using telnet. It appears
(from the comment) that it can figure out the difference between duplicate
sessions and a multilink attempt.
SO in this case, HOW is as follows:
1) radiusd gets a username/password packet
2) it authenticates based on the credentials supplied (it appears
CISTRON radius can only auth using UNIX password file or entries
in the RADIUS users file)
3) before it ACKS the login, it checks the Simultaneous-Use parameter
4) If the user fails the rad_check_multi() check, it NAKs the login
I imagine this approach isn't foolproof, but it's one approach.
I also imagine all the other RADIUS vendors have a different approach.
Many of them include source -- download it and learn! Quit expecting
everyone to give you a gift-wrapped answer.
Thank you for your time. Print out this email and keep it for
future questions you may have. The logic flow is very linear and
can be applied to a variety of computer-related questions.
>
>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>
++ 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: