InnerAttributes not escaped when transmitted to outter
Hey all, I'm using PEAP/Mschapv2 with Windows machines. I need the user-name of the inner-tunnel when the authentication ends to assign the vlan id. So I put in eap.conf / peap { ... use_tunneled_reply = yes ... }, and now I can have the User-name of the inner-tunnel with %{reply:User-Name}. But it seems it has not been escaped... My User-Name "DOMAIN/testx" becomes => "DOMAIN estxx" And if I try DOMAIN/user it works nicely... ++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{request:User-Name} -> ANKAMA\testx expand: %{reply:User-Name} -> ANKAMA estxx How can I escape this ? Regards, Frad G.
Stun Box wrote:
I'm using PEAP/Mschapv2 with Windows machines. I need the user-name of the inner-tunnel when the authentication ends to assign the vlan id. ... But it seems it has not been escaped... My User-Name "DOMAIN/testx" becomes => "DOMAIN estxx" And if I try DOMAIN/user it works nicely...
++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{request:User-Name} -> ANKAMA\testx expand: %{reply:User-Name} -> ANKAMA estxx
How can I escape this ?
You should be able to set it by hand from the inner tunnel: update outer.reply { User-Name = "%{User-Name}" } I'll take a look to see if there's anything in the EAP module that could affect this. Alan DeKok.
2009/6/2 Alan DeKok <aland@deployingradius.com>:
Stun Box wrote:
I'm using PEAP/Mschapv2 with Windows machines. I need the user-name of the inner-tunnel when the authentication ends to assign the vlan id. ... But it seems it has not been escaped... My User-Name "DOMAIN/testx" becomes => "DOMAIN estxx" And if I try DOMAIN/user it works nicely...
++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{request:User-Name} -> ANKAMA\testx expand: %{reply:User-Name} -> ANKAMA estxx
How can I escape this ?
You should be able to set it by hand from the inner tunnel:
update outer.reply { User-Name = "%{User-Name}" }
It does not work for me. The only way I succeed to get the innertunnel user-name is by setting the eap.conf / peap / use_tunneled_reply to yes. It does the same weird result with "DOMAIN\nuser" => DOMAIN nuserr Could the matter come from my configuration ?
I'll take a look to see if there's anything in the EAP module that could affect this.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stun Box wrote:
2009/6/2 Alan DeKok <aland@deployingradius.com>:
Stun Box wrote:
I'm using PEAP/Mschapv2 with Windows machines. I need the user-name of the inner-tunnel when the authentication ends to assign the vlan id. ... But it seems it has not been escaped... My User-Name "DOMAIN/testx" becomes => "DOMAIN estxx" And if I try DOMAIN/user it works nicely...
++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{request:User-Name} -> ANKAMA\testx expand: %{reply:User-Name} -> ANKAMA estxx
How can I escape this ? You should be able to set it by hand from the inner tunnel:
update outer.reply { User-Name = "%{User-Name}" }
It does not work for me. The only way I succeed to get the innertunnel user-name is by setting the eap.conf / peap / use_tunneled_reply to yes. It does the same weird result with "DOMAIN\nuser" => DOMAIN nuserr
Could the matter come from my configuration ?
Alan committed a fix to the git repository last night. It does a straight copy of the value without parsing it, so should fix the issues you've been seeing. See http://git.freeradius.org/ for instructions on how to retrieve code from the git repository. Regards, Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkok3FwACgkQcaklux5oVKIfUACdGZ+63/oxgPw/iN5tmBwNiR6x yEIAliN7tJ2z7HXI9uN1zsXbFBWQPi0= =PBVU -----END PGP SIGNATURE-----
ok, thank you for the news. Regards, 2009/6/2 Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stun Box wrote:
2009/6/2 Alan DeKok <aland@deployingradius.com>:
Stun Box wrote:
I'm using PEAP/Mschapv2 with Windows machines. I need the user-name of the inner-tunnel when the authentication ends to assign the vlan id. ... But it seems it has not been escaped... My User-Name "DOMAIN/testx" becomes => "DOMAIN estxx" And if I try DOMAIN/user it works nicely...
++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{request:User-Name} -> ANKAMA\testx expand: %{reply:User-Name} -> ANKAMA estxx
How can I escape this ? You should be able to set it by hand from the inner tunnel:
update outer.reply { User-Name = "%{User-Name}" }
It does not work for me. The only way I succeed to get the innertunnel user-name is by setting the eap.conf / peap / use_tunneled_reply to yes. It does the same weird result with "DOMAIN\nuser" => DOMAIN nuserr
Could the matter come from my configuration ?
Alan committed a fix to the git repository last night. It does a straight copy of the value without parsing it, so should fix the issues you've been seeing.
See http://git.freeradius.org/ for instructions on how to retrieve code from the git repository.
Regards, Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEUEARECAAYFAkok3FwACgkQcaklux5oVKIfUACdGZ+63/oxgPw/iN5tmBwNiR6x yEIAliN7tJ2z7HXI9uN1zsXbFBWQPi0= =PBVU -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Alan committed a fix to the git repository last night. It does a straight copy of the value without parsing it, so should fix the issues you've been seeing.
does this fix mean that TTLS and PEAP get the inner identity copied correctly so there is no more need for update outer.reply { User-Name = "%{User-Name}" } shenanigans in the inner-tunnel EAP? alan
A.L.M.Buxey@lboro.ac.uk wrote:
does this fix mean that TTLS and PEAP get the inner identity copied correctly so there is no more need for
update outer.reply { User-Name = "%{User-Name}" }
That's still needed. The question is what do you want the server to do. Always over-ride the outer name with the inner one? If so, why is the outer one "anonymous", and the inner one "user@realm"? i.e. "anonymous" is being used to hide the inner name... which promptly gets exposed with that rule. Is this a good idea? What else could be done to be secure, but also useful? Alan DeKok.
I set in copy_tunnel_reply to yes and I use the inner-tunnel user-name in my default / post-auth. And I still have the real user-name hidden. In default / post-auth : update reply{ User-Name := "%{request:User-Name}" Tunnel-Medium-Type = 6 Tunnel-Type = 13 Tunnel-Private-Group-Id = `/usr/local/etc/raddb/getVlan %{reply:User-Name}` } It will now work nicely with your fix. Thanks 2009/6/2 Alan DeKok <aland@deployingradius.com>:
A.L.M.Buxey@lboro.ac.uk wrote:
does this fix mean that TTLS and PEAP get the inner identity copied correctly so there is no more need for
update outer.reply { User-Name = "%{User-Name}" }
That's still needed. The question is what do you want the server to do. Always over-ride the outer name with the inner one? If so, why is the outer one "anonymous", and the inner one "user@realm"?
i.e. "anonymous" is being used to hide the inner name... which promptly gets exposed with that rule. Is this a good idea?
What else could be done to be secure, but also useful?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 2/6/09 10:01, Alan DeKok wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
does this fix mean that TTLS and PEAP get the inner identity copied correctly so there is no more need for
update outer.reply { User-Name = "%{User-Name}" }
That's still needed. The question is what do you want the server to do. Always over-ride the outer name with the inner one? If so, why is the outer one "anonymous", and the inner one "user@realm"?
I agree. Doing this by policy is a better idea than hardcoding behavior. We just need the policy to work correctly. Currently attributes in outer.reply are not inserted if: 1) You're doing EAP-TTLS-MSCHAPv2 2) The inner sever issued a reject These two cases need to be fixed for predictable behaviour. Did you get a chance to look at that patch I sent ? Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Arran Cudbard-Bell wrote:
Currently attributes in outer.reply are not inserted if:
1) You're doing EAP-TTLS-MSCHAPv2
I set "use_tunneled_reply = yes", and I get the reply attributes copied from the inner tunnel to the outer tunnel. And if I do "update outer.reply" with an attribute, it works for me with EAP-TTLS-MSCHAPv2.
2) The inner sever issued a reject
Yes... that may be easy to fix. See ttls.c, look for 'case PW_AUTHENTICATION_REJECT:'. And copy the lines above 'if (t->use_tunneled_reply)...' to that 'case' statement. That should work...
These two cases need to be fixed for predictable behaviour.
Did you get a chance to look at that patch I sent ?
Later today. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Stun Box