How does your environment deal with Keychains?

[Ricky]

We are currently in an environment with an ActiveDirectory backend, as part of a network that was once primarily a Windows atmosphere. We have an interesting divide, being part of a school district—the majority of teachers use MacBooks, while district administrators (including those in business) are all on HP all-in-ones. This configuration makes it very difficult to take and remove the ActiveDirectory backbone, and that is not something that is currently desired.

That being said, how do those in a similar situation deal with Keychains? This is the process for when a user changes their password:
1) It's been 60 days since their last password update
2) The server prompts users for a new password, which they comply with
3) When logging in, the mac works as normal... until there are close to one million popups that show up saying that an individual can't log into "Local Items" and "login."

We were first prompted with this issue over the summer, more than six months ago. Our solution was just to delete the old keychain and force the computer to restart to generate a new one. Okay, this works but isn't ideal. Those who change their passwords lose all of their web cookies (something they aren't usually expecting), and we often have issues with Microsoft Office. Outlook references the keychain to enter a password every time a user logs in; when they log in it does not save it to the keychain as the file it is looking to reference no longer exists. Outlook will log in, but simply won't save the password and will continue to prompt the user every time they open the application.

We are looking to encrypt all hard drives in the near future, but this can't be done until we no longer need to delete the Keychain.

With this being said, what is the best way to manage Keychains?

[mm2270]

This is an old old problem that few Mac admins out there haven't needed to deal with. The main issue is that Apple's implementation of the keychain is kind of broken. Too often the keychain password is not updated in sync when a client changes their password on their Mac, through Users & Groups for example. Its far worse when the password is changed through some other means outside of on the Mac directly. So yes, we see this issue too. The problem is we often don't see it unless the user reboots or logs out/in after changing their password. At that point they get all the prompts that just keep coming up and coming up, seemingly endlessly. Since the keychain is already unlocked when the Mac is on, logged in and in use, there is no prompt about not being able to access keychain entries. Not until they do a reboot or logout. Since that can often be days or even weeks after the password change, more than likely the user has now forgotten their old password and you have no choice but to blow away the keychain. As you said, less than ideal. This gets especially ugly if important certificates are being installed into the user's keychain. They lose those certs as well and need to re-obtain them.

Then there's the ever annoying Local Items Keychain. Don't even get me started on that one.

There are some 3rd party tools that can help with this a little, but I have to be honest, there is no full on magic bullet for keychain issues. You can look at @bentoms's ADPassMon fork for example, which helps alert users to problems with their keychain, although I'm not sure if it alerts during regular login sessions or only at login. I think it will when the screen is locked and then unlocked though.
And there may be additional tools to help with this.

[stevewood]

