[OT] AD password change -> auto update keychains

[corbinmharris]

I'm not an AD expert, but it was my understanding that if Kerebos was properly implemented, changing an AD password, would also update saved passwords in the keychain such as for Outlook 2011, network servers, Wifi and items such as TimeMachine.

We are using Centrify 5.11 and AD mobile users (local home directory). Any ideas on configuring our AD that when a users updates their AD password, the saved keychain passwords are also updated? I am reaching out to Centrify on this issue as well.

Thanks!

Corbin

[dgreening]

I have found that if the user completes the password change in Sys Pref - Accounts while they are logged in (and the login keychain is unlocked) that it updates the login keychain password automatically. We instruct our users to change their passwords in this manner.

Edit, ah I see, you want the individual keychain items which contain their AD password to also be updated. I've never seen that work.

[chriscollins]

Yep he is correct. When you change your password on a bound machine it only auto-updates the password for the keychain file itself so the login window can unlock it automatically when the user logs in, but it does not change the individual items inside the keychain.

Also since you mentioned Kerberos you might have a misunderstanding of how Kerberos works. Kerberos really doesn't have much to do with the keychain. An application has to support Kerberos authentication to work with Kerberos, and then AD gives you a kerberos ticket that that application then uses to authenticate to whatever service that acceptsKerberos tickets for your domain. The whole point is that you don't actually save a username and password at all.

So for Outlook for Mac 2011, you actually have to explicitly tell the account settings that you want to use Kerberos authentication instead of a saved username and password.

I hope that helps. And sorry if you already understood Kerberos :)

[mm2270]

Right, this won't happen, because those saved passwords are actually just, well, saved passwords in the keychain. It (Keychain Access) doesn't know they are linked to an AD account. It could just as well be a Gmail password item or whatever. Typically the user will be prompted that the stored password is now invalid and be given a chance to update all those. But the main login.keychain password should and will sync up with the password change being made.

Around here we actually have a consistent problem of users saving their AD password into individual keychain items which of course become invalid after around 90 days when they have to change it. We actually encourage users not to save those passwords in some cases. SSO will often work in many cases as long as their "session" remains active. For example if they log in to a SSO enabled site in Safari, as long as they don't quit Safari or log out etc, they can keep going to that site and not have to log in again. While saving their password helps avoid re-logging in, its only for as long as their password hasn't changed.

I'm not sure if Centrify has some trick up their sleeve to make that happen automagically, but I kind of doubt it.

[chriscollins]

We use Centrify and they definitely don't do anything special in regards to the Keychain more than what the built in AD plugin does during a password change.

[rtrouton]

The keychain is a password-protected file. It does not refer to any directory services or to Kerberos, so the only way to update the password is by feeding it the old password, then providing the new password. If you don't have the password that the keychain needs to unlock, you don't get in and you can't update it to use the new password.

If you're changing your password using the Users & Groups pane in System Preferences, the OS handles the process for you by providing the login keychain first with the old account credentials (which are being replaced) and then the new account credentials. All of this happens behind the scenes, but that's the process which is going on.

In the event that your current login keychain uses different credentials that what the OS is feeding it, the keychain will not update with the new password.

[BLau]

Hi Corbin,

The kind folks above me are all correct: - Centrify only deals with the Kerberos authentications, it doesn't touch any "regular" saved passwords in the keychain.
- As long as your apps are properly configured to use Kerberos authentication, then when the users updates their AD password from the Mac - those apps will automatically use the new credentials as well.

- The best way to update the AD password is as follows:
-- 1. Make sure the Centrify agent is in "Connected" status (System Preferences > Centrify > "CentrifyDC mode: Connected")
-- 2. Then update the password via System Preferences > Users & Groups > [ Change Password ]

If the password was changed from another location, like webmail - then the Mac will need to go through at least one *Connected* logon operation before it's AD cache gets updated with the new password as well.

Kind regards,
Brian

[pblake]

Corbin, I know of nothing that can update any of the passwords stored in the keychain. How would the computer or Centrify "KNOW" that the password for exchange or a fileserver stored in the keychain is the same account/password. I know to us, it seems a no brainer, but it would be really difficult to program that intelligence without a lot of failure. Being from a AD domain myself, I have dealt with this issue during every password change, and my best solution is to make a short 3 minute video on how to change the passwords for your users. That has always been my take, hope that is helpful.

[Araneta]

This has been my headache for the past year too (outlook for mac, printers and sharepoint). The only way to get away from this is to use Kerberos. We recently upgraded our exchange server to 2012, if yours is set correctly Kerberos should work without a hitch. On my setup it needs the main ldap server for it to work properly. If you have shared printers on windows servers, you can turn on kerberos printing too by (cupsctl DefaultAuthType=Negotiate)(http://www.cups.org/documentation.php/doc-1.6/kerberos.html). This worked for me too. I still got no luck with sharepoint.

Hope this helps

[bentoms]

Sorry for the late reply. Just going through flagged emails.

Since this post I have released my fork of ADPassMon: http://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/

This can manage the login keychain password too.

[corbinmharris]

Revisiting this issue and came across the MS article to setup Outlook 2011 accounts to user Kerberos for user authentication -

http://technet.microsoft.com/en-us/library/jj984188(v=office.14).aspx

Our Windows guy left last month, so I'm working on getting myself unto speed with Centrify and AD management. So diving in with Centrify guides to figure out how to Kerberize our AD login credentials for our Windows file server and Wifi. Both require updating the local keychain as well when a user changes their AD pass.

[JPDyson]

Corbin, if your Mac is joined to AD with Centrify, and it's in Connected mode, you're going to get your Kerberos TGT with no additional effort. It's a matter of the server presenting Kerberos (or as IIS calls it, Negotiate) as an authentication protocol.

Also, if you're using AD credentials to log into the Mac and to authenticate to WiFi, you don't need the keychain at all. A configuration profile can handle that, so that whatever they used at the login window will be used for WiFi.

[JimAllsop]

@bentoms I keep getting "can't change password"

[Poseiden951]

@JimAllsop @bentoms

Same here, "can't change password" via System Pref

[ernstcs]

So is it safe to say that between THIS issue with AD users changing passwords and essentially breaking their keychain, AND the machines not completing a boot after being hard reset on Yosemite, it'd cover a lot of people's biggest headaches right now?

Should start one of those petitions for everyone to sign so Apple's gets the hint, this impacts a LOT of people and their time. Enterprise customers matter.

It was somewhat hilarious when our Apple SE asked, "So how many people would you say this (the password keychain issue) is impacting?" Well, technically, that's all or any of our users really. So about 11,000 users.

Added: We did make available the keychain first-aid item that uses Cocoa and prompts them through rebuilding their keychain we saw at JNUC a couple years ago, but it sure would be nice to NOT have to do that.

[Poseiden951]

@ernstcs

I'm seeing the Keychain break on 10.9.5.

[ernstcs]

@Poseiden951, you would. The keychain break problem is not new at all and has been going on for many versions.

I apologize if my mention of Yosemite and the issue with a hard reboot confused the thread topic. That's a separate issue, but certainly a really important one that is hopefully addressed soon.

[bentoms]

@Poseiden951 & @JimAllsop is this via ADPassMon or Sys Prefs?

Are you bound using Centrify?

[Sean_Ginn]

Quick question about ADPassMon...
I am seeing an issue that is giving me an extreme date for password expiration. 10675200 Days to be exact. When I look in AD under "msDS-UserPasswordExpiryTimeComputed" user attribute, I can see the correct date of expiration, but that information doesn't seem to be passing to the macs.

Just a quick side note, I am not very versed in AD, i'm just really good at googling lol.