(RADIATOR) delete_attr('User-Name') in PreClientHook
Toomas Kärner
tomkar at estpak.ee
Mon Feb 27 02:25:24 CST 2006
Hello Hugh,
This "proxy" in between does the trick:
#####################
#####################
AcctPort xxxx
AuthPort
LogDir /home/.../redback/acct/
DictionaryFile /home/.../rfc.dictionary,\
/home/.../redback.dictionary
Trace 4
#####################
<Client x.x.x.x>
.
.
.
</Client>
#####################
<AuthBy SQL>
Identifier GetDataFromSession
DBSource ...
DBUsername ...
DBAuth ...
AuthenticateAccounting
NoDefault
AuthSelect SELECT \
if(isnull(username),'%u at dhcp',username) \
from session where \
s_id = '%{Class}'
AuthColumnDef 0, ETC-User-Name, request
</AuthBy SQL>
#####################
<AuthBy RADIUS>
Identifier IntoAcct
<Host localhost>
Secret ...
AuthPort
AcctPort ...
Retries 0
RetryTimeout 3
</Host>
StripFromRequest User-Name
AddToRequest User-Name=%{ETC-User-Name}
</AuthBy>
#####################
<Realm DEFAULT>
AuthByPolicy ContinueWhileAccept
AuthBy GetDataFromSession
AuthBy IntoAcct
</Realm DEFAULT>
######################
######################
Next Radius will pick up normal accounting and if user is not really
authenticated there will be something like this:
"00:0b:cd:8c:61:ed at dhcp" for his username - @dhcp as a special realm so
this log can be piped into different accounting module.
Rgds.
Toomas
Friday, February 24, 2006, 1:43:40 AM, you wrote:
> Hello Toomas -
> Many thanks for the detailled description - it helps our
> understanding immensely.
> One possible solution to your problem may be to return the "real"
> User-Name in the second access accept. Some NAS equipment supports
> this so that you can do exactly what you descibe - check with your
> NAS vendor for details.
> And you are correct that there is nothing "special" about the User-
> Name attribute - its just that Radiator caches the User-Name
> internally for various reasons, hence as you know you must use
> changeUserName in your hook to make sure that it really is changed.
> I see Mike has added AuthenticateAccounting to the patches for
> Radiator 3.14, so that may also help.
> BTW - you don't need to use a "bogus" attribute if you decide to go
> down that path - you can use your own vendor-specific (or OSC-
> AVPAIR), or just use Prosy-State for proxied requests.
> The weather is relatively hot here at the moment - maximum in the
> mid-30's.
> http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDV10450.txt
> I'm in Sydney this week, then Perth for the following 10 days.
> regards
> Hugh
> On 23 Feb 2006, at 17:52, Toomas Kärner wrote:
>> 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?
>>
>>
> 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.
More information about the radiator
mailing list