Hi We are using dynamic VLAN assignment with freeradius 2.1.6 and tried to test session resumption. It looks like that freeradius doesn't cache all reply attributes and upon session resumption the VLAN assignment attributes don't get send. Is there any way to cache these attributes? The attributes are generated by rlm_perl in post-auth section of inner-tunnel virtual server
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anatoli Logvinski wrote:
Hi
We are using dynamic VLAN assignment with freeradius 2.1.6 and tried to test session resumption. It looks like that freeradius doesn't cache all reply attributes and upon session resumption the VLAN assignment attributes don't get send. Is there any way to cache these attributes? The attributes are generated by rlm_perl in post-auth section of inner-tunnel virtual server - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html No. You should be running through your authorisation policies on session resumption. All policies should be moved to the post-auth section of the outer server.
Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkoVCjwACgkQcaklux5oVKJvDwCYvPokdzA/pfBPJEJnfjaQLGSm 4gCfd17/hCU6qQUjoPu1yP+0hcSSV9Q= =p9OV -----END PGP SIGNATURE-----
Hi,
No. You should be running through your authorisation policies on session resumption. All policies should be moved to the post-auth section of the outer server.
but only the inner server knows the real id etc ?
Yes, so have it tell the outer server... Insert the (attached) snippet into the authorize section of the inner server. There's an issue where outer.reply items aren't merged with the reply when doing EAP-TTLS-MSCHAPv2. So you still have to have 'use_tunneled_reply' set to yes. I believe the User-Name attribute in outer.reply is cached, and available for use on session resumption. So just: Auth-Type EAP { eap if(ok && "%{reply:User-Name}"){ update request { User-Name := "%{reply:User-Name}" } } } Once you've got the policies moved to post-auth, then any scripts or lookups used for authorisation will only be run once, so far greater efficiency with complex policies. Rejects are still handled properly even within the Post-Auth section (jumps to Post-Auth-Type reject). Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
# # Workaround for EAP-TTLS MsCHAPv2, not adding outer.reply attributes # If we use both methods we get duplicate User-Name attributes. # if(("%{outer.request:EAP-Type}" == 'EAP-TTLS') && ("%{control:Auth-Type}" == 'MSCHAP')){ update reply { User-Name := "%{Stripped-User-Name}" } } else { update outer.reply { User-Name := "%{Stripped-User-Name}" } }
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arran Cudbard-Bell wrote: > Hi, >>> No. You should be running through your authorisation policies >>> on session resumption. All policies should be moved to the >>> post-auth section of the outer server. >>> >> but only the inner server knows the real id etc ? >> > Yes, so have it tell the outer server... Insert the (attached) > snippet into the authorize section of the inner server. * at the bottom of the authorize section of the inner server. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoVIFQACgkQcaklux5oVKK33wCfdq4CkOvX7PAGwhL56KSLcyTk 3qoAn2HcsVUpaFZpQJmhd4VB28eCdyRi =utZd -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
Yes, so have it tell the outer server... Insert the (attached) snippet into the authorize section of the inner server.
$ git format-patch ?
I believe the User-Name attribute in outer.reply is cached, and available for use on session resumption.
Yes.
Once you've got the policies moved to post-auth, then any scripts or lookups used for authorisation will only be run once, so far greater efficiency with complex policies. Rejects are still handled properly even within the Post-Auth section (jumps to Post-Auth-Type reject).
Documentation suggestions are always welcome. Alan DeKok.
On 21/5/09 15:05, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Yes, so have it tell the outer server... Insert the (attached) snippet into the authorize section of the inner server.
$ git format-patch
?
It's on my to do list. You may find things getting jiggled around to a more sane naming scheme though. :)
I believe the User-Name attribute in outer.reply is cached, and available for use on session resumption.
Yes.
Once you've got the policies moved to post-auth, then any scripts or lookups used for authorisation will only be run once, so far greater efficiency with complex policies. Rejects are still handled properly even within the Post-Auth section (jumps to Post-Auth-Type reject).
Documentation suggestions are always welcome.
That too. I think leading by example is a better option though. 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
Thanks a lot guys, it's working properly now Best regards Anatoli Arran Cudbard-Bell wrote:
Hi,
No. You should be running through your authorisation policies on session resumption. All policies should be moved to the post-auth section of the outer server.
but only the inner server knows the real id etc ?
Yes, so have it tell the outer server... Insert the (attached) snippet into the authorize section of the inner server.
There's an issue where outer.reply items aren't merged with the reply when doing EAP-TTLS-MSCHAPv2. So you still have to have 'use_tunneled_reply' set to yes.
I believe the User-Name attribute in outer.reply is cached, and available for use on session resumption. So just:
Auth-Type EAP { eap if(ok && "%{reply:User-Name}"){ update request { User-Name := "%{reply:User-Name}" } } }
Once you've got the policies moved to post-auth, then any scripts or lookups used for authorisation will only be run once, so far greater efficiency with complex policies. Rejects are still handled properly even within the Post-Auth section (jumps to Post-Auth-Type reject).
Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Anatoli Logvinski -
Arran Cudbard-Bell