(RADIATOR) delete_attr('User-Name') in PreClientHook

Thu Feb 23 00:52:39 CST 2006

Hello Hugh,

Class is out of simply because when session starts I have no username
:P - sound weird? Let me explain:
step 1: subscriber pc requests ip with dhcp from SE, SE generates
Access-Request for radius User-Name = subscriber MAC (no real username
password involved - not possible with dhcp).
step 2: radius consults with sessionDB verifying that it is
unauthenticated mac, inserts into sessionDB new session with unAuth
session parameters. Replies to SE with Access-Accept and restrictions
for traffic and redirect for all http packets to authentication
web-portal. (Class is inserted here - I still have no username. I
insert sessionDB record ID into class to speed up later transactions
with same session)
step 3: First accounting received - still no username to put in there.
step 4: User authenticates on web-portal. On proper authentication
his/hers sessionDB record is updated with proper service parameters,
real usernames, timeouts etc. based on id from class attribute (web
portal consults also with sessionDB before authentication so show
area-based web-design and gets some parameters, id from class being
one of them). PostAuthHook for portal radius service does SNMP-SET for
SE to make it reauth this particular session.
step 5: SE sends Access-Request, radius consults sessionDB, finds real
username, service paramters. Radius replies with Access-Accept again
with probably more speed, more open ACL's and redirect rule lifted
from this session - user starts getting somewhere else also than only
authentication web-page.
step 6: SE sends second Accounting - into this one I could already
insert a real username.

Question that you might have: Why I could not insert it into some
bogus attribute and log that?
Answer: This system will be working together with international
roaming partners then I need to send them right attributes in right
places. Using User-Name attribute gives me possibilities to use realms
and so on later in accounting storing procedures.

Workaround with two radius processes works ... made it yesterday
already.. But it does not take my question down ..
RFC2865 is not saying anything about User-Name being special...
http://www.freeradius.org/rfc/rfc2865.html#User-Name
(sorry for resource - first one I found).
I'm not trying to get some kind of "fix" for it in short term but I
just want to get an explanation to myself, why it is acting the way it
does, so I could understand radiator better and reduce future
development time by not running into some unknowns ..
PS. how's the weather in .au? Here in .ee is -7C .. pretty warm for
this time of the year :D ...

Rgds.
Toomas

Thursday, February 23, 2006, 12:23:44 AM, you wrote:

> Hello Toomas, Hello Frank -

> I generally find it simpler to use the Class attribute for this sort  
> of thing.

> You can add whatever string you want to use in your accounting to a  
> Class attribute in the Access-Accept, and then just use the Class  
> attribute directly in your accounting. The Class attribute can be  
> added to an Access-Accept and the subsequent accounting for the  
> session will include the Class attribute unchanged (subject to  
> testing in your environment of course). This way you don't have to  
> mess around with rewrites and so on.

> hope that helps

> regards

> Hugh

> On 23 Feb 2006, at 07:14, Frank Danielson wrote:

>> So if I understand you correctly you want to use  
>> AuthenticateAccounting to
>> rewrite the user  name with a value from the database. I don't  
>> think it is
>> designed to work that way. The AuthColumnDef may modify the  
>> attribute in the
>> request but changing the user name is different because it is  
>> stored in more
>> than one place. That's why you used ChangeUserName() in your hook.
>>
>> I would suggest that the best place to do it is in a hook but you  
>> already
>> stated that you don't like to do database operations in a hook.
>>
>> The next option I'd reccomend would be to write an AuthBy module that
>> inherits from AuthBySQL and simply performs the ChangeUserName()  
>> function
>> after passing the request through the superclass. Or you could patch
>> AuthBySQL to call ChangeUserName() when User-Name is defined as a  
>> reply
>> item.
>>
>> Of course I may have misunderstood your goals.
>>
>> -Frank
>>
>> -----Original Message-----
>> From: Toomas Kärner [mailto:tomkar at estpak.ee]
>> Sent: Wednesday, February 22, 2006 10:16 AM
>> Cc: radiator at open.com.au
>> Subject: Re[2]: (RADIATOR) delete_attr('User-Name') in PreClientHook
>>
>>
>> Hello all,
>>
>> This is exactly what I'm trying to do, Camilo... that table being  
>> sessionDB.
>> I what to rewrite accounting records every time they come based on
>> SessionDB.
>>
>> Frank Danielson,
>> Using ChangeUserName() is well known to me. But it does not solve my
>> problem because I want to completely remove it from the request and
>> add "real" username back with this configuration sample below.
>> I had my PrClientHook doing all that (fetching real username from
>> sessionDB and replacing it in request with ChangeUsername()) before
>> but I dont like having database transactions in a hook. Now, when
>> AuthenticateAccounting is also working I should have no problem doing
>> it all with config.
>>
>> Rgds&Thnks
>> Toomas
>>
>>
>>
>> Wednesday, February 22, 2006, 4:45:36 PM, you wrote:
>>
>>> Hi Toomas
>>
>>> when you rewrite the username, the NAS does not know about this, so
>>> in the accounting requests it sends the mac address again as  
>>> username.
>>> one recomendation is to keep track of the MAC and username in a
>>> sepparate table and rewrite the accounting username based on that  
>>> table.
>>
>>
>>> On 2/22/06, Toomas Kärner <tomkar at estpak.ee> wrote:
>>>  Hi,
>>
>>> For some reason I'm unable to remove User-Name attribute from  
>>> incoming
>>> Acct-Request with PreClientHook:
>>> sub {
>>> my $p = ${$_[0]};
>>> my $mac_username = $p->getUserName;
>>>     if ($mac_username) {
>>>          $p->delete_attr('User-Name');
>>         $p->>add_attr('ETC-Mac',$mac_username);
>>>         &main::log($main::LOG_DEBUG,"Username attribute with value
>>> $mac_username stripped and put into ETC-Mac");
>>>     }
>>> }
>>
>>> Setup goes like this:
>>> Redback SE sends it CLIPS accounting :
>>> *** Received from x.x.x.x port 1812 ....
>>> Code:       Accounting-Request
>>> Identifier: 177
>>> Authentic:  p$<226>!G<226><17><249>81<18>5<202>Ho=
>>> Attributes:
>>>         User-Name = "00:0b:cd:8c:61:ed"
>>>         Acct-Status-Type = Stop
>>>         Acct-Session-Id = "0001FFFF780001D3-43140C10"
>>>         Class = "127828"
>>>         .
>>>         .
>>
>>> For that NAS, MAC is the user since it does not know any better...
>>> Now I want to remove this username attribute and with PreClientHook
>>> and insert a real username based on information from sessionDB like
>>> this:
>>> <AuthBy SQL>
>>>         Identifier GetDataFromSession
>>>         DBSource        dbi:mysql:xx:x.x.x.x
>>>         DBUsername      xxx
>>>         DBAuth          xxx
>>>         AuthenticateAccounting
>>>         AuthSelect      SELECT \
>>>                         username \
>>>                         from wnsession where \
>>>                         class_id = '%{Class}'
>>>         AuthColumnDef   0,      User-Name, request
>>>         NoDefault
>>> </AuthBy SQL>
>>
>>> But for some reason I still get the MAC later into accounting as the
>>> username.
>>
>>> I have some workarounds but I dont like them very much and I got
>>> interested what I'm doing wrong...
>>
>>> Rgds.
>>> Toomas
>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> 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.
>>
>> --
>> 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 read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/ 
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?

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