(RADIATOR) delete_attr('User-Name') in PreClientHook
Hugh Irvine
hugh at open.com.au
Wed Feb 22 16:23:44 CST 2006
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?
--
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