Erich Wetzel

Q: Mavericks Server Keychain not properly storing information network users.

OS 10.9.1, Server 3.0.2. Clients OS 10.9.1 bound to server Open Directory and managed with Profile Manager. 10.6.8 Mail server bound to 10.9.1 server Open Directory. Messages is running on the 10.9.1 server which hosts the users.

 

Changeip -checkhostname indicates DNS is correct for the server. Server is running on a FQDN, no .local or other DNS issues.

 

For everything below: the Keychain for any of the users does not need to be repaired.

 

Generally things are going well with one exception which is a big problem.

 

Each time a network user logs and tries to use either Mail to connect to our mail server via IMAP or Messages in they are prompted for passwords. Messages takes the password and logs in. Mail acts as though the password was incorrect and asks for it again, it does not pass the connection to the mail server. There is no trace of the attempted login on the mail server logs.

 

Functional workarounds:

 

1 - OS reinstall allows immediate login on the mail server and connections as expected. This is a little too much for day to day use.

 

2 - (From somewhere in the forums forgot who, sorry), User login, go to User's network home/Library/Keychains and move any keychains with long strings of letters and numbers as name to another folder or put in trash, immediately reboot, User login again, enter passwords in Mail, immediate connection to mail server and expected behavior from Mail.app.

 

As a network user machine in a multi user environment, the next user will have to repeat the entire procedure above, including the reboot, to get access to the contents of the mail server. The first user in the example above will have to repeat it, if they come back to the same machine and log in again.

 

This is what we are doing now. It appears that it would work on a personal machine with local users and has solved a lot of issues in the forum. It is helping but does not solve the keychain problem for network users.

 

Does anyone have any advice.

 

Thanks.

 

-Erich

OS X Server

Posted on Jan 10, 2014 6:42 PM

Close

Q: Mavericks Server Keychain not properly storing information network users.

  • All replies
  • Helpful answers

