MSCHAP / NTLM_AUTH failure on "expired" AD password; out of sync cached creds / AD password.

[Garber, Neal]

> FR is configured to send the auth request to AD (MSCHAP 
> only, Aruba terminates PEAP) using NTLM_AUTH.  

Why do you want Aruba to terminate PEAP?

> If it IS expired, MSCHAP (or NTLM_AUTH) "seems" to always 
> return a reject.  

See below...

> Also, with new users an account is created with a 
> temp / one time password and their account is set to 
> "user must change password at first logon".  This 
> results in a similar failure - the supplicant never pops 
> a box prompting to CHANGE password, it just prompts 
> to reenter because of the failure - which is 
> obviously worthless. 

For now, this is working as designed because FR doesn't support password change via MSCHAP.  Recently, there was a thread talking about
supporting retry and Phil Mayers wrote and submitted a patch to
provide retry & password change for MSCHAP (thank you Phil:) ).  But, 
I'm not sure that code will make it into 2.1.11 because I haven't seen 
a lot of people posting "I tested it and it works fine" messages.  Of course, Alan would know for sure...

> I THOUGHT MSCHAPv2 can recognize a "password expired" state 
> and actually allow a user to change it via MSCHAPv2 functions.  

True, but see above.

> We have a similar failure when the laptops "cached credentials" 
> are out of sync with AD.  

This might be fixed with Phil's patch.  Feel free to test it
and report your findings..

Another option is to use machine authentication (assuming the
machines connecting are all members of your AD domain).  Then,
while the user is logged off, the machine logs on.  The user
logon then goes to the domain since it already has a network
connection.  That would eliminate the bad cached credentials issue
and the expired password issue.