Keychain password and LDAP password sync’ing

[Anonymous]

I am getting complaints from my users about their keychain password. Every time they change their login password (Kerberos/LDAP) they have to type in their old password until I can run Keychain first aid. This is unacceptable every 30 days. How can the key chain password be kept in sync with the login password automagically? TIA.

[Anonymous]

The password is changed via the logon screen when the password expires.

[Anonymous]

I hadn’t thought of it as a bug. I figured I was missing something. We have premium support for our servers but I wonder if Apple will support this since its on a client.

All are running 10.3.3 and the home directories are remote.

Single sign on is the goal.

[Anonymous]

Did you use anything to import the user into workgroup manager?

[Anonymous]

No. These were added from scratch.

I called Apple on this and reported it as a bug. I have not heard back yet but level I thought this was expected behavior. When pressed, level I could not explain how it was a security issue to NOT change passwords when the rest of the world seems to think changing passwords is a good thing.

[Anonymous]

This has been an issue for us ever since we started binding our Macs to our AD Server. We’re running 10.3.5 – 10.3.9 and have passwords set to expire every 45 days. With 250 users, we hear about the Keychain issue every day.

I have not tested this with 10.4 yet, maybe it’s not an issue there, but we need to stay on 10.3.x for now because of some third party software that’s not 10.4 ready.

Does anyone have a workaround that’s a little more user friendly?

[gw1500se]

I reported this to Apple as a bug quite some time ago. Although I have my doubts, they claim the reason they are not fixing it on Panther is because it is fixed on Tiger

As a side note (you may already have gotten this complaint) if the password expires after the user logs in and the screen saver is activated it will no longer unlock with the expired password (a bug fixed in Tiger?) and Applemail will no longer connect to the POP server (another bug fixed in Tiger?). This is driving our users crazy every 30 days. They have to then quit everything they are doing, log out, log back in, change their password, run keychain first aid and edit their Applemail password settings (because Kerberos authentication is broken on our POP server which is also supposedly fixed in Tiger). Effective single signon is only a pipe dream at this point (fixed in Tiger?).

[mikemchargue]

This is not fixed in Tiger. I’m running an OD master on 10.4.2 Server. My clients are 10.4.2 with network homes. When users are prompted to change their passwords at login, their Keychain passwords are not changed and support hell ensues. I have 150 users and most of the accounts were created on the same day. Every 90 days I spend a full work day helping people get their Keychain password to match their OD password.

Of course, if the users use the Change Password button in System Preferences>Accounts the Keychain password is changed. I can’t convince any of them to change their passwords before that 90 day mark though.

This is truly aggravating.

I’ll have to look into this Keychain Minder.

[mikemchargue]

Three cheers for Keychain Minder!

I loaded that app in /Applications/Utilites and then added it to the login items in group preferences in the OD Master. Now everything works as it should.

[superrcat]

[QUOTE BY= mikemchargue] This is not fixed in Tiger. I’m running an OD master on 10.4.2 Server. My clients are 10.4.2 with network homes. When users are prompted to change their passwords at login, their Keychain passwords are not changed and support hell ensues. I have 150 users and most of the accounts were created on the same day. Every 90 days I spend a full work day helping people get their Keychain password to match their OD password.

Of course, if the users use the Change Password button in System Preferences>Accounts the Keychain password is changed. I can’t convince any of them to change their passwords before that 90 day mark though.

This is truly aggravating.

I’ll have to look into this Keychain Minder.[/QUOTE]

Although the desired effect is to have the login password and keychain password synchronized, I can see why it’s not working. Password policy enforcement occurs before a network home is mounted. If the network home is not mounted, then the keychain is not accessible. If the keychain is not accessible, then the keychain password can not be updated.

The mechanism that is handling a password reset occurs before the mechanism that is handling home directory access in the authorization database. If it is not already doing so, the password reset mechanism should be passing a hint or context data to the home directory mechanism with the previous password so the keychain can be updated (since it is now authenticating to the network home with the new password).

This is just a big assumption on the implementation though…

