EAP-PEAP - windows client password change

[Kacper Wirski]

Hello,

I have environment with Freeradius 3.0.17 and samba 4.8 AD DC
authenticating windows 10 clients over LAN with EAP-PEAP.

To start off, I know that ntlm_auth is used ant that is just a tool used
by freeradius, so if my issue has nothing to do with freeradius, do say
so, I'll ask around samba mailing list.

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.

A scenario is this:

- user has expired password (either because it "just" expired, or
because user forgot password, and it was reset with "user must change at
next logon")

- user enters enters expired password

- user is allowed to change password (user prompt to enter new password)
and then:

a) if user enters and re-enters new password, all is fine, password is
changed (hurray!)

b) if user enters mismatched passwords, all works as intended (error
prompts: entered password do not match, user gets another chance) (great!)

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: Doing MS-CHAPv2 password change via ntlm_auth helper
(24) mschap: EXPAND username: %{mschap:User-Name}
(24) mschap:    --> username: some-username
(24) mschap: EXPAND nt-domain: somedomain
(24) mschap:    --> nt-domain: somedomain
(24) mschap: ntlm_auth said: Password-Change: No Password-Change-Error:
The transport connection is now disconnected. . .
(24) mschap: ERROR: ntlm auth password change failed:
Password-Change-Error: The transport connection is now disconnected.
(24) mschap: ERROR: Password change failed
(24)     [mschap] = reject
(24)   } # authenticate = reject
(24) MSCHAP-Error: 3E=709 R=0 M=Password change failed
(24) Could not parse new challenge from MS-CHAP-Error: 2
(24) ERROR: MSCHAP Failure

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).

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.


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?

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".

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.

I will be thankful for some input, wether it's something that can be
fixed/worked around or just something that I'll have to live with.


Regards,

Kacper


-
List info/subscribe/unsubscribe? See http://www.freerad

[Alan DeKok]

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. :(

...
(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.


-
List info/subscribe/unsubscribe?