Active Directory Password Caching

We basically do what you do: encourage users to change passwords through System Preferences on the LAN on premises whenever possible on their Mac. A great scare tactic is warning them about all the keychain prompt nonsense they'll get if they change it anywhere else.

I'm not sure if there is a better way to handle it other than user awareness and education. Maybe throw some clear documentation somewhere that all users have access to if you have a central information portal/internal web presence.

Agreed with @emilykausalik. I understand that some of your clients may not like the answer, but there is no magic here. If they change their password on a PC or it gets changed in AD, when they next go to use their Mac its going to have an out of sync password and things will generally be miserable for them until it gets fixed. If they have the privilege of having both a PC and Mac to use (I'm serious; where I am you get one computer to use, PC or Mac, unless you are a VIP or in IT and get special consideration), they need to just change their password on their Mac if they don't want to experience problems.

As a slight aside, we have an internal password change website that we encourage users to use when changing their password. The site is designed to make certain the change gets fed out to every DC in the domain, and down to every device using that account in a matter of moments, so its the best experience for this process. Something like that is ideal because it can be done from any machine. But of course something like that needs to be set up first.

We have the same challenge at one company. Rather than them learning to do it on the Mac, they chose to allow a never-expiring passphrase. While I think it's a bit of a cop-out, it has cut the calls down to almost none.
Mostly this was done to appease the exec's using Macs - many of the others were able to adjust...

That sounds nice, though because of compliance reasons we have to enforce 90 day password changes.

We've tried to inform users as best as possible a number of ways:
- Guide to changing passwords through ADPassMon
- Guide to changing passwords through our VPN tunnel
- Guide to changing passwords through System Preferences
- Guide to troubleshooting the local items prompt after a password change
- User awareness of password policies in new hire orientation

We've found that providing centrally-accessible documentation on the above has cut down on tickets substantially. We also have a #helpdesk channel on our work Slack where people can ask questions, and we've pinned some FAQs that folks can reference quickly.

@scottb

they chose to allow a never-expiring passphrase.

So... they chose to compromise the security of the entire org to appease a few overpaid execs that can't figure out how to click a button and change their password? Sounds reasonable.

EDIT: To be clear, I'm not saying its anything you are doing wrong or even a decision you would have made. It just makes me SMH sometimes at what some companies do to get around an issue instead of actually trying to educate users.

@mm2270 Indeed. It's the way things seem to work, isn't it? You'd think that after SONY, they'd have a change of mindset, but indeed, in some ways, they've gone the other direction. As soon as their assets and emails end up on the internets, they'll look to blame everyone except those that make such decisions...it's called appeasing the higher-ups, or *-kissing.

I am interested in this too. Currently rule of thumb in my organization is if you have both Mac and Windows then the user must change their network credentials from their Mac while on the internal network. Our users seem to be okay with those conditions.

At the university where I work we also have a web-based tool for changing passwords since we allow the
same student to log into windows, linux, or mac OSX. We tell the students to wait a few minutes to log in
again.

Thanks for all the info, good to hear that i'm not alone with the issue.

We are soon implementing a web portal password reset system, but my thoughts were that the same thing would happen even if you change the password through this web portal? The mac would keep using the cached creds?

@kyle302 yep. Whilst the Mac might update the clients password from AD, the users login keychain & local items will still be using the old.

Some of the functions of ADPassMon prompts for expiry, but only allowing changing via a web portal. Then at login check to see if the keychain is locked (as it is when AD password is not the same as local). Then prompt to update/reset.

There is no simple way around it, due to Macs being in a Windows environment.. From my experience, if the Mac is on the domain, they should be changing the passwords via the Mac at the login window. Pretty sure they get a message stating their password will expire in so/so days.. Once changed, they should select the option to update the login keychain, in which they will put in their previous password to do so..

As far as the local keychain that doesn't get changed. You can just go into LibraryPreferenceKeychains.. and delete that folder named with a "plethora of letters/numbers", restart immediately, that will remove their old local keychain, and start using the current password.. No more pop up prompts to put in their local keychain after a network password change.

If you're using desktop Macs you can reduce the pain by not creating mobile accounts. Each login window authentication will then be against a domain controller rather than a cached dslocal copy so will use the new password.

Keychain a are still a pain though, even in this case.

If it's laptop users then of course mobile accounts are unavoidable but you should still make sure the domain controllers are reachable from the login window where possible to help reduce issues.