"You must enter a new password before you can log in to the account."

[ianmb]

Has anyone seen this message on a Mac bound to AD? Some of our student users get prompts to reset the password. It seems to happen when a user tries to log on to the computer for the first time. For other students, they are able to log in just fine. I can't see anything in our AD to suggest that the problem accounts are any different.

The affected machines are configured with mobile accounts and are running macOS Sierra v10.12.6.

NB. Longer term we plan to migrate to NoMAD, but for now we're stuck with binding to AD.

[sshort]

Yeah, that can happen during a one-off password reset directly in AD (or an AD policy) is set to "user must change password at next login" I don't know the exact GPO, but that can also be enabled for any user logging in to their AD-account on any machine for the first time.

It's also possible that a config profile has a conflicting local password policy that's forcing the account pw to be reset.

[ianmb]

@sshort I've double checked that the affected users don't have that option set, which is why I'm puzzled. We don't do anything in config profiles (or anywhere) to set local password policies - we just go with whatever is in AD.

[seanhansell]

Yea, this is definitely coming from AD. Jamf is not doing this.

[a_simmons]

Has the user logged into the device previously and the local account now has an expired password?

[ICTMuttenz]

Hey

We had a similar problem with the teachee. A quick Solutions is to set „Password never expires“ and then check the default group policy in your ad. By us was the problem in a default GPO which was scope on all teacher.

Best regards

[ianmb]

@a.simmons No; these are mobile AD accounts, not local accounts. There's a long-term plan to use NoMAD, but we're a bit of a way off that at the moment.

[ianmb]

I think I've narrowed this down to the badPasswordTime attribute in AD. If that is populated, and I presume the system is hitting the same DC (AIUI badPasswordTime is a non-replicated attribute), then the student cannot log in. The students that can successfully log in without a prompt to reset have a value of <never> on that attribute. The badPwdCount attribute is possibly also affecting things.

Can anyone shed any more light?

[ianmb]

Forget what I said; the population of the badPasswordTime attribute seems to be a red herring, as I've just managed to log in successfully with a test account that has a value populated across all of our DCs.