Hi, I am having some problems with attr_rewrite. What I want to do is the following at a pre authorisation phase: User-Name = username@somedomain.com To User-Name = somedomain.com I want to call by attr_rewrite function for each of the domains that I want to stip the username from prior to authorisation. This is what I have in radiusd.conf: attr_rewrite checkdomain1 { attribute = User-Name searchin = packet searchfor = ".@domain1.net" replacewith = "domain1.net" ignore_case = yes new_attribute = no max_matches = 10 append = no This is kind of working but =mMy problem is that I am not sure what to use in the regular expersion for the match query: I have tried .@domain1.com, ^$@domain1.com, ?@domain.com, \w.@domain.com I have read the list history and trawlled google and I guess I am just not bright enough to get these pesky (ir)regular expressions! Can someone please tell me what I need to put in here: searchfor = ".@domain1.net" To match: anything@domain1.net Why Am I doing this??? ---------------------- DSL Wholesale Layer2 Tunneling Switch - (LTS) 1 querries my Radius Server 1 for tunnel paramaters. Radius Server 1 will then for: user@mydomain.com into various Tunnels / groups swtiched based on full username to NAS1,2,3 etc domain1.com classify any users at this domain into tunnel1 and switch to LTS 2 domain2.com classify any users at this domain into tunnel2 and switch to LTS 2 Because I dont know the users in domain1&2, I cant authenticate using the fully qualified username, and for other reasons it is not possible to set LTS1 to athenticate its tunnels based on realm rather than username, it has to use username. So -tThis above is why I am trying to rewrite the user to be just a realm in radius server 1 for domain 1&2.net For those that are intersted, what happens next is... LTS 2 then looks up in another radius server (radius 2) for the tunnel ID where to switch the tunnel to for the terminating NAS for that partner/reseller. This NAS will then query its radius server (a third party) to handle the actual user authentication and PPP paramaters. For mydomain.com NAS1,2,3 will querry radius server 3 for the authentication of my own users and PPP paramaters. So: DSL Wholesale LTS -> In house NASes or In house LTS boxes In house LTS boxes -> Partner NASes Kind Regards Ben
On Monday 19 February 2007 15:29, Ben Butler wrote:
Hi,
I am having some problems with attr_rewrite.
What I want to do is the following at a pre authorisation phase:
User-Name = username@somedomain.com
To
User-Name = somedomain.com
I want to call by attr_rewrite function for each of the domains that I want to stip the username from prior to authorisation.
I'm not very familiar with attr_rewrite, so I'm posting what I would do if I were presented with this issue. We use the hints file to rewrite the request username, as needed. A hints file example that should do what you want: DEFAULT User-Name =~ "^.*@somedomain.com$" User-Name := "somedomain.com" Then just define somedomain.com in your users file (or DB) and process it like a normal request. Kevin Bonner
Hi Kevin, That has worked a treat. It works in attr_rewrite as well, but I ended up going with your hints file method as I also need to rewrite the password attribute as well and could not see how this could be conditionally done with the att_rewrite based on the value of the username attibute. Many thanks! Help website on regular expressions have been driving me around the twist all afternoon. Now, my next little querry is since turning on RFC2867 Accounting in my Cisco LTS & LNS boxes to get extended tunnel accounting info. I am getting the folllowing in my log files (plus other codes): Unsupported Acct-Status-Type = 12 Despite these existing in my dictionary file: Unsupported Acct-Status-Type = 12 ATTRIBUTE Acct-Status-Type 40 integer VALUE Acct-Status-Type Tunnel-Start 9 VALUE Acct-Status-Type Tunnel-Stop 10 VALUE Acct-Status-Type Tunnel-Reject 11 VALUE Acct-Status-Type Tunnel-Link-Start 12 VALUE Acct-Status-Type Tunnel-Link-Stop 13 VALUE Acct-Status-Type Tunnel-Link-Reject 14 VALUE Acct-Status-Type Failed 15 I have been looking at this and cant for the life of me see why it thinks its unsupported when it is in the file and the dictionary file is definetly being parsed. Anyone got any ideas, TIA. Kind Regards Ben
Ben Butler wrote:
I am getting the folllowing in my log files (plus other codes):
Unsupported Acct-Status-Type = 12
That's likely from the SQL module. It helps to show *all* of the message, rather than editing it.
Despite these existing in my dictionary file:
The dictionaries define the types. They don't say what the server does when it receives one of those packets. The SQL module currently is hard-coded to support only a few Acct-Status-Types. Adding more isn't hard, but requires code. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi Alan, Hard as in nice text file I can edit replicating examples of what already is there. Or Hard Hard as in C and compilers and what not. What would I have to edit to alter the way the SQL module functions. Kind Regards Ben ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: "Ben Butler" <freeradius@dfa.me.uk>; "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, February 20, 2007 8:39 AM Subject: Re: was Re: attr_rewrite - now RFC2867 Ben Butler wrote:
I am getting the folllowing in my log files (plus other codes):
Unsupported Acct-Status-Type = 12
That's likely from the SQL module. It helps to show *all* of the message, rather than editing it.
Despite these existing in my dictionary file:
The dictionaries define the types. They don't say what the server does when it receives one of those packets. The SQL module currently is hard-coded to support only a few Acct-Status-Types. Adding more isn't hard, but requires code. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Ben Butler wrote:
Hard as in nice text file I can edit replicating examples of what already is there.
Or Hard Hard as in C and compilers and what not.
Writing more C code.
What would I have to edit to alter the way the SQL module functions.
See the hard-coded queries in rlm_sql.c (I think), versus the more configurable way of handling it in rlm_sql_log.c. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi, Indeed it is coming from the SQL module and radutmp. Tue Feb 20 14:02:09 2007 : Error: rlm_radutmp: NAS bb-rtr1-rbhx-thn.hgfhgfh.net port 882 unknown packet type 12) Tue Feb 20 14:02:09 2007 : Error: rlm_radutmp: NAS bb-rtr1-rbhx-thn.hgfhgfh.net port 882 unknown packet type 12) Tue Feb 20 14:02:09 2007 : Info: rlm_sql (sql): Unsupported Acct-Status-Type = 12 Tue Feb 20 14:04:24 2007 : Error: rlm_radutmp: NAS bb-rtr1-rbhx-thn.hgfhgfh.net port 281 unknown packet type 14) Tue Feb 20 14:04:24 2007 : Error: rlm_radutmp: NAS bb-rtr1-rbhx-thn.hgfhgfh.net port 281 unknown packet type 14) Tue Feb 20 14:04:24 2007 : Info: rlm_sql (sql): Unsupported Acct-Status-Type = 14 Kind Regards Ben ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: "Ben Butler" <freeradius@dfa.me.uk>; "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, February 20, 2007 8:39 AM Subject: Re: was Re: attr_rewrite - now RFC2867 Ben Butler wrote:
I am getting the folllowing in my log files (plus other codes):
Unsupported Acct-Status-Type = 12
That's likely from the SQL module. It helps to show *all* of the message, rather than editing it.
Despite these existing in my dictionary file:
The dictionaries define the types. They don't say what the server does when it receives one of those packets. The SQL module currently is hard-coded to support only a few Acct-Status-Types. Adding more isn't hard, but requires code. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Ben Butler -
Kevin Bonner