Skip to main content

We maintain passwords via a larger AD userbase, and I am now thinking I might like to see Keychain Access disabled for good. Meaning yes, lab and public workstation users would have to enter every password they need for every website they need one for-- every time. This would be great for computer labs like ours where computers often are abandoned. It appears as if the AD plugin in the post-10.7 OS's is slowly becoming unglued and increasingly buggy, IMHO. Computer lab users inevitably misunderstand or are baffled by the choices that the OSX AD-plugin Keychain GUI demands they make every time there is a domain account password change for the user.

It is my understanding that this is impossible given OSX's underpinnings, but I wanted to ask whether anyone has made this approach work for public or kiosk workstations. We have access to Profile Manager and its settings choices-- as well as the ability to deploy scripts and commands of every conceivable kind.

Thanks for any advice or wisdom on this. Keychain and AD have been the one item for us that consistently gets in the way of a smooth end-user experience. Users having to remember website passwords would be much preferable to all the outcomes we have seen with local login Keychain and the convenience they were originally intended to provide.

I have seen ADPassMon and a few other approaches to this, but I am becoming more interested in some more fundamental approach to circumventing the Keychain login db for good for an AD user.

I don't think you can disable it completely, but 2 things that comes to mind:

1) Set up the default profile with an empty keychain, which is set to either read-only, or with permissions completely removed. ie; touch /System/Library/User Template/English.lproj/Library/Keychains/login.keychain; chmod 400 [...]

No idea how much that would break OSX though - whether or not it handles it gracefully when it's not a valid keychain file.

2) Create a logout hook which deletes the keychain each time. The upside to this is that they can have passwords remembered for the session, so they don't have to keep typing in passwords everytime they want to access something (in our case, we have a proxy that needs to be authenticated with).

You might find that diskutil repairpermissions / (A pretty common maintenance routine) fixed the permissions and made the file usable so you would have to test that and possibly be re applying the lock each time with a login hook.

OS X does not appreciate not being able to write to a local keychain during the user session.
I'd suggest allowing the login.keychain for the session itself, writing a policy triggered both on logout and startup that deletes any login.keychain files from all user homes, and then using the ```
security create-keychain
``` command with a login policy to create a new temporary login keychain that's good until the next reboot.

psliequ solution seems very smart and good on the paper.

We have same pb in our company. Apple seems still not fully convinced that keychain is good for local/private users, but not for enterprise users being in an AD environment (where auth should always be done transparently with domain credentials, and only display a pwd prompt if these creds fail). Not to mention tickets generated by endusers, complaining they locked their AD account, just because they forgot to update some pwd entries in keychain...

We also have sometimes reliability problems with AD module : some computers suddenly cannot talk to AD anymore, because either some nodes (seen with "odutil show nodenames") are shown as being offline, or only AD group enumeration fail, or KDC cannot be discovered (seen with "odutil set log debug"), or OSX AD certificate profile fail to get AD cert from our PKI infra,... I also have seen one case where the "/Active Directory/your_domain" object in system keychain suddenly disappeared, so obviously Mac could not be trusted by AD anymore.

All that stuff work again if Mac is restarted (restarting "opendirectoryd" rarely helps), or unbound/rebound to AD.

Terms & ConditionsCookie settingsAccessibility statement