(RADIATOR) SnmpgetProg and DefaultRealms

[Hugh Irvine]

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.

===
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.