Virtual Server not setting attributes on reply
Hi, I'm having problems when using a virtual server. When using the "virtual_server" I'm not getting the reply attributes set. It may be a config thing, but I haven't been able to find where the problem is from the documentation. And I can't understand why there would be the difference. I have 2 realms set using the same virtual server. The only difference is realm TEST1 { virtual_server = test } realm TEST2 { type = radius format = prefix delimiter = "/" authhost = 127.0.0.1:11812 accthost = 127.0.0.1:11813 secret = secret } If I authenticate to TEST1/user My response is "only" a successful auth. If I authenticate to TEST2/user My response is a successful auth WITH Attributes (in this case the attribute I'm setting is Cisco-AVPair = "shell:priv-lvl=15" It appears to me that using the virtual server is stripping the attributes from the reply. Can anyone tell me a) The approprate documentation covering this is so I know. b) What I have done wrong (and where to find the answers) or c) This is an actual bug and someone will look at it Thanks Timothy
Hi,
If I authenticate to TEST1/user My response is "only" a successful auth.
If I authenticate to TEST2/user My response is a successful auth WITH Attributes (in this case the attribute I'm setting is Cisco-AVPair = "shell:priv-lvl=15"
where are you setting that attribute? in the default virtual_server in the post-auth?
It appears to me that using the virtual server is stripping the attributes from the reply.
check your attr filter - check that those attributes arent cleared - if you run in full debug mode you should see everything that is happening and exactly where it gets set and where it gets wiped alan
2009/12/21 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>:
Hi,
If I authenticate to TEST1/user My response is "only" a successful auth.
If I authenticate to TEST2/user My response is a successful auth WITH Attributes (in this case the attribute I'm setting is Cisco-AVPair = "shell:priv-lvl=15"
where are you setting that attribute? in the default virtual_server in the post-auth?
Not the default virtual server. The test virtual server The flow is client -> default virtual server acting as a proxy -> test virtual server If the test virtual server is configured as a remote radius server then things work great. If it's configured as a virtual server using the "virtual_server=name" then things break. I'm setting the attribues in the test virtual server via post-auth. The idea would be to have the different virtual servers using tables / databases for their own user list.
It appears to me that using the virtual server is stripping the attributes from the reply.
check your attr filter - check that those attributes arent cleared - if you run in full debug mode you should see everything that is happening and exactly where it gets set and where it gets wiped
The attributes just don't look to be getting set. I'm guessing that the post-auth section isn't being used with you proxy to a "virtual server" rather than to a "real" server realm TEST1 using "virtual server" rad_recv: Access-Request packet from host 192.168.183.20 port 2530, id=16, length=106 User-Name = "TEST1/default" Acct-Session-Id = "1261403370P17nsl" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "Localhost" NAS-Port = 0 Calling-Station-Id = "1115551212" User-Password = "password" +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop rlm_realm: Looking up realm "TEST1" for User-Name = "TEST1/default" rlm_realm: Found realm "TEST1" rlm_realm: Adding Stripped-User-Name = "default" rlm_realm: Adding Realm = "TEST1" rlm_realm: Proxying request from user default to realm TEST1 rlm_realm: Preparing to proxy authentication request to realm "TEST1" ++[slash] returns updated rlm_realm: Request already proxied. Ignoring. ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop
Sending proxied request internally to virtual server. server test { +- entering group authorize expand: %{Stripped-User-Name} -> default expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> default rlm_sql (sql): sql_set_user escaped user --> 'default' rlm_sql (sql): Reserving sql socket id: 3 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'default' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'default' ORDER BY id rlm_sql (sql): User found in radcheck table expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'default' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radreply WHERE username = 'default' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'default' ORDER BY priority rlm_sql_mysql: query: SELECT groupname FROM radusergroup WHERE username = 'default' ORDER BY priority expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'shells' ORDER BY id rlm_sql_mysql: query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'shells' ORDER BY id rlm_sql (sql): User found in group shells expand: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'shells' ORDER BY id rlm_sql_mysql: query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'shells' ORDER BY id rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop rlm_pap: Normalizing MD5-Password from hex encoding ++[pap] returns updated rad_check_password: Found Auth-Type auth: type "PAP" +- entering group PAP rlm_pap: login attempt with password "password" rlm_pap: Using MD5 encryption. rlm_pap: User authenticated successfully ++[pap] returns ok Login OK: [default/password] (from client desktop port 0 cli 1115551212 via TLS tunnel) +- entering group post-auth rlm_sql (sql): Processing sql_postauth expand: %{Stripped-User-Name} -> default expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> default rlm_sql (sql): sql_set_user escaped user --> 'default' expand: %{User-Password} -> password expand: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:49:30') expand: /var/log/freeradius/sqltrace.sql -> /var/log/freeradius/sqltrace.sql rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:49:30') rlm_sql (sql): Reserving sql socket id: 2 rlm_sql_mysql: query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:49:30') rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok } # server test Going to the next request <<< Received proxied response from internal virtual server. +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop rlm_realm: Proxy reply, or no User-Name. Ignoring. ++[slash] returns noop rlm_realm: Proxy reply, or no User-Name. Ignoring. ++[suffix] returns noop ++[eap] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [TEST1/default/password] (from client desktop port 0 cli 1115551212) +- entering group post-auth ++[exec] returns noop Sending Access-Accept of id 16 to 192.168.183.20 port 2530 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 16 with timestamp +11 Ready to process requests.
realm TEST2 using "real" server rad_recv: Access-Request packet from host 192.168.183.20 port 2535, id=17, length=106 User-Name = "TEST2/default" Acct-Session-Id = "1261403531L18dgh" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "Localhost" NAS-Port = 0 Calling-Station-Id = "1115551212" User-Password = "password" +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop rlm_realm: Looking up realm "TEST2" for User-Name = "TEST2/default" rlm_realm: Found realm "TEST2" rlm_realm: Adding Stripped-User-Name = "default" rlm_realm: Adding Realm = "TEST2" rlm_realm: Proxying request from user default to realm TEST2 rlm_realm: Preparing to proxy authentication request to realm "TEST2" ++[slash] returns updated rlm_realm: Request already proxied. Ignoring. ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop Sending Access-Request of id 34 to 127.0.0.1 port 11812 User-Name = "default" Acct-Session-Id = "1261403531L18dgh" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "Localhost" NAS-Port = 0 Calling-Station-Id = "1115551212" User-Password = "password" Proxy-State = 0x3137 Proxying request 1 to home server 127.0.0.1 port 11812 Sending Access-Request of id 34 to 127.0.0.1 port 11812 User-Name = "default" Acct-Session-Id = "1261403531L18dgh" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "Localhost" NAS-Port = 0 Calling-Station-Id = "1115551212" User-Password = "password" Proxy-State = 0x3137 Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=34, length=104 User-Name = "default" Acct-Session-Id = "1261403531L18dgh" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "Localhost" NAS-Port = 0 Calling-Station-Id = "1115551212" User-Password = "password" Proxy-State = 0x3137 server test { +- entering group authorize expand: %{Stripped-User-Name} -> expand: %{User-Name} -> default expand: %{%{User-Name}:-DEFAULT} -> default expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> default rlm_sql (sql): sql_set_user escaped user --> 'default' rlm_sql (sql): Reserving sql socket id: 1 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'default' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'default' ORDER BY id rlm_sql (sql): User found in radcheck table expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'default' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radreply WHERE username = 'default' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'default' ORDER BY priority rlm_sql_mysql: query: SELECT groupname FROM radusergroup WHERE username = 'default' ORDER BY priority expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'shells' ORDER BY id rlm_sql_mysql: query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'shells' ORDER BY id rlm_sql (sql): User found in group shells expand: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'shells' ORDER BY id rlm_sql_mysql: query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'shells' ORDER BY id rlm_sql (sql): Released sql socket id: 1 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop rlm_pap: Normalizing MD5-Password from hex encoding ++[pap] returns updated rad_check_password: Found Auth-Type auth: type "PAP" +- entering group PAP rlm_pap: login attempt with password "password" rlm_pap: Using MD5 encryption. rlm_pap: User authenticated successfully ++[pap] returns ok Login OK: [default/password] (from client LocalHost port 0 cli 1115551212) +- entering group post-auth rlm_sql (sql): Processing sql_postauth expand: %{Stripped-User-Name} -> expand: %{User-Name} -> default expand: %{%{User-Name}:-DEFAULT} -> default expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> default rlm_sql (sql): sql_set_user escaped user --> 'default' expand: %{User-Password} -> password expand: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:52:11') expand: /var/log/freeradius/sqltrace.sql -> /var/log/freeradius/sqltrace.sql rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:52:11') rlm_sql (sql): Reserving sql socket id: 0 rlm_sql_mysql: query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'default', 'password', 'Access-Accept', '2009-12-21 13:52:11') rlm_sql (sql): Released sql socket id: 0 ++[sql] returns ok } # server test Sending Access-Accept of id 34 to 127.0.0.1 port 1814 Service-Type = NAS-Prompt-User Cisco-AVPair = "shell:priv-lvl=15" APC-Service-Type = Admin Proxy-State = 0x3137 Finished request 2. Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Accept packet from host 127.0.0.1 port 11812, id=34, length=67 Service-Type = NAS-Prompt-User Cisco-AVPair = "shell:priv-lvl=15" APC-Service-Type = Admin Proxy-State = 0x3137 +- entering group post-proxy rlm_eap: No pre-existing handler found ++[eap] returns noop +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop rlm_realm: Proxy reply, or no User-Name. Ignoring. ++[slash] returns noop rlm_realm: Proxy reply, or no User-Name. Ignoring. ++[suffix] returns noop ++[eap] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [TEST2/default/password] (from client desktop port 0 cli 1115551212) +- entering group post-auth ++[exec] returns noop Sending Access-Accept of id 17 to 192.168.183.20 port 2535 Service-Type = NAS-Prompt-User Cisco-AVPair = "shell:priv-lvl=15" APC-Service-Type = Admin Finished request 1. Going to the next request Waking up in 4.9 seconds. Cleaning up request 2 ID 34 with timestamp +172 Cleaning up request 1 ID 17 with timestamp +172 Ready to process requests.
Hi,
Not the default virtual server. The test virtual server The flow is client -> default virtual server acting as a proxy -> test virtual server If the test virtual server is configured as a remote radius server then things work great. If it's configured as a virtual server using the "virtual_server=name" then things break.
test virtual server not setting the options byt he looks of it... post-auth is called in that virtual server - so how should it be getting/setting that attribute? alan
I think we're getting too far into the detail and losing sight of the problem I was trying to report initially. I'd expect the only difference between the proxying to a remote server, and proxying to a virtual server to be efficency / ports used, not functionality, aka it's more efficnt to use virtual_server= rather than define a remote radius server, then have the virtual server listen on odd numbered ports on localhost. There seems to be a functionality difference when proxied to a virtual server. Tim Alan Buxey wrote:
Hi,
Not the default virtual server. The test virtual server The flow is client -> default virtual server acting as a proxy -> test virtual server If the test virtual server is configured as a remote radius server then things work great. If it's configured as a virtual server using the "virtual_server=name" then things break.
test virtual server not setting the options byt he looks of it... post-auth is called in that virtual server - so how should it be getting/setting that attribute?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I think we're getting too far into the detail and losing sight of the problem I was trying to report initially.
I'd expect the only difference between the proxying to a remote server, and proxying to a virtual server to be efficency / ports used, not functionality, aka it's more efficnt to use virtual_server= rather than define a remote radius server, then have the virtual server listen on odd numbered ports on localhost.
There seems to be a functionality difference when proxied to a virtual server.
well, looking from the log, your virtual_server doesnt appear to set any attribute in its post-auth stage. calling the right thing or SQL table? my initial thought was your attr_filter wasnt allowing that attribute through from the virtual_server (much like it would strip it out if the domain/realm wasnt allowed - check pre-proxy and post-proxy parts) alan
well, looking from the log, your virtual_server doesnt appear to set any attribute in its post-auth stage. calling the right thing or SQL table?
post-auth, yes, see the virtual server config below. Remember TEST1 and TEST2 are the same virtual server, just proxying to them via different methods. That's why I was getting confused, They behave differently if you proxy to them in different ways.
my initial thought was your attr_filter wasnt allowing that attribute through from the virtual_server (much like it would strip it out if the domain/realm wasnt allowed - check pre-proxy and post-proxy parts)
No attr filters. Ok I think we're getting somewhere with the pre- and post- proxy parts. When I tried having the sql methods in there I got the following (Note 2 starts in debug 1 for pre, 1 for post) Module: Checking pre-proxy {...} for more modules to load /etc/freeradius/sites-enabled/test[59]: "SQL" modules aren't allowed in 'pre-proxy' sections -- they have no such method. /etc/freeradius/sites-enabled/test[58]: Errors parsing pre-proxy section. Module: Checking post-proxy {...} for more modules to load /etc/freeradius/sites-enabled/test[62]: "SQL" modules aren't allowed in 'post-proxy' sections -- they have no such method. /etc/freeradius/sites-enabled/test[61]: Errors parsing post-proxy section. server test { listen { # ipaddr = * ipaddr = 127.0.0.1 port = 11812 type = auth } listen { # ipaddr = * ipaddr = 127.0.0.1 port = 11813 type = acct } authorize { # preprocess sql expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type MD5 { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix eap } preacct { preprocess acct_unique files } accounting { detail unix radutmp } session { radutmp # See "Simultaneous Use Checking Queries" in sql.conf # sql } post-auth { sql } pre-proxy { # sql } post-proxy { # sql # attr_rewrite eap } }
post-auth, yes, see the virtual server config below. Remember TEST1 and TEST2 are the same virtual server, just proxying to them via different methods. That's why I was getting confused, They behave differently if you proxy to them in different ways.
my initial thought was your attr_filter wasnt allowing that attribute through from the virtual_server (much like it would strip it out if the domain/realm wasnt allowed - check pre-proxy and post-proxy parts)
No attr filters. Ok I think we're getting somewhere with the pre- and post- proxy parts.
When I tried having the sql methods in there I got the following (Note 2 starts in debug 1 for pre, 1 for post)
Module: Checking pre-proxy {...} for more modules to load /etc/freeradius/sites-enabled/test[59]: "SQL" modules aren't allowed in 'pre-proxy' sections -- they have no such method. /etc/freeradius/sites-enabled/test[58]: Errors parsing pre-proxy section.
Use sql.authorize instead. Ivan Kalik
I think we're getting too far into the detail and losing sight of the problem I was trying to report initially. I'd expect the only difference between the proxying to a remote server, and proxying to a virtual server to be efficency / ports used, not functionality, aka it's more efficnt to use virtual_server= rather than define a remote radius server, then have the virtual server listen on odd numbered ports on localhost. There seems to be a functionality difference when proxied to a virtual server. Tim 2009/12/21 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>:
Hi,
Not the default virtual server. The test virtual server The flow is client -> default virtual server acting as a proxy -> test virtual server If the test virtual server is configured as a remote radius server then things work great. If it's configured as a virtual server using the "virtual_server=name" then things break.
test virtual server not setting the options byt he looks of it... post-auth is called in that virtual server - so how should it be getting/setting that attribute?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan Buxey -
Timothy -
tnt@kalik.net