On Nov 13, 2018, at 4:44 AM, Kacper Wirski <kacper.wirski@gmail.com> wrote:
I did configure freeradius to allow expired password changes (in mschap and eap modules), but what I did not realize is that there is an exception, where password change goes wrong.
That situation could be handled better by the Windows system. :(
and now the (in my opinion) incorrect behaviour c):
user enters and re-enters new password during change that does not comply with domain password complexity policy (too short, not complex, or repetitive). In this scenario freeradius debug shows error like this: ... (24) mschap: ntlm_auth said: Password-Change: No Password-Change-Error: The transport connection is now disconnected. . .
Which isn't very useful.
At this point 802.1x authentication ends, windows starts another authentication session for windows-host (and succeeds), BUT on the other hand user still sees password change prompt, just "ordinary", not the one that is related to 802.1x and with correct error reason (password does not comply with domain password policy).
That's good, I guess.
What happens next is this: IF user still tries to change their password they might succeed, windows will start another 802.1x session and this time with already changed password 802.1x login will just work. But it's not always the case and overall it seems wrong. Sometimes user gets in a "password change loop", that is: prompt to change password, doesn't matter what user will enter, another "your password has expired - change your password" screen will appear, with no real connection being sent. Overall it's really messy and confusing to users.
Blame Windows, unfortunately.
I'm not sure if it's more samba related (since it's ntlm_auth that's being used) or freeradius and just different error handling?
It's the end users system, i.e. Windows. There's not a lot that FreeRADIUS can do here. It's largely just passing data back and forth between the Windows client, and the Windows AD server.
Correct behaviour in my opinion for c) would be similar to scenario b), that is - without breaking 802.1x authentication session, give user another chance to change password with proper information (that password does not comply with domain policy settings), instead of just "failure".
I'm not sure that's possible. Microsoft (in their less than infinite wisdom) hasn't made good allowances for *repeated* password changes. i.e. "that change didn't work, here's a useful error, try another" And again, FreeRAIDUS is just a pass-through system here.
Unfortunately I don't have access to pure windows environment with windows NPS and windows DC to see, how this scenario is handled there as comparison.
I can get more information (full debug, configuration etc.), when/if needed.
That's probably not useful here, unfortunately. The protocols *should* be designed to account for this situation. It looks like they're not. Alan DeKok.