Hello, How do I rewrite the value of the User-Name attribute based on Called-Station-Id? I need to do a series of these logical decisions and replace the username with username@<some-isp.com> based on what the value of Called-Station-Id is. rlm_attr_rewrite seems the obvious choice, but I can't figure out how to use various instances of that module only when Called-Station-Id has a certain value. It seems like a strange thing to need to do, but I've thought about our problem and this is really the only scalable way. I can give a lot of background as to why, but I figured I would ask the question first. So, does anyone have any ideas? Also, thank you for all the hard work on Freeradius. Its a great piece of software. Thanks Chris Carver
Christopher Carver wrote:
Hello,
How do I rewrite the value of the User-Name attribute based on Called-Station-Id? I need to do a series of these logical decisions and replace the username with username@<some-isp.com> based on what the value of Called-Station-Id is.
hmm that is a tricky one! One possible solution (untried, so YMMV) may be an approach such as: 1) Define a local attribute "My-ISP-Realm" in etc/raddb/dictionary 2) In the users and/or acct_users file you could have default entries like: DEFAULT Calling-Station-Id == isp1, My-ISP-Realm := isp1.com DEFAULT Calling-Station-Id == isp2, My-ISP-Realm := isp2.com 3) Define an attr_rewrite module that has a replace string something like: replace = %{User-Name}@%{My-ISP-Realm} As I said, un-tried and un-tested and un-guaranteed, but it may be somewhere to look if noone else comes up with a solution. I'm sure someone else will come up with something better though! Goodluck! cheers, Mike
On Monday 13 November 2006 22:24, Christopher Carver wrote:
Hello,
How do I rewrite the value of the User-Name attribute based on Called-Station-Id? I need to do a series of these logical decisions and replace the username with username@<some-isp.com> based on what the value of Called-Station-Id is.
rlm_attr_rewrite seems the obvious choice, but I can't figure out how to use various instances of that module only when Called-Station-Id has a certain value.
It seems like a strange thing to need to do, but I've thought about our problem and this is really the only scalable way. I can give a lot of background as to why, but I figured I would ask the question first. So, does anyone have any ideas?
Also, thank you for all the hard work on Freeradius. Its a great piece of software.
Thanks
Chris Carver
Not a crazy question at all. We used a hints file entry like: DEFAULT Called-Station-Id =~ "^(012)?3456789$" User-Name := "%{User-Name}@some-isp.com" After that, it's pretty easy. Just make sure the some-isp.com realm is in proxy.conf and it should act like any other normal request. Kevin Bonner
Quoting Kevin Bonner <keb@pa.net>:
On Monday 13 November 2006 22:24, Christopher Carver wrote:
Hello,
How do I rewrite the value of the User-Name attribute based on Called-Station-Id? I need to do a series of these logical decisions and replace the username with username@<some-isp.com> based on what the value of Called-Station-Id is.
rlm_attr_rewrite seems the obvious choice, but I can't figure out how to use various instances of that module only when Called-Station-Id has a certain value.
It seems like a strange thing to need to do, but I've thought about our problem and this is really the only scalable way. I can give a lot of background as to why, but I figured I would ask the question first. So, does anyone have any ideas?
Also, thank you for all the hard work on Freeradius. Its a great piece of software.
Thanks
Chris Carver
Not a crazy question at all. We used a hints file entry like:
DEFAULT Called-Station-Id =~ "^(012)?3456789$" User-Name := "%{User-Name}@some-isp.com"
After that, it's pretty easy. Just make sure the some-isp.com realm is in proxy.conf and it should act like any other normal request.
Kevin Bonner
Thanks for the reply, Kevin. You got me on the right track, but I still don't quite have it right. It seems as though the users file can only manipulate reply A/V pairs. I am using mysql to authorize and authenticate, so, I need rlm_sql_mysql to see the new and changed User-Name. This means I need to modify the User-Name on the access-request list of A/V pairs. Something like this... DEFAULT Called-Station-Id =~ "^(012)?3456789$" %{request:User-Name} := `%{request:User-Name}@isp.com`, Fall-Through = yes But that doesn't work. See if I do just: DEFAULT Called-Station-Id =~ "^(012)?3456789$" User-Name := `%{request:User-Name}@isp.com`, Fall-Through = yes The reply packet just has the User-Name attribute changed. That doesn't do what I want, because I aut with rlm_sql_mysql and it needs to see the changed username with the suffix added. Any ideas? Anyone? Thanks, Chris Carver Network Engineer
Hi Chris, Christopher Carver wrote:
Thanks for the reply, Kevin. You got me on the right track, but I still don't quite have it right. It seems as though the users file can only manipulate
Kevin's solution uses the "hints" file, not the "users" file. You'll need to enable the preprocess module in the authorize section of radiusd.conf if it isn't already. cheers, Mike
Quoting Michael Mitchell <mitchell.michael@bigpond.com>:
Hi Chris,
Christopher Carver wrote:
Thanks for the reply, Kevin. You got me on the right track, but I still
don't
quite have it right. It seems as though the users file can only manipulate
Kevin's solution uses the "hints" file, not the "users" file. You'll need to enable the preprocess module in the authorize section of radiusd.conf if it isn't already.
cheers, Mike
Thanks for the help Mike and Kevin. Well, I've made the change in the hints file. The proprocesses module is matching on the correct line of the hints file, but the change to the User-Name isn't actually taking place. It continues on to other modules with the same value. From hints (line 1, where preprocesses is matching): DEFAULT User-Name := "%{User-Name}@some-isp.com" I excluded the check for Called-Station-Id for now to keep things simple. I use radclient to send an access accept packet where the username is "carver" along with the correct password. Thats the test user account name. Here is the radiusd -X output: rad_recv: Access-Request packet from host 127.0.0.1:32858, id=14, length=46 User-Name = "carver" User-Password = "carver" rad_lowerpair: User-Name now 'carver' rad_rmspace_pair: User-Name now 'carver' modcall: entering group authorize for request 0 hints: Matched DEFAULT at 1 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched DEFAULT at 10 modcall[authorize]: module "files" returns ok for request 0 radius_xlat: 'carver' rlm_sql (sql): sql_set_user escaped user --> 'carver' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'carver' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 5 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'carver' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = 'carver' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'carver' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.prio' rlm_sql (sql): Released sql socket id: 5 modcall[authorize]: module "sql" returns ok for request 0 modcall: group authorize returns ok for request 0 auth: type Crypt Login OK: [carver] (from client localhost port 0) In theory it should be processing it after hints as carver@some-isp.com. But its still using the original username as if the change in hints had never ocurred. Any ideas? Thanks for the help so far. I really appreciate it. Chris Carver
Quoting Christopher Carver <ccarver@pennswoods.net>:
Quoting Michael Mitchell <mitchell.michael@bigpond.com>:
Hi Chris,
Christopher Carver wrote:
Thanks for the reply, Kevin. You got me on the right track, but I still
don't
quite have it right. It seems as though the users file can only manipulate
Kevin's solution uses the "hints" file, not the "users" file. You'll need to enable the preprocess module in the authorize section of radiusd.conf if it isn't already.
cheers, Mike
Thanks for the help Mike and Kevin. Well, I've made the change in the hints file. The proprocesses module is matching on the correct line of the hints file, but the change to the User-Name isn't actually taking place. It continues on to other modules with the same value. From hints (line 1, where preprocesses is matching):
DEFAULT User-Name := "%{User-Name}@some-isp.com"
I excluded the check for Called-Station-Id for now to keep things simple. I use radclient to send an access accept packet where the username is "carver" along with the correct password. Thats the test user account name. Here is the radiusd -X output:
rad_recv: Access-Request packet from host 127.0.0.1:32858, id=14, length=46 User-Name = "carver" User-Password = "carver" rad_lowerpair: User-Name now 'carver' rad_rmspace_pair: User-Name now 'carver' modcall: entering group authorize for request 0 hints: Matched DEFAULT at 1 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched DEFAULT at 10 modcall[authorize]: module "files" returns ok for request 0 radius_xlat: 'carver' rlm_sql (sql): sql_set_user escaped user --> 'carver' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'carver' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 5 radius_xlat: 'SELECT
radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op
FROM radgroupcheck,usergroup WHERE usergroup.Username = 'carver' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = 'carver' ORDER BY id' radius_xlat: 'SELECT
radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op
FROM radgroupreply,usergroup WHERE usergroup.Username = 'carver' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.prio' rlm_sql (sql): Released sql socket id: 5 modcall[authorize]: module "sql" returns ok for request 0 modcall: group authorize returns ok for request 0 auth: type Crypt Login OK: [carver] (from client localhost port 0)
In theory it should be processing it after hints as carver@some-isp.com. But its still using the original username as if the change in hints had never ocurred. Any ideas?
Thanks for the help so far. I really appreciate it.
Chris Carver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
No one has any idea about this?
On Friday 17 November 2006 21:06, Christopher Carver wrote:
No one has any idea about this?
Configured in our test environment and it's working for me. Maybe something from the configs below will stand out... -Kevin == hints == DEFAULT User-Name := "%{User-Name}@some-isp.com" == end hints == == proxy.conf == realm some-isp.com { type = radius authhost = LOCAL accthost = LOCAL } == end proxy.conf == == users == keb User-Password := "test" == end users == == radiusd -X == rad_recv: Access-Request packet from host 192.168.2.212:32973, id=64, length=55 User-Name = "keb" User-Password = "test" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 rad_lowerpair: User-Name now 'keb' Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 5 radius_xlat: 'keb@some-isp.com' modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: Looking up realm "some-isp.com" for User-Name = "keb@some-isp.com" rlm_realm: Found realm "some-isp.com" rlm_realm: Adding Stripped-User-Name = "keb" rlm_realm: Proxying request from user keb to realm some-isp.com rlm_realm: Adding Realm = "some-isp.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry keb at line 5 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [keb@some-isp.com] (from client local port 0) == end radiusd -X ==
If all else fails, rlm_perl dug me out of a big, rather similar hole :) Jan On 21/11/06, Kevin Bonner <keb@pa.net> wrote:
On Friday 17 November 2006 21:06, Christopher Carver wrote:
No one has any idea about this?
Configured in our test environment and it's working for me. Maybe something from the configs below will stand out...
-Kevin
== hints == DEFAULT User-Name := "%{User-Name}@some-isp.com" == end hints ==
== proxy.conf == realm some-isp.com { type = radius authhost = LOCAL accthost = LOCAL } == end proxy.conf ==
== users == keb User-Password := "test" == end users ==
== radiusd -X == rad_recv: Access-Request packet from host 192.168.2.212:32973, id=64, length=55 User-Name = "keb" User-Password = "test" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 rad_lowerpair: User-Name now 'keb' Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 5 radius_xlat: 'keb@some-isp.com' modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: Looking up realm "some-isp.com" for User-Name = "keb@some-isp.com" rlm_realm: Found realm "some-isp.com" rlm_realm: Adding Stripped-User-Name = "keb" rlm_realm: Proxying request from user keb to realm some-isp.com rlm_realm: Adding Realm = "some-isp.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry keb at line 5 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [keb@some-isp.com] (from client local port 0) == end radiusd -X ==
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thursday 16 November 2006 04:56, Christopher Carver wrote:
Quoting Kevin Bonner <keb@pa.net>:
Not a crazy question at all. We used a hints file entry like: ... It seems as though the users file can only manipulate reply A/V pairs.
Correct. The hints file can manipulate the request before any other module touches it. Add the entry to your _hints_ file and it should work. Kevin Bonner
participants (4)
-
Christopher Carver -
Jan Mulders -
Kevin Bonner -
Michael Mitchell