Mavericks Server Keychain not properly storing information network users.

The problem in Yosemite seems to be even worth than described here.

Some network users can work for days without loosing any passwords from the keychain.

But some users loose all there password stored in keychain suddenly while working.

That means all of a sudden Mail, Calendar and Contacts start complaining about missing passwords.

There are lost of annoying send error messages in system log (hundreds)

26517 Mar 23 15:02:22 imac1 kernel[0]: Mail[3019] Unable to quarantine: 5

26518 Mar 23 15:02:22 imac1 kernel[0]: Mail[3019] Unable to quarantine `/Network/Servers/bigmac.bp-arc.corp/Shared/Users/martin/Library/Containers/com.apple.mail/Data/Library/Log s/Mail/2015-03-23_AccountManager.log': 5 (error suppressed)

26519 Mar 23 15:02:22 imac1 kernel[0]: Mail[3019] Unable to quarantine: 5

26520 Mar 23 15:02:22 imac1.bp-arc.corp Mail[3019]: Error writing to /Network/Servers/bigmac.bp-arc.corp/Shared/Users/martin/Library/Mail/V2/IMAP-m02e4bb5@w00fe72d.provider.com/.mboxCache.plist: Error Domain=NSCocoaErrorDomain Code=512 "Die Datei â<80><9e>.mboxCache.plistâ<80><9c> konnte nicht im Ordner â<80><9e>IMAP-m02e4bb5@w00fe72d.kasserver.comâ<80>< 9c> gesichert werden." UserInfo=0x61800046abc0 {NSFilePath=/Network/Servers/bigmac.bp-arc.corp/Shared/Users/martin/Library/Mail/V2/IMAP-m02e4bb5@w00fe72d.provider.com/.mboxCache.plist, NSUnderlyingError=0x618000a44c20 "Der Vorgang konnte nicht abgeschlossen werden. Zu viele offene Dateien"}

26521 Mar 23 15:02:22 imac1.bp-arc.corp Mail[3019]: Error writing to /Network/Servers/bigmac.bp-arc.corp/Shared/Users/martin/Library/Mail/V2/IMAP-m022034b@w00fe72d.kasserver.com/.mboxCache.plist: Error Domain=NSCocoaErrorDomain Code=512 "Die Datei â<80><9e>.mboxCache.plistâ<80><9c> konnte nicht im Ordner â<80><9e>IMAP-m022034b@w00fe72d.provider.comâ<80>< 9c> gesichert werden." UserInfo=0x600001668dc0 {NSFilePath=/Network/Servers/bigmac.bp-arc.corp/Shared/Users/martin/Library/Mail/V2/IMAP-m022034b@w00fe72d.provider.com/.mboxCache.plist, NSUnderlyingError=0x600001455900 "Der Vorgang konnte nicht abgeschlossen werden. Zu viele offene Dateien"}

26522 Mar 23 15:02:23 imac1.bp-arc.corp secd[2842]: securityd_xpc_dictionary_handler Mail[3019] copy_matching The operation couldnâ<80><99>t be completed. (com.apple.utilities.sqlite3 error 10 - reset: [10->1802] disk I/O error sql: SELECT rowid, data FROM inet WHERE port=? AND srvr=? AND sync=? AND ptcl=? AND acct=? AND tomb=? AND agrp IN (?,?) LIMIT 1)

26523 Mar 23 15:02:23 imac1.bp-arc.corp Mail[3019]: SecOSStatusWith error:[-25291] Der Vorgang konnte nicht abgeschlossen werden. (com.apple.utilities.sqlite3-Fehler 10 - Remote error : The operation couldnâ<80><9a>Ã<84>ôt be completed. (com.apple.utilities.sqlite3 error 10 - reset: [10->1802] disk I/O error sql: SELECT rowid, data FROM inet WHERE port= ? AND srvr=? AND sync=? AND ptcl=? AND acct=? AND tomb=? AND agrp IN (?,?) LIMIT 1))

26524 Mar 23 15:02:23 imac1.bp-arc.corp Mail[3019]: Error finding an Internet password for m022035b@w00fe72d.provider.com: -25291

26525 Mar 23 15:02:23 imac1.bp-arc.corp secd[2842]: securityd_xpc_dictionary_handler Mail[3019] copy_matching The operation couldnâ<80><99>t be completed. (com.apple.utilities.sqlite3 error 10 - reset: [10->1802] disk I/O error sql: SELECT rowid, data FROM inet WHERE port=? AND srvr=? AND sync=? AND ptcl=? AND acct=? AND tomb=? AND agrp IN (?,?) LIMIT 1)

26526 Mar 23 15:02:23 imac1.bp-arc.corp Mail[3019]: SecOSStatusWith error:[-25291] Der Vorgang konnte nicht abgeschlossen werden. (com.apple.utilities.sqlite3-Fehler 10 - Remote error : The operation couldnâ<80><9a>Ã<84>ôt be completed. (com.apple.utilities.sqlite3 error 10 - reset: [10->1802] disk I/O error sql: SELECT rowid, data FROM inet WHERE port= ? AND srvr=? AND sync=? AND ptcl=? AND acct=? AND tomb=? AND agrp IN (?,?) LIMIT 1))

26527 Mar 23 15:02:23 imac1.bp-arc.corp Mail[3019]: Error finding an Internet password for m022035b@w00fe72d.provider.com: -25291

Next try will be to restore the whole Library from a backup.

Network Users are not usable this way.

This problem seems to date from when Mavericks was introduced along with its very different behaviour with Keychains. There are two main changes with keychains, the first is the use of a second keychain called 'Local Items' in addition to the former and still existing 'Login' keychain. The second is that the keychain files rather than having a simple name of e.g. login.keychain now have a UUID as part of the file name.

I have not closely read this entire thread but I am noticing one of the symptoms that I do not recall seeing mentioned is that the 'Local Items' keychain when this problem occurs ends up being completely empty and also will not allow adding any entries - hence you cannot save the password to it. A temporary fix is to logout the user, delete the ~/Library/Keychains folder and then the user can login and at least for that session successfully add and save their passwords until the problem re-occurs.

I have setup the suggested LogoutHook via Profile Manager and I believe this is being successfully pushed to our client Macs. I did however find an issue with this and a solution that may help some people who have not been able to get it working. LoginHooks and LogoutHooks work by running shell scripts, this means the user logging in or out needs to be allowed to run shell scripts which means their user account needs to have a shell defined for their account e.g. /bin/bash I found some of our user accounts had none set and therefore were not allowed to run shell scripts. Changing this allowed LoginHooks etc. to run.

Another thing to check is what level of trust you need to define for a Login or LogoutHook to work. Test your client by running -

dscl localhost -read /LDAPv3/nameofserver.domain.com

This should show the level of authentication you need to set in MCXScriptTrust.

Hello!

Newer expierences: user logged into a client computer where I setup the kill_sed script and had now trouble. After a few hours this users logged out and back into a computer where I had no time to setup the kill_secd script and immediately ran into "password again and again"-bug.

I looked into the process list of this client computer and found three running "secd"s of three different users and 15 running processes of the user that logged out before the above mentioned user logged in. The user logged out about 5 hours ago!

I filled a new bug report, but i looks like my reports are ignored - I am still waiting for the first response from Apple to my last 3 bug reports filed at the end of december 2014.

@Apple: You loose business customers every day until this bug is fixed!

Bye,

eweri

P.S. Just checked another client computer that is used by lots of users (not network users - changed to local users a few weeks ago). I found that at this computer were three local users logged in but four secds were running. Checked which user was still running secd but is not currently logged in and than check if there are still other processes running for this user - found 14 processes running since 5 days ago!

Now I am looking for a script that kills every process of the current user when the user logs out.

Hello!

I played around with a test computer and as far as i can tell Yosemite does not kill around 20-25 process and let them run endlessly when a user logs out.

I tried to solve this with a script that starts as launch agent, the script "traps" SIGINT, SIGKILL and SIGHUB to do some stuff but it looks like Yosemite kills this script so fast that it is able to kill only a few processes until it self get killed.

So I took the brutal way and played with Benjamin Losch script. I thought why kill secd only? What if you kill all process of a user at login?

Well I tried it - if a user logins and a launch agent kills all processes immediately - the login takes a few seconds longer or the user sees the desktop a few seconds than it looks like it got logged out just to see the desktop again.

I found only one problem: programs that should automatically start when the user logs in get killed and do not start.

Bye,

eweri

P.S: Is there a way to get a signal when a user logs out? So it would be really ease to write a launch daemon that runs as root and could kill all process of a just logged out user after a little waiting.

P.P.S: Just saw another disadvantage of the "brutal way" - the Dock lost its setup 😊

You could use a logouthook script.

I described on page 9 of this thread how this is done.

But will that solve the problems with keychain loosing passwords.

I have a logout script that kills send and secinitd but still users are losing their passwords.

BTW:

Did anyone check if the problem persists with OS X 10.10.3?

Regards

Martin

For what its worth I have succcesfully implemented the script as a logouthook (I put an additional line in to write to the console log to show it had run) but I am like you finding that at least some users still have the problem in that when they log back in Mail/Calendar/Contacts re-asks for the password. The majority of our users are still running Mavericks 10.9.5 but with a Yosemite 10.10.2 server.

In my network it happens that Mail/Contacts/Calendar ask for passwords after users have been logged in for several hours and have been using this apps all day.

The keychain then is empty.

In some cases the keys come back into the keychain when the user logs out and back in again.

But usually I have to copy the ~/Library/keychains folder from a backup while the user is logged out.

Hi Martin,

thanks for the addition to the kill script!

I was waiting eagerly for a 10.10 solution and now i can't wait to test this!

I have to report that this Bug stays unfixed from Apple's side in 10.10.3 😠

Greetings,

Ben

Hallo

Could it be localisation Problem? possible that this problem occurred more on international System like German. Please write what Langauge or Country settings you are using!

Regards

Gérard

Hello Gérad!

Good point:

The systems I see with this problem are all setup with german language and the users all use german as thier language setup.

If this bug depends on languages it is still a bug - function should not depend on language selection.

Bye,

eweri

At first i tended to neglect the possibility that localization could be a factor here.

But if all affected systems are running germane locale?

Mine does run in german. Hase someone a test setup for testing?

Laufen wirklich alle betroffenen Systeme auf Deutsch? Könnt ihr das bestätigen?

Thanks & greetings,

Ben

Hello,

I am running localized English versions of both clients and server and this is definitely a real problem. So bad for so long that we are looking at other solutions.

Doug

Hello!

Just got a call from my customer looks like the script that should fix this bug works 50-70% of the time, only. One User had a problem with passwords all day and the next day the problem was gone until today to have the password problem again.

I am waiting for a recall of my customer if I understand what she told me, today she could not get Mail or Calendar running logging in at two different computers but she never got a problem at a computer she used to log in 90% of the time. I am still waiting for confirmation.

Looks like computers that a network user used before the update to Yosemite do not run into this problem.

BTW. My two bug reports were closed by Apple because they were duplicates.

Hello

actually we are rolling out 15 iMacs and one OS X Server. Both runs with 10.10.3.

Unfortunatly we have excatly the same issue with the keychain. Password from calendar, mail and browser wont be safe when the process is blocked.

Have anybode some news with this issue?

Thanks & best regards

Juerg