first Previous Page 9 of 19 last Next
  • by jpawelchak,

    jpawelchak jpawelchak Mar 3, 2015 11:23 AM in response to Erich Wetzel
    Level 1 (0 points)
    Mar 3, 2015 11:23 AM in response to Erich Wetzel

    Who following this thread are Apple Consultant Network (ACN) members? I am suggesting that we all contact ACN admin e-mail address to get them to escalate this bug which has been around since the introduction of Mavericks (10.9) and is still in the beta of Yosemite (10.10.3).  They (ACN) won't do so, however, until enough ACNs that they represent contact them.

  • by macmartin,

    macmartin macmartin Mar 17, 2015 8:11 AM in response to Erich Wetzel
    Level 2 (499 points)
    Mar 17, 2015 8:11 AM in response to Erich Wetzel

    I have the " error = 122: Path had bad ownership/permissions" error, too.

    But I don't find any bad permissions:

     

    This is what I have:

    ls -led /usr

    drwxr-xr-x@ 11 root  wheel  374 14 Mär 12:36 /usr

    ls -led /usr/local

    drwxr-xr-x  6 root  wheel  204 17 Mär 14:29 /usr/local

    ls -led /usr/local/scripts

    drwxr-xr-x  3 root  wheel  102 17 Mär 15:59 /usr/local/scripts

    ls -le /usr/local/scripts/kill_secd.sh

    -rwxr-xr-x  1 root  wheel  174 17 Mär 15:59 /usr/local/scripts/kill_secd.sh

     

    Does anyone see what I am missing?

     

    I am on 10.10.2 Clients with network accounts on 10.10.2 Server

    Clean install this weekend

     

    Greetings

    Martin

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 20, 2015 2:00 AM in response to jpawelchak
    Level 1 (18 points)
    Mac OS X
    Mar 20, 2015 2:00 AM in response to jpawelchak

    Hello everybody!

     

    It is a shame that Apple only looks at iOS and forgot OS X. We need a another forum to get heard.

     

    Some here with a good friend at a mac magazine who's not afraid about Apples lawyers?

     

    At least this bug renders OS X Server unusable. I think about speaking to my customers (round about 35 dentists - about 200 Macs) to sign an open letter about  massive quality problems and bugs with OS X. Maybe this gets its way to Tim Cook.

     

    This is my list of horrible bugs that have to be fixed ASAP:

    1. Keychain and network homes

    2. SMB file sharing - problems with access rights

    3. speed of file sharing

    4. speed of ARD

    5. ...

     

    BTW. I never setup a Windows Server with network homes - is it possible and does it work reliable?

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Mar 20, 2015 2:20 AM in response to Christoph Ewering1
    Level 1 (38 points)
    Desktops
    Mar 20, 2015 2:20 AM in response to Christoph Ewering1

    Hello Christoph

     

    Same situation here in Switzerland! I have the same envouriments as you with about 50 Ophthalmological Chirurgs. All the bugs you list we have also. It is a shame what the produce (200 new features, 300 new bugs) But I think Apple want to kill their Business Clients and only supply Barbie Computer for Dummies and Mobile Devices for idiots. I am shure in a couple of years none serious business will have OS X on their desk. 10.6.8 was the latest working OS X, all newer are useless and filled with bugs

     

    Regards

    Gérard

  • by macmartin,

    macmartin macmartin Mar 21, 2015 6:27 AM in response to macmartin
    Level 2 (499 points)
    Mar 21, 2015 6:27 AM in response to macmartin

    I want to give some feedback about the "bad ownership/permissions" issue.

     

    The problem was not the permissions of the kill_secd.sh script but of of LaunchAgent plist file.

    This file must not be writable from groups and others.

    It does not even need to be executable.

    When I changed permissions to 644 the script was run but it was complaining in system.log about the keys "UserName" and "GroupName".

    After removing these it runs with a charm.

     

    I added some logging to have control over whether it was run or not.

     

    In Terminal:

    touch /Users/Shared/kill_secd.log

    chmod 777 /Users/Shared/kill_secd.log


    In the script:

    #!/bin/bash

     

    LOG=/Users/Shared/kill_secd.log

    DATE=`date`

     

    echo $DATE - $USER: in killall_secd >> $LOG

     

    /usr/bin/killall -9 secd

    /usr/bin/killall -9 secinitd

     

    echo "$DATE - $USER: return code: $?" >> $LOG

     

    Greetings

    Martin

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Mar 21, 2015 6:33 AM in response to macmartin
    Level 1 (38 points)
    Desktops
    Mar 21, 2015 6:33 AM in response to macmartin

    Hello Martin

     

    Very nice that you have a workaround, but in my opinion Apple should fix this by a Software Update. The Bug is at least availible for 2 years now and from Apple heard nothing!

     

    Maybe it is a bug that is not on all System but when I look in this forum , many users have this issue!

     

    Regards

    Gérard

  • by macmartin,

    macmartin macmartin Mar 21, 2015 6:50 AM in response to Gerard Dirks
    Level 2 (499 points)
    Mar 21, 2015 6:50 AM in response to Gerard Dirks

    The workaround builds up on what Benjamin Losch has posted on page 5 of this thread.

    So he deserves the flowers.


    I totally agree that apple has to fix it but if they don´t we have to help ourselves I guess.

    Shame on you, Apple!


    My feeling is that the bug could be fixed by adjusting the plist files of seed and secinitd but I have not the time and not quite the knowledge for further investigations.

    I only noticed that there are messages in System.log about keys in the corresponding plist files which don't do anything and should be removed.


    com.apple.xpc.launchd[1] (com.apple.secd): This key does not do anything: OnDemand

    com.apple.xpc.launchd[1] (com.apple.secd): The ServiceIPC key is no longer respected. Please remove it.


    In my opinion this is a an evidence of incapability for a company like Apple.

    They can´t even implement their own changes into their own code correctly.

    This might even be a ticking bomb for future bugs.

    I am quite disappointed by Apple and I have been using Apple computers since 1984.


    Greetings

    Martin

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 22, 2015 1:46 PM in response to macmartin
    Level 1 (18 points)
    Mac OS X
    Mar 22, 2015 1:46 PM in response to macmartin

    Hello!

     

    Just one short question: Does the script solves the problem with Yosemite, too?

     

    Bye,

    eweri

  • by macmartin,

    macmartin macmartin Mar 22, 2015 2:06 PM in response to Christoph Ewering1
    Level 2 (499 points)
    Mar 22, 2015 2:06 PM in response to Christoph Ewering1

    I think so.

    I could proof that it kills secd and secinitd when restarting but I did not yet test when logging off.

    I will do so in the next days and report.

     

    Greetings

    Martin

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 23, 2015 3:24 AM in response to macmartin
    Level 1 (18 points)
    Mac OS X
    Mar 23, 2015 3:24 AM in response to macmartin

    Okay, here are my experiences with the script: it works with 10.10 !

     

    I just did a few test so I can not tell if it works reliable - but it looks promising. :-)

     

    I had a user that could not use Mail nor Calendar and just installing the script does not work. I had to remove the account data, rebooted the computer and configure the account data again. Than I logged in at the same client with a different user, who had trouble before - no more trouble, logged off and back in as first user and no trouble, too.

     

    So this script looks really promising!

     

    Just for some bug hunting: This bug happens mostly with users using different client computers over time. I have a few users that always login at the same client computer and they never got this problem.

    Users that do not experience this problem and use different client computers login into computers that were running 10.8 but their "main"-computer is running 10.10 - but they never login to a computer running 10.10 (or 10.9).

     

    So to me this looks like the problem starts when a user logs into different clients running 10.10 (or10.9?).

     

    Maybe this helps solving this bug,

    eweri

     

    BTW. Many thanks to Benjamin Losch for the workaround

  • by macmartin,

    macmartin macmartin Mar 23, 2015 5:14 AM in response to Christoph Ewering1
    Level 2 (499 points)
    Mar 23, 2015 5:14 AM in response to Christoph Ewering1

    For me the script didn't work.

    I think this is because the UserName and GroupName keys are not supported (any more?)

    I found this in system.log:

    6714 Mar 23 11:01:53 imac1 com.apple.xpc.launchd[1] (kill_secd): The UserName key is not supported for non-System services.

    6715 Mar 23 11:01:53 imac1 com.apple.xpc.launchd[1] (kill_secd): The GroupName key is not supported for non-System services.

     

    Also I found that after logging out and in again with another user the seed process of the first user was still running.

    I remind my script a little to see whats going on:

    #!/bin/zsh

     

    LOG=/Users/Shared/kill_secd.log

    DATE=`date`

     

    echo $DATE - $USER: in killall_secd >> $LOG

     

    echo "before kill:" >> $LOG

    ps Au | grep secd >> $LOG

    /usr/bin/killall -9 secd

    /usr/bin/killall -9 secinitd

    echo "$DATE - $USER: return code: $?" >> $LOG

    echo "#######################################" >> $LOG

    sleep 1

    echo "after kill:" >> $LOG

    ps Au | grep secd >> $LOG

    echo "#######################################" >> $LOG

     

    Also in the log file I could see that "after kill" the seed process was not running.

    I think this is because the script runs under the UID of the user who logs in and he is not allowed to kill processes of the user who was logged in before.

     

    Next I tried to configure a LogOut Script with profile manger but I couldn´t get it running so I finally created a LogouHook.

    This technonolgy is depreciated but TADA! It works.

    A look into the log file proves that the seed process gets killed

     

    #######################################

    Mon Mar 23 12:46:47 CET 2015 - : in killall_secd

    before kill:

    admin             2593   0.0  0.0  2539620   4160   ??  S    12:45PM   0:00.04 /usr/libexec/secd

    root              2676   0.0  0.0  2432772    476   ??  R    12:46PM   0:00.00 grep secd

    root              2672   0.0  0.0  2451732   1104   ??  S    12:46PM   0:00.00 /bin/zsh /usr/local/scripts/kill_secd.sh admin

    Mon Mar 23 12:46:47 CET 2015 - : return code: 0

    #######################################

    after kill:

    root              2682   0.0  0.0  2432772    428   ??  R    12:46PM   0:00.00 grep secd

    root              2672   0.0  0.0  2460948   1124   ??  S    12:46PM   0:00.01 /bin/zsh /usr/local/scripts/kill_secd.sh admin

    #######################################

    Mon Mar 23 12:47:13 CET 2015 - : in killall_secd

    before kill:

    root              2815   0.0  0.0  2424580    400   ??  R    12:47PM   0:00.00 grep secd

    root              2811   0.0  0.0  2451732   1100   ??  S    12:47PM   0:00.00 /bin/zsh /usr/local/scripts/kill_secd.sh martin

    martin            2779   0.0  0.0  2540692   2940   ??  S    12:47PM   0:00.03 /usr/libexec/secd

    Mon Mar 23 12:47:13 CET 2015 - : return code: 0

    #######################################

    after kill:

    root              2820   0.0  0.0  2432772    476   ??  R    12:47PM   0:00.00 grep secd

    root              2811   0.0  0.0  2461972   1132   ??  S    12:47PM   0:00.01 /bin/zsh /usr/local/scripts/kill_secd.sh martin

    #######################################

     

    Creating the LogoutHook is easy:

    sudo defaults write  com.apple.loginwindow LogoutHook /usr/local/scripts/kill_secd.sh

    This has to be done on alle clients.

     

    I feel it would be a little more elegant to use profile manager for this, but it did´t work for me.

    I set EnableMCXLoginScripts = TRUE; and MCXScriptTrust = FullTrust; in com.apple.loginwindow but the script was not run.

     

    I would appreciate if any one could explain what I am missing.

     

    Greetings

    Martin

  • by macmartin,

    macmartin macmartin Mar 23, 2015 7:22 AM in response to macmartin
    Level 2 (499 points)
    Mar 23, 2015 7:22 AM in response to macmartin

    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.

  • by John Lockwood,

    John Lockwood John Lockwood Mar 25, 2015 8:22 AM in response to macmartin
    Level 6 (9,349 points)
    Servers Enterprise
    Mar 25, 2015 8:22 AM in response to macmartin

    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.

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 26, 2015 2:28 PM in response to John Lockwood
    Level 1 (18 points)
    Mac OS X
    Mar 26, 2015 2:28 PM in response to John Lockwood

    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

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 26, 2015 2:47 PM in response to Christoph Ewering1
    Level 1 (18 points)
    Mac OS X
    Mar 26, 2015 2:47 PM in response to Christoph Ewering1

    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.

first Previous Page 9 of 19 last Next