(RADIATOR) delete_attr('User-Name') in PreClientHook
Hugh Irvine
hugh at open.com.au
Thu Feb 23 17:43:40 CST 2006
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?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
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