[superrcat]

[QUOTE BY= macshome] OK, I haven’t seen anyone mention this yet so I will.

The keychain not syncing when the account password is changed at the directory or login window level is by design. It’s a good thing too.

Why? Let me explain.

The Keychain is an all purpose secret repository. It can contain all sorts of stuff like online banking passwords, secure notes, and other fun stuff. This is info that should be protected.

If the keychain automaticly synced when the password was changed at the login window or in the directory than a malicious admin could easily get that info. All they would need to do would be to change the password, walk over, and login.

By not syncing the Keychain anywhere but the system prefs, you reduce this attack vector greatly and it keeps your personal secrets safe. i.e. you need to know the old password to change the current one in the prefs.

Keychain Minder is great becasue it allows a streamlined solution to the user support part of the equation without reducing the security of the keychain contents.[/QUOTE]

I can see what you are saying, but updating a user’s keychain password should be allowed through loginwindow. At the point of the required password change, the user has already authenticated and confirmed who he or she is by supplying the old password.

[Anonymous]

[QUOTE BY= macshome] OK, I haven’t seen anyone mention this yet so I will.

The keychain not syncing when the account password is changed at the directory or login window level is by design. It’s a good thing too.

Why? Let me explain.

The Keychain is an all purpose secret repository. It can contain all sorts of stuff like online banking passwords, secure notes, and other fun stuff. This is info that should be protected.

If the keychain automaticly synced when the password was changed at the login window or in the directory than a malicious admin could easily get that info. All they would need to do would be to change the password, walk over, and login.

By not syncing the Keychain anywhere but the system prefs, you reduce this attack vector greatly and it keeps your personal secrets safe. i.e. you need to know the old password to change the current one in the prefs.

Keychain Minder is great becasue it allows a streamlined solution to the user support part of the equation without reducing the security of the keychain contents.[/QUOTE]

As a “malicious admin” I’d like to add that this is our #1 most annoying support call. With passwords expiring every 45 days and no built-in syncing of the LDAP and Keychain passwords, we have come to despise the Keychain and everything it stands for. This is NOT fixed in Tiger but should be a priority for Apple in the 10.4.3 update.

[superrcat]

[QUOTE BY= Slappy White]
As a “malicious admin” I’d like to add that this is our #1 most annoying support call. With passwords expiring every 45 days and no built-in syncing of the LDAP and Keychain passwords, we have come to despise the Keychain and everything it stands for. This is NOT fixed in Tiger but should be a priority for Apple in the 10.4.3 update.[/QUOTE]

Well, what you are asking for, built-in synchronization between an LDAP directory and user keychains, is not fixed because it is not a bug. What you are asking for is a new feature and the only way it could appear in Mac OS X is through a feature or enhancement request.

Updating the keychain password to match a new password, in my opinion, should only occur on Mac OS X (from the client) and only when the user is changing the password by providing the old password, both occur at loginwindow and System Preferences.

[gw1500se]

Perhaps I am misunderstanding but I don’t see what Keychain Minder does that is any different then Apple’s keychain access and the change password fuction.

The crux of the problem is that every time users change their login password all the applications that are autostarted can’t access the keychain and half the user’s dock is bouncing, throwing up password and error windows, creating a mess for the user.

Whether Apple is wants to spend the resources making their single signon feature really work is one thing. However, arguments about not implementing a solution for security reasons is another. It seems to me every argument, in that area presented here, should be up to the systems admin as an option rather then being decided by a one-size-fits-all disinterested opinion, even that of Apple.

As such an admin the security concerns expressed are not applicable in my environment. The risks of users not changing passwords is much greater then the risks associated with sync’ing keychains, in my opinion. Indeed, there is no risk in this environment. If I want a users password I just ask or change it myself. If the din continues about this much longer with no relief in sight, I doubt I can continue to convince management we need to keep changing passwords.

[Anonymous]

Thanks, Joel for Keychain Minder. I added it to our 10.4.2 image today and it works great.

I can already imagine the Keychain calls melting away……

[Author]

Posts