Keychain with AD user's

Where are the users changing their passwords? On the Mac? If they do so, the login.keychain password will be sync'd automatically (default setting, can be turned off).

If the password is changed or reset elsewhere, then you will run into the issues that you've described... which is why we recommend password changing on the Mac.

They get the alert on the mac password is going to expire and they change it. But I think they ignore the part where it asks you after that to create new keychain, update keychain or continue to log in, and they hit continue to log in and they run into the problems after that.

If they are able to change it on the Mac and have it take, the keychain password should be updated transparently.

If they are seeing that horrendous dialog at login (couldn't unlock your keychain, what do you want to do?), either the password isn't getting changed in AD, or someone has changed off the default keychain password sync'ing behavior.

https://jamfnation.jamfsoftware.com/discussion.html?id=7783#responseChild41294 has the commands to change this setting (can read what the setting is by substituting defaults read for defaults write, and leaving off the value at the end of the command).

This is a persistent problem in our environment since users must change their password on an intranet site and cannot do it on the Mac.

Step 0 is to try to educate users on the implications and provide good walkthrough/guide documentation on updating their keychain after an AD password change.

Of course that rarely works.

I wrote a "Keychain Repair" utility to recreate their login keychain interactively. It's a nuclear approach but it works great in my shop. Users know where to go and click a button to fix their problem instead of stumbling through a guide, and our tier 1 staff can point them to the utility quickly. Plus, if they've forgotten their previous password they're effectively locked out and can't update the keychain, so recreating it is the only option.

Check out https://github.com/haircut/osx-keychain-repair - it's a script and small app that's resulted from my best attempts to ease this pain point.

There are a few prongs to this fork. You need cocoaDialog on the user's system for a makeshift GUI. I use it for lots of interactions so it gets installed at imaging. The script will also attempt to auto-heal if cocoaDialog is not found, so you need to create a policy to install it (instructions in repo).

Secondly is a small app created with Automator called QuitAllApps.app. It...quits all open applications and prompts the user to save open work in each application, but leaves Self Service running. Works nicely. It's another thing I toss on during imaging because it's useful to call before maintenance policies in Self Service. Again, the script will attempt to auto-heal if it's not installed, so you need a policy to take care of that.

Finally the script backs up their keychain, deletes it, recreates it with their current AD password, then reboots the computer. It also kills the Local Items keychain.

In total, you need to customize the script and install both cocoaDialog and QuitAllApps to a known location. You also need 1) a policy to auto-heal cocoaDialog, 2) a policy to auto-heal QuitAllApps, and 3) the actual user-facing "Keychain Repair" policy in Self Service.

This solves a huge portion of keychain problems in my environment.

@bmwarren - Your process sounds pretty good. I may take a look on implementing it in our environment. As with many here, login.keychain and password issues remain a near constant issue in our environment as well.

I wanted to mention that I have several applications I've created using Platypus that use an embedded version of cocoaDialog for the GUI elements, meaning that the .app bundle becomes self contained and the script will always know where to call cocoaDialog from. If you're interested in some code on how to do that, let me know or email me at mm2270 [at] me [dot] com and I can send it to you.
Its great for those scripts that work well when wrapped up to run as individual little apps, but there is always the concern about whether or not cD is installed on the system or if its even the right version.

Hi All,

ADPassMon is meant to deal with this, so not sure what issues you've seen @EliasG & was unsure what you meant by the message you emailed me via [macmule.com](macmule.com).

My fork of ADPassMon can be found at: https://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/ I'm going to be working on it some over the next few weeks & may finally try & commit it to main or separate it some.

@bmwarren & @mm2270 my fork can alert a user of pending expiry, then prompt them to go to an external site to change the password. Once I have resolved the open issue from @golbiga (https://github.com/macmule/ADPassMon/issues/3) it'll work as expected.

If it's not meeting what you need, let me know. I'd rather have one solution that could work for many than many solutions that work for few.

Hi

I'm using ADPassMon with our Staff but we had to "educate" them on any error messages.
At the "system was unable to unlock your keychain.." error they need to click "Continue Log In"

Once they've logged in ADPassMon will open and prompt them to change/update the keychain.

I've thought about just deleting the contents of the Keychain folder at logout but this seems alittle harsh.

We always have had users change AD passwords via outlook web access and never had had the issues we have had with 10.9.4 and keychains (though for whatever reason, I am never able to reproduce it, but we see it all the time).

Apple has said issue is corrected in 10.10... Anyone seen keychain issue improvements with 10.10? We won't roll out 10.10 until summer.