I handle the problem here through written policy/instruction and education of the end users. We utilize a web site to change our AD passwords, so every time a user changes their AD password their Keychain is broken. The process that is documented for end users, and works very well as long as they remember their Keychain password (can't tell you how many do not) is this:

• User changes password on web site
• User opens Keychain Access and utilizes the Change Password menu item to update Keychain password

That works 100% of the time. Yeah, it takes a few minutes to complete, but every time they follow that procedure, they have no problems.

I'm with @mm2270 though, it's a broken technology that needs to be fixed at some point. They need to provide some method for updating passwords outside of Users & Groups.

[AVmcclint]

Are your users setup as Mobile Users or are they purely local accounts? Our Mobile Users' accounts are created with Active Directory credentials the first time they login on the computer. When it comes time for the user to change their password (BEFORE it completely expires) I tell users to change it in System Preferences > Users & groups. After the password is changed, wait 30-60 seconds to make sure everything syncs up (Keychain, FileVault2, and various network resources) and then restart the computer. As long as users wait that little bit of time and restart, they never have problems with keychains getting out of whack.

Times we are guaranteed to have keychain problems:
1. the user waited until after the password expired in AD
2. they don't restart their computer at all after changing the password
3. they restart the computer too quickly after changing the password
4. the password is changed in a location outside of the computer (on a different computer or directly via Active Directory Users & Computers)

[Ricky]

@AVmcclint Users are set up as Mobile Users—anyone can log into any computer. I appreciate your response; the majority of our users change their passwords online (we use RapidIdentity Single Sign On). The website will prompt them when they login to do attendance / grade books a week before their password actually expires.

@mm2270 It's nice to see that this isn't something we are doing wrong. I will check out the ADPassMon information you linked me to. Have you ever looked into integrating AD and OD? Not sure if it's possible, but it doesn't sound like a fun process.

[apizz]

@Ricky we have documentation written on this for those folks that reset their password (machines bound to AD) , but of course no one really reads it. We've had issues when users choose the "Update My Keychain" option where they are continually prompted for their old password at first login on every machine they've logged into, so we go with the "Create New Keychain" option.

We also have a "Fix My Keychain" Self Service policy which everyone has access to which basically just delete's the logged in user's folder in their ~/Library/Keychains folder and reboots the machine.

We're looking to implement ADPassMont for next year, which IIRC allows you to display custom messages to update the Keychain password when the account pass does not unlock the account's Keychain at login.

[ItsMe_Sean]

A solution we came up with here, is one of our techs wrote up an application which we deployed via the JSS.

The app pretty much did all of this for us;

Asks the user for their old password so it can access the keychains etc
Asks for a new password that meets the AD security policy and confirms
Once password has met the minimum criteria, it then gets sent back to the AD servers and set as the new password
The app then changes the keychain password and reboots the Mac.

[Aaron]

A solution we came up with here, is one of our techs wrote up an application which we deployed via the JSS. The app pretty much did all of this for us; Asks the user for their old password so it can access the keychains etc Asks for a new password that meets the AD security policy and confirms Once password has met the minimum criteria, it then gets sent back to the AD servers and set as the new password The app then changes the keychain password and reboots the Mac.

This is how I do it in my environment. From here it's just down to user education, to make sure they change their password on their Mac through the Self Service, and not on another computer or through the webmail.

[sfarra]

@aporlebeke does your Fix My Keychain script work in 10.12.1? Would you be able to share it? Thanks!

[kturnbeaugh]

FWIW in our Labs we delete home directories on Friday nights after a reboot. The AD PassMont is great if someone uses the same computer every time. In a lab, they rarely do, so we have a policy that restarts the machines, and deletes the home directories of every user except the local admin account. This was the only viable solution we could come up with for those students that haven't logged into a computer for two password cycles. In our environment students are instructed to not save any data to the computers. I mention this because you indicated you're in a school environment, and this was one of the hurdles we had to jump over to get the Mac's joined to the domain.

[apizz]

@sfarra We're not going to be on 10.12 until next year, and I haven't done much testing with it. I don't believe anything has changed with respect to users' Keychains, so I don't see why the script wouldn't work.

This script removes the keychain for the currently logged-in user on the machine. The machine will have to be rebooted to generate a new keychain.

#!/bin/sh

USER=`/bin/ls -l /dev/console | /usr/bin/awk '{print $3}}'`

rm -rf /Users/$USER/Library/Keychains/*

if [ $? = 0 ]; then
    /bin/echo "Successfully deleted ${USER}'s keychain!"
else
    /bin/echo "Failed to delete ${USER}'s keychain."
    exit 1
fi

exit 0

[sfarra]

@aporlebeke Thanks!

[NoahRJ]

There are a bunch of Keychain posts, but I figured I'd piggyback off the newer one for some advice. Currently, we're blowing away the login.keychain/some others and having users restart to recreate, but it's become a bit burdensome for our users and we'd like to implement a rebuild without the restart. We branched off the great work @Andrina did here with some password error checking and thought since we have the user's password already, we might as well recreate keychain entries for commonly used applications (Outlook, Lync, Enterprise Connect). Below is some of the code to add that PW value to the login.keychain for Enterprise Connect:

#add Enterprise Connect pwd
su $USER -c "security add-generic-password -a '${USER}' -s 'Enterprise Connect' -w '${PASSWORD}' -c kchn -T '/Applications/Enterprise Connect.app' login.keychain"

That works great in 10.11, but with 10.12, we'll receive the below prompt when launching those created password apps:

I'm guessing 10.12 introduced some extra layer of Keychain protections. The 'security' tool includes some new commands in 10.12, including 'set-generic-password-partition-list', which I'm guessing is needed to stop users from seeing that prompt above, but aside from a not very helpful help page on the command, I'm having a tough time with the syntax. Looks like you need to pass along some value or values for the partition-list (identified with the flag -S), and it suggests you 'See output of "security dump-keychain" for examples', but none of that output works to pass along with the -S trigger.

Anyone have any experience with the above that could shed some light or point me in a direction? Thanks!