On 07/18/2013 07:25 AM, Olivier Beytrison wrote:
Hello,
We're in the middle of migrating all of our radius server to FR3.
This is the opportunity to discuss a the difference of behaviour between EAP-TTLS/MSCHAPv2 and EPA-PEAP/MSCHAPv2 which is bothersome.
With EAP-TTLS/MSCHAPv2 we have the following flow
With EAP-PEAP/MSCHAPv2 the flow is somewhat different
FWIW I don't think either of those are complete or accurate. For starters, TTLS/MSCHAPv2 and TTLS/EAP-MSCHAPv2 are different, and PEAP/MSCHAP is *really* PEAP/EAP-MSCHAPv2. Comparing TTLS/MSCHAP and PEAP/EAP-MSCHAPv2 is comparing two different things, and of course they may behave differently.
This mean that with EAP-PEAP/MSCHAPv2, if the ldap/sql/xxx module in authorize{} add attributes to the reply, they will be sent during the last challenge/response in authenticate{}, and will not be present in post-auth or the final access-accept.
You're not being very precise here. authorize in the inner or outer tunnel?
On our side, we are doing the policying in the inner-tunnel post-auth section, based on values directly mapped from ldap attributes to our private dictionary through the ldap module called in authz{}
With EAP-TTLS we don't need to do anything special to make this work, but for PEAP actually we need to use the rlm_cache to cache and restore the attributes in post-auth.
Why don't you just set them in post-auth, and skip setting them in authorize completely? You can do this, remember: post-auth { ldap.authorize sql.authorize ... }
It would be really nice if eap would cache automatically all attributes present in the reply list if it has to do another round of challenge/response and restore them once the final access-accept (or reject) is reached.
I'm not sure about that. You definitely have to take care with reply attributes, but if you always set them in post-auth, you should always be safe. Setting them in authorize is only safe if you set them on *every pass* through authorize. You're not doing this, because you have: eap { ok = return } ldap sql In 3.0, the "ok = return" will match on EAP-identity packets for the inner tunnel but *also* EAP-MSCHAPv2 success/failure packets. So, the final pass through the tunnel will be skipped. This should be logged in the debug with a quite specific/verbose message, for exactly this reason: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... Maybe this is the issue you're facing?
Now this is a behaviour I always encountered in our configs (based on the default shipped config). Still it's possible that it is due to what've done. For this purpose you'll find the inner-tunnel config below [1].
# that's where we need the attributes added # by the ldap module in authz{} wireless-policy }
What does "wireless-policy" do, and where does it get its data from?