AD password change/Keychain password update

[nextyoyoma]

I know this topic has been brought up many times, but I still have not found an ideal solution to our particular situation, so I wanted to get some input from you folks. I know it's not exactly a jamf issue but...

We do not allow our users to set their own passwords. The reason for this is that we have multiple services our teachers and students use and we manage, and some of these use LDAP while others require us to set the password for the user. To keep things consistent and avoid daily "I forgot my password" situations, we control the passwords for all users. I realize this is not ideal from a security standpoint, but it is necessary for our situation.

We change passwords for teachers once a year. As you all know, OS X displays a cryptic (to most users) dialog prompting them to update their keychain password after an AD password change. We do not want to panic our teachers, so right now we are thinking that we will try to communicate the steps they need to take when they all get back on campus, and then change the passwords the next day. Does anybody else have a similar situation and a better way to deal with it?

Some things we have tried:

KeychainMinder. The problem: I can't get it to come up before the system dialog. It only comes up after the original prompt, which doesn't help avert the aforementioned panic.

A script with a database of the username, old password, and new password to change the keychain password via the "security" command line tool. This seems to work sometimes, but at other times it seems to set the keychain password to something that is neither the old or new password, and ends up with a completely inaccessible keychain that has to be reset (deleted and replaced with a new empty keychain).

What I would like to see: Apple to release an API that would allow jamf to update the keychain password. I guess there might be security implications with this, but it would certainly be helpful for us.

[alexjdale]

I know this is not what you want to hear, but you really need to re-evaluate your processes. Passwords are only being changed once a year and are obviously stored somewhere in plaintext (or communicated in plaintext to users, who do not change them later). Multiple people have access to user passwords. This would fail any security audit, and if student records can be accessed through these mechanisms, you could be facing a breach that could release personal information.

This is a very bad scenario. But to answer your question, I would just train your users on how to handle the keychain update prompt, since I doubt you are able to properly secure password changes with your setup (database->scripts).

[rtrouton · Accepted solution]

You can turn this loginwindow keychain update option off. Here are the commands I used to disable for my own account:

To disable:

defaults write com.apple.keychainaccess SyncLoginPassword -bool false

To enable:

defaults write com.apple.keychainaccess SyncLoginPassword -bool true

This is a per-user setting and is stored in /Users/username/Library/Preferences/com.apple.keychainaccess.plist

You should also be able to control this setting with MCX.

For more information on this setting, see this post:

http://www.jaharmi.com/2009/08/29/sync_the_keychain_passphrase_with_the_login_account_password_in_sn...

[mm2270]

Besides the posted suggestions and remarks, I think a big issue here is that the passwords only change once a year. Given this, you can't expect the teachers to even remember what they need to do when the Apple keychain dialog comes up. Who would recall what the procedure is if they only saw it 12 months ago? Some of them may even be new staff who have never seen it. Like alexjdale said, you really should consider changing this entire process. If you really must keep it the way it is with IT changing the passwords for them, then at least consider doing it more frequently. That will help a little on the security side and also get users used to how to update their login keychain password.

[RobertHammen]

Don't change the passwords in AD, change them on the Mac. Either have your IT staff do this, or let them set/change the password and make the password expire once a year...

[nextyoyoma]

Thanks, all. Like I said, I understand the situation is not ideal, but I'm sure you all know that processes evolve out of the needs you have, and trying to rubber-stamp a new process onto an existing system is not something we can afford to do right now. I looked at the practicals of changing the system recently, and I'm pretty sure we would have a revolt on our hands if we tried to do it right now.

We will probably try rtrouton's suggestion for now. That will allow us to use keychain minder to have them reset their passwords.

[FritzsCorner]

I know this is an old thread but I thought I would add my experience using keychain minder. While we don't have the same password change process as nextyoyoma, our Mac users utilize many other platforms including Windows systems, Citrix systems, and other remote systems; so they could change their password anywhere.

I used rtrouton's suggestion and disabled the password sync to disable the default keychain prompt from popping up in Mavericks during logon. While this works, and the keychain minder app does pop up after logging on, other services that use the keychain such as a wireless connection will pop up in front of the Keychain minder window asking for the password. This is really not that ideal and would cause further confusion.

I actually have no issues with the default keychain password change prompt in mavericks other than it isn't very clear what it is for to a non-technical user. I wish there was some way I could just alter the text of the default keychain prompt that apple provides.

We have decided to stick with the default apple notification for now. We will try and communicate the process to the end users and support staff as best we can for the time being until a better solution becomes available.

[cgiordano]

Hi All,

I know that this is a SUPER old thread but wanted to throw out a suggestion we'll be implementing once we roll out Self Service to our users. Now, mind you, this is a bit of a "shotgun" approach but you could do the following by using Self Service:

Create the following script in your JSS or upload it the script through Casper Admin:

#!/bin/bash

# JAMF Help Variables
jamfHelper='/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper'

## Parameters 1 through 3 are predefined as mount point, computer name, and username
cd /Users/$3/Library/Keychains/
rm -Rf *

## Message Contents Variables
title="Tech Support Alert"
heading="Please reboot!"
description="In order for finalize the fix for your keychains you computer will need to reboot.  You computer will reboot 60 seconds from when you click OK"
button1="OK"

###########################################################################

## Let's get this show on the road, RUN THAT SCRIPT!

"${jamfHelper}" -windowType utility 
-title "$title" 
-heading "$heading" 
-description "$description" 
-button1 "$button1" 
-defaultButton 1

## The sleep command shouldn't run until AFTER the OK button has been clicked
sleep 60

shutdown -r now

Note: I've not tested this but the script should go something like that

Once your script is in the JSS you can then create a policy to make available in Self Service so the user can simply click the on the button, delete their keychains and reboot the computer to let the user's login keychains recreate.

Like I said, I know that this is super old but figured it might help someone if they are looking for help on this issue as well.

Chris

[rhysforrester]

Disclaimer: everything we support is bound to active directory, managed-mobile accounts-admin rights, password changes every 90 days, we've got about ~1500 Macs managed by our JSSes and another ~500 odd running amok in the wild.

I'm honestly in disbelief at how many people fight against keychains rather than trying to tame them - in our organization and outside.

It absolutely isn't clear to a non-technical person when you're being prompted - but we try very hard to train clients and support staff to focus on the difference between a "current access password" and a "current login keychain". The single best document for doing this is; https://support.apple.com/en-au/HT201609

I've never had an issue with keychains synchronizing (9+ years and counting) - even when i've been using my laptop off the network with a recent password change, as designed, the next time it talks to our AD server i'm prompted to enter my current login keychain password so that it can be updated/synchronized with my account access password.

Up until literally yesterday the troubleshooting process somewhere in our organization involved...anything keychain related...delete it and start again. I've narrowed this information down to a single mis-informed support staff member...everyone else is being instructed to only ever delete keychains if the user has completely forgotten their password - otherwise you synchronize them, and worst case, delete an offending keychain entry if an old password is set somewhere that's causing an account to be locked after 'x' many incorrect attempts.

As always, your mileage may vary in your environment - happy wrangling.