(RADIATOR) SnmpgetProg and DefaultRealms

Hugh Irvine hugh at open.com.au
Mon Mar 17 20:12:37 CST 2003


Hello Jeremy -

Many thanks for your patience and the patch (I finally realize what you 
were trying to say).

The new version of SessSQL.pm is now available in the patches area of 
the web site.

We really appreciate code contributions such as this.

Thanks again.

regards

Hugh


On Tuesday, Mar 18, 2003, at 06:13 Australia/Melbourne, Jeremy Hinton 
wrote:

>
> Hugh,
>
>         I found an error in the patch after i mailed you, the 
> corrected version is below. Just to be clear, the patch does the 
> following:
>
>         If your CountQuery SQL statement is written to return a fifth 
> argument (the default is just four), the value of the fifth argument 
> is used in the  querying of the NAS as the username to look for. If 
> CountQuery just returns four or less, the old behavior is used (use 
> the username in the current query to compare against the NAS entry). 
> So basically this compares the actual username that was used when the 
> session database entry was created to check the accuracy of a login, 
> as opposed to using the current username (as its possible they may 
> differ with customized session database). At any rate, here's the 
> revised patch:
>
> bash-2.05# diff -C 1 SessSQL.pm.dist SessSQL.pm
> *** SessSQL.pm.dist     Mon Mar 17 10:52:06 2003
> --- SessSQL.pm  Mon Mar 17 14:04:51 2003
> ***************
> *** 149,152 ****
>       my (@sessions, $session, $nas_id, $nas_port,
> !       $session_id, $framed_ip_address);
> !     while (($nas_id, $nas_port, $session_id, $framed_ip_address)
>            = $sth->fetchrow())
> --- 149,152 ----
>       my (@sessions, $session, $nas_id, $nas_port,
> !       $session_id, $framed_ip_address, $user_name);
> !     while (($nas_id, $nas_port, $session_id, $framed_ip_address, 
> $user_name)
>            = $sth->fetchrow())
> ***************
> *** 153,155 ****
>       {
> !       push(@sessions, [$nas_id, $nas_port, $session_id, 
> $framed_ip_address]);
>         $count++;
> --- 153,156 ----
>       {
> !       push(@sessions, [$nas_id, $nas_port, $session_id, 
> $framed_ip_address,
> !                        $user_name]);
>         $count++;
> ***************
> *** 164,167 ****
>
> !           ($nas_id, $nas_port, $session_id, $framed_ip_address)
>                 = @$session;
>             my $client;
> --- 165,169 ----
>
> !           ($nas_id, $nas_port, $session_id, $framed_ip_address, 
> $user_name)
>                 = @$session;
> +             $user_name ||= $name;
>             my $client;
> ***************
> *** 170,172 ****
>                 if (!$client->isOnline
> !                   ($name, $nas_id, $nas_port, $session_id, 
> $framed_ip_address))
>                 {
> --- 172,174 ----
>                 if (!$client->isOnline
> !                   ($user_name, $nas_id, $nas_port, $session_id, 
> $framed_ip_address))
>                 {
>
> - jeremy
>
> At 04:54 PM 3/16/2003, you wrote:
>
>> Hello Jeremy -
>>
>> You are not understanding what I am saying.
>>
>> What I am suggesting is that you use RewriteUsername(s) in your 
>> Raditator configuration file so that all usernames get translated to 
>> lower case with the Realm stripped off (for example).
>>
>> Then in your scenario #1 below, the username gets stored in the 
>> session database as "jgh" (original) and "jgh" (rewritten).
>>
>> Then in your scenario #2, the username gets stored as "jgh at acme.com" 
>> (original) and "jgh" (rewritten).
>>
>> Your session database CountQuery uses the rewritten usernames and the 
>> NAS queries use the original usernames.
>>
>> regards
>>
>> Hugh
>>
>>
>> On Sunday, Mar 16, 2003, at 05:00 Australia/Melbourne, Jeremy Hinton 
>> wrote:
>>
>>> Hugh,
>>>
>>>         i understand what you're saying, but i think you may still 
>>> not quite understand the issue i'm trying to describe. Below, i'll 
>>> try to show why your solution wouldn't address the problem.
>>>
>>> Assume the following:
>>> - acme.com is my default realm, so i can log in as jgh or 
>>> jgh at acme.com and its the same thing.
>>> - my session database and queries can detect a multiple logins with 
>>> or without the default realm.
>>> - i am using a Bay NAS which radiator will query via SNMP to confirm 
>>> multiple logins as indicated in the session database.
>>> - i cannot in any way affect what the NAS stores in its SNMP tables 
>>> by a RewriteUsername or similar, as it stores whatever it initally 
>>> gets before it sends the query to radiator.
>>>
>>> ** Call #1
>>> - I dial in and log in as jgh on port 1 of my NAS.
>>> - jgh is now listed in my session database.
>>> - My NAS now shows jgh logged in to port 1 in its internal SNMP 
>>> tables.
>>>
>>> ** Call #2
>>> - I dial in a second time, this time logging in as jgh at acme.com.
>>> - radiator queries the session database and finds the entry for jgh 
>>> on my NAS on port 1. My query is designed so it recognizes this and 
>>> returns a 1 for the count (as it should).
>>> - Now, radiator attempts to verify that the session database is 
>>> accurate, so it queries the NAS. Its checks the NAS SNMP tables to 
>>> see if the username in the current request (jgh at acme.com)  is 
>>> associated with port 1.
>>> - It instead sees that user 'jgh' is on on port 1, not 
>>> 'jgh at acme.com'. So, it deletes the first 'jgh' login from the 
>>> session database as being incorrect, and lets the second 
>>> jgh at acme.com login proceed, and puts an entry for it in the session 
>>> database.
>>>
>>>         I can't change the values in the NAS table, but i can change 
>>> the username in the current request they are compared against 
>>> though, right? So i would fix the above problem if i just rewrote 
>>> the username in the current query and stripped out the realm. that 
>>> way, when the SNMP query was done, it would compare 'jgh' from SNMP 
>>> to 'jgh' from the current request, verify the original login was 
>>> still there, and block the second login attempt.
>>>
>>> If i did that though, what about the reverse scenario:
>>>
>>> ** Call #1
>>> - I dial in and log in as jgh at acme.com on port 1 of my NAS.
>>> - i rewrite the username and strip the realm off.
>>> - jgh is now listed in my session database.
>>> - My NAS however shows jgh at acme.com logged in to port 1 in its 
>>> internal SNMP tables (since the rewrite can't affect those).
>>>
>>> ** Call #2
>>> - I dial in a second time, this time logging in as just jgh.
>>> - radiator queries the session database and finds the entry for jgh 
>>> on my NAS on port 1.
>>> - Now, radiator attempts to verify that the session database is 
>>> accurate, so it queries the NAS. Its checks the NAS SNMP tables to 
>>> see if the username in the current request (jgh) is associated with 
>>> port > 1.
>>> - It instead sees that user 'jgh at acme.com' is on on port 1, not 
>>> 'jgh'. So, it deletes the first 'jgh at acme.com' login from the 
>>> session database as being incorrect, and lets the second 'jgh' login 
>>> proceed, and puts an entry for it in the session database.
>>>
>>>         The only way i've found to address this is to alter the code 
>>> in the specific NAS query module (Bay.pm). With my current changes, 
>>> if the result of the SNMP lookup doesn't contain a realm, the 
>>> default realm is appended. Then, if the username in the current 
>>> request doesn't have a realm, the default realm is appended (just 
>>> for the purpose of the comparison). *Then* the two are compared, and 
>>> if they match, a positive result is returned. This seems to handle 
>>> both of the above scenarios well. Another possibility would be store 
>>> the username before ANY rewrites are done to it in the session 
>>> database, and then when a check was performed, compare *that* value 
>>> with the results of the SNMP query. This actually is the more 
>>> logical solution, as the logic should be that your are trying to 
>>> determine the accuracy of the session database, so the contents of 
>>> it should be compared to the current state of the NAS, not the 
>>> contents of the current packet (though they are often the same). I'm 
>>> not sure how this would be done at the code level though, the idea 
>>> just came to me as i was writing this.
>>>
>>>         I apologize for the length of this, but it can be very 
>>> confusing. Both of the above cases have been verified in a test bed 
>>> here, and you should be able to reproduce them if you still have 
>>> some questions. I hope i've been able to explain this to your 
>>> satisfaction, and if you have any questions, please let me know.
>>>
>>> - jeremy
>>>
>>> At 05:55 PM 3/14/2003, you wrote:
>>>
>>>> Hello Jeremy -
>>>>
>>>> If your session database contains session records that each have 
>>>> the original username from the NAS, and the rewritten username 
>>>> (typically all lowercase with the realm stripped off) added by the 
>>>> AddQuery, then your CountQuery can be constructed to use the 
>>>> rewritten username and the NAS query can continue to use the 
>>>> original username as it already does.
>>>>
>>>> The session database just needs to contain a bit more information 
>>>> in the form of the rewritten username.
>>>>
>>>> I think you are making it a bit too complicated below.
>>>>
>>>> regards
>>>>
>>>> Hugh
>>>>
>>>>
>>>> On Saturday, Mar 15, 2003, at 03:53 Australia/Melbourne, Jeremy 
>>>> Hinton wrote:
>>>>
>>>>>
>>>>> Hugh,
>>>>>
>>>>>         I had to postpone work on this for a bit, and am just now 
>>>>> getting back to it. Maybe i'm missing something, but i don't see 
>>>>> how modifying the session database would help with this. The 
>>>>> session database part is fine, its the NAS query that has the 
>>>>> issue. From reviewing the perl code, the username value sent to 
>>>>> the NAS query function is derived from the current request, not 
>>>>> the active session in the session database. If my terminal servers 
>>>>> SNMP table shows user 'bob' connected, and i attempt a login as 
>>>>> 'bob at visi.net' (my default realm),  the NAS query will fail when 
>>>>> it looks for 'bob at visi.net', delete the old session from the 
>>>>> session database and let me in. I can handle this scenario if i 
>>>>> decide to rewrite the username and strip the realm out. But then, 
>>>>> what about if the terminal server SNMP table has a current login 
>>>>> as 'bob at visi.net' and i try to log in as just 'bob'. Stripping the 
>>>>> realm wont work in this scenario, i'd need to add the realm 
>>>>> instead. This only would look to be an issue with the default 
>>>>> realm, since its the one case where a single entity can log in 
>>>>> correctly one of two ways (with or without the realm). Your second 
>>>>> suggestion of passing the rewritten user-name back to the ts in 
>>>>> the reply looked promising, that way i could force the ts to use 
>>>>> %U@%R in its snmp session tables, but it looks like my Bay's just 
>>>>> ignore any User-Name attributes in the response packet :(. The 
>>>>> only solution i've found is is to alter the NAS query code to 
>>>>> equalize both the search for name and the result by adding the 
>>>>> default realm to both if no realm is specified. I apologize if the 
>>>>> above is not very clear, it gets my mind in knots sometimes trying 
>>>>> to understand it myself.
>>>>>
>>>>> - jeremy
>>>>>
>>>>>  04:36 PM 2/27/2003, Hugh Irvine wrote:
>>>>>
>>>>>> Hello Jeremy -
>>>>>>
>>>>>> The way to deal with this situation is to add a column to the 
>>>>>> session database to contain the rewritten username in addition to 
>>>>>> the original username. Then you can do your session limit 
>>>>>> checking on the rewritten username, and the NAS query can 
>>>>>> continue to use the original username.
>>>>>>
>>>>>> BTW - some NAS's will accept the rewritten username in a 
>>>>>> User-Name attribute in the access accept, or you could also use 
>>>>>> the Class attribute for the same purpose.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>
>>>>>> On Friday, Feb 28, 2003, at 08:23 Australia/Melbourne, Jeremy 
>>>>>> Hinton wrote:
>>>>>>
>>>>>>> Hugh & Mike,
>>>>>>>
>>>>>>>         While working on locking down multiple logins recently, 
>>>>>>> i noticed an interesting situation. I have a default realm of 
>>>>>>> visi.net, so logging in as bob and bob at visi.net are treated the 
>>>>>>> same. I log into the server as bob. i then try to log in to the 
>>>>>>> server as bob at visi.net. Now, i can tailor my SQL lookups to 
>>>>>>> catch this multiple login no problem. *However*, when the NAS 
>>>>>>> itself gets queried with the SnmpgetProg, it only checks against 
>>>>>>> what the term server responds with, which may or may not include 
>>>>>>> the realm. Now, i made a quick hack to the Bay.pm module to auto 
>>>>>>> add my default realm to both the result and the username if no 
>>>>>>> realm is specified, but it was a quick and dirty hack 
>>>>>>> hard-coding my realm.  Maybe i'm missing some way to do this 
>>>>>>> already, but i couldn't find it. I suppose this would be a 
>>>>>>> feature request then :).  At any rate, heres my quick patch:
>>>>>>>
>>>>>>> bash-2.05# diff -C1 Bay.pm Bay.pm.old
>>>>>>> *** Bay.pm      Thu Feb 27 16:01:28 2003
>>>>>>> --- Bay.pm.old      Sun Mar 24 18:10:51 2002
>>>>>>> ***************
>>>>>>> *** 28,34 ****
>>>>>>>       {
>>>>>>> !         my $match = $1;
>>>>>>> !         $match .= "\@visi.net" unless ($match =~ /\@/);
>>>>>>> !         $name .= "\@visi.net" unless ($name =~ /\@/);
>>>>>>> !
>>>>>>> !         return $match eq $name;
>>>>>>>       }
>>>>>>> --- 28,30 ----
>>>>>>>       {
>>>>>>> !       return $1 eq $name;
>>>>>>>       }
>>>>>>>
>>>>>>> - jeremy
>>>>>>>
>>>>>>> ===
>>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>>> Announcements on radiator-announce at open.com.au
>>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>>
>>>>>> NB: have you included a copy of your configuration file (no 
>>>>>> secrets),
>>>>>> together with a trace 4 debug showing what is happening?
>>>>>>
>>>>>> --
>>>>>> Radiator: the most portable, flexible and configurable RADIUS 
>>>>>> server
>>>>>> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS 
>>>>>> X.
>>>>>> -
>>>>>> Nets: internetwork inventory and management - graphical, 
>>>>>> extensible,
>>>>>> flexible with hardware, software, platform and database 
>>>>>> independence.
>>>>>>
>>>>>> ===
>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>> Announcements on radiator-announce at open.com.au
>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>
>>>> NB: have you included a copy of your configuration file (no 
>>>> secrets),
>>>> together with a trace 4 debug showing what is happening?
>>>>
>>>> --
>>>> Radiator: the most portable, flexible and configurable RADIUS server
>>>> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
>>>> -
>>>> Nets: internetwork inventory and management - graphical, extensible,
>>>> flexible with hardware, software, platform and database 
>>>> independence.
>>>
>>
>> NB: have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>> --
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>>
>> ===
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list