Christoph Ewering1

Q: network home user lead to damaged keychains - still no fix since Mavericks

Hello!

 

This discussion is about a very frustrating bug - that lives in OS X since Mavericks and is still not fixed in El Capitan 10.11.3 even though lots of bug reports were filed but Apple does not recognize it.

 

The bug in short: if you try to use network home user at an unpredictable point in time this user is unable to access its own keychain items. The console gets filled with messages about accountsd can not access a file and until then Mail, Calendar or any other program that wants to connect to the keychain can not access the passwords any more. When this happens there is no work around other than create the user from scratch. (Until this bug happens again after a few hours or days)

 

What the community found out so far is that:

- If you reboot the client machine after every logout of a network user this will prevent the bug

- OS X leaves some processes of a user running even thought the user has logged out!

- If you kill secd and secinitd after a network user logged out this bug is prevented

- There is a script as a work around that kills every process of a user that logged out - (but OS X starts some processes again - very strange)

- the bug resides in OS X (client) and rises his ugly head only when network home users are used

 

Here is the link to original discussion

Mavericks Server Keychain not properly storing information network users.

 

Here is the link to the script as work around

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

 

Here is a link for those guys using WGM

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

 

I have no explanation why Apple does not fix this bug as it makes using OS X Server useless.

 

I started this discussion to transfer what was found out to be found under El Capitan discussion. (to spread the word ;-))

 

Bye,

Christoph

Mac mini, OS X Server

Posted on Jan 25, 2016 1:38 PM

Close

Q: network home user lead to damaged keychains - still no fix since Mavericks

  • All replies
  • Helpful answers

Previous Page 2
  • by macmartin,

    macmartin macmartin Feb 6, 2016 10:51 AM in response to PSC-Admin
    Level 2 (499 points)
    Feb 6, 2016 10:51 AM in response to PSC-Admin

    Thanks for the explanation.

     

    Before I try I have some more questions,

     

    What does the %@ stand for?

    Is it a variable for the username?

     

    For me it is quite important the users can switch computers at any time.

    So my idea is to store the keychains of any user on any computer.

    What access rights, owner and group settings are needed for the local keychains folders?

     

    Are there any additional steps needed when  storing a new password in the keychain (e. g. when creating a new Mail account)?

     

    I already asked this in the other thread (Mavericks ...) but did´t get any answer yet.

  • by PSC-Admin,

    PSC-Admin PSC-Admin Feb 11, 2016 9:25 PM in response to macmartin
    Level 1 (4 points)
    Servers Enterprise
    Feb 11, 2016 9:25 PM in response to macmartin

    Hi,

     

    sorry it has taken me a while to respond.... Our school year started in Australia.

     

    So to answer your Questions:

     

    %@ stands for the username of a user that logs on to the computer. In case of the Link it creates it under Shared/username/Library/Keychain

     

    User can go to any other computer and log in, as Apple has now decided that keychain will be tied to computer UID. Some of our users woudl have 15 UID's in their Keychain folder.

     

    Access to the created folder is read/write for the user that created the folder and no access to anyone else

     

    No additional steps needed for Mail or any other program, just enter them once logged in and should  be good!

     

    Hope this helps

     

    Adi

  • by Douglas155,

    Douglas155 Douglas155 Apr 5, 2016 1:50 PM in response to PSC-Admin
    Level 1 (9 points)
    Apr 5, 2016 1:50 PM in response to PSC-Admin

    Hi Adi,

     

    Thanks for this workaround! It has helped with our users that need to log into different stations. Things are mostly working well, but we have users that access a terminal server using either Parallels Client or Microsoft Remote Desktop. For some reason, these two applications can't save passwords to the redirected keychain and I can't seem to figure out why. The password seems to stick, but once the application is quit, the password is gone. Have you run into this with any other applications? Passwords save and are stored for CalDAV, CardDAV, and email just fine, as well as file sharing and Filemaker.

     

    Thanks for any insight.

     

    Doug

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 May 17, 2016 7:22 AM in response to Christoph Ewering1
    Level 1 (18 points)
    Mac OS X
    May 17, 2016 7:22 AM in response to Christoph Ewering1

    Hello guys!

     

    Just that no information is lost - at the other thread I released a new script thats a lot easier and works as expected. It is based on the knowledge of lots of community members.

     

    Bye

    Christoph

     

    #! /bin/bash 

    # logout-fix.sh 

     

     

    # This script runs as a logouthook to fix bugs that Apple should have fixed

    # The bug occurs to network home users only because since OS X 10.9.x not all processes

    # of a user that logs out get killed. It is a workaround developed by Luda24,

    # John Lockwood, Christoph Ewering, Benjamin Losch and may others at the

    # Apple Support Communities

     

     

    # Once again - this is a workaround that works with OS X 10.9.x to 10.11.5

    # (shame on Apple for ignoring many bug reports and feedbacks about this bug)

     

     

    # You should store this script at /usr/local/bin and then run

    # "sudo defaults write com.apple.loginwindow LogoutHook /usr/local/bin/logout-fix.sh"

    # remember to set the access rights "sudo chmod 755 /usr/local/bin/logout-fix.sh"

    # and owner to "chown root:wheel /usr/local/bin/logout-fix.sh"

     

     

    # And here it is what this script does:

    # 1. Check if the logging out user is a local or network user

    # 2. Kill left running processes of the logged out user

    # 3. Unmount Network-Share that may have been left mounted

    # 4. Remove cache files from /private/var/folders that are owned by user $username

     

     

    # Here you can select if you want to any feature disabled or enabled

    UNMOUNTHOME=1

    CLEANCACHE=1

     

     

    # Do not change anything after this line

    username=$1

    /usr/bin/logger "logout-fix.sh $username" 

     

    Local=`dscl . -list /Users |grep -x $username` 

    if [[ "$1" == "$Local" ]]

    then 

        /usr/bin/logger "logout-fix.sh has nothing to do - logged out user was a local user"

        exit 0 

    fi 

     

    # Here is the important part - kill users processes - first of all „secinitd“ and „secd“

    /usr/bin/logger "logout-fix.sh trying to kill all processes of user $username"

    /usr/bin/killall -15 -u $username

    /bin/sleep 5

    /usr/bin/killall -9 -u $username 

     

     

    # Unmount network home directory share if left mounted after user logs out

    if [ $UNMOUNTHOME ]; then

      mountpath=`mount | grep /Network/Servers/  | awk '{print $3}'` 

      if [ "$mountpath" != "" ] 

      then

       /usr/bin/logger "logout-fix.sh trying to unmount $mountpath"

       /sbin/umount -f $mountpath 

       /usr/bin/logger "LogoutHook unmounted: $mountpath " 

      fi

    fi

     

     

     

     

    # Delete old stuff from /private/var/folders - mainly cache files after user logs out

    if [ $CLEANCACHE ]; then

        /usr/bin/logger "logout-fix.sh trying to clean cache files of user $username"

      /usr/bin/find /private/var/folders/* -type d -mtime 1 —user $username -exec rm -vrf {} \;

    fi

     

     

    /usr/bin/logger "logout-fix.sh finished for $1" 

     

    exit 0

Previous Page 2