Robert Hrovat

Q: Keychain issue with network users on 10.10 clients

Hello everybody

 

I've got a keychain issue with network user homes connecting form 10.10 clients to a 3.2.2 server:

 

After upgrading some clients to 10.10, our students started to complain: They had to enter passwords again and again. It looked like the passwords wouldn't save in their keychain.

When I checked their "local items" keychain, it was empty and no new data could be saved in there.

This caused of course a lot of following issues with a lot of other apps.

 

So I started testing with a brand new user on a 10.10 client. These are the results:

When the user logs in, the keychain "keychain-2.db" is created in ~/Library/Keychains/893693C6-3637-5019-A594-DC4BD648101C

I think this is as it should be, this folder is for this particular client.

When the user logs out and then logs in again, this keychain has changed to "keychain-2.db-corrupt" and no data can be saved in there.

But when I restart the client and then the user logs in again, a new "keychain-2.db" has been created and the corrupt keychain is still there.

The new keychain is empty of course, but new data can be saved in there.

And then, when the user logs out and in again, the whole story starts from beginning.

 

First I thought, it could be because of the "after logout network home directory isn't disconnected from server" problem as it was discussed in other posts. (See also Users not disconnected from file sharing and others.) But it looks like this problem has been solved  in 10.10: When a network user has logged out, there's no more AFP (or SMB) connection visible on the server.

 

So on the client I logged in as a local admin and checked the activity:

Although my test user had just logged out, there were still about 16 processes running under his name. One (or more) of them must have been destroying the "keychain-2.db" and blocking the creation of a new one.

With killing them one by one and a lot of testing I found the guilty one:

It's the process called "secd" that causes this keychain issue.  If I kill this process before the user logs in again, his heychain-2.db won't become corrupt!

 

I have no idea what this process is for and why it is (and all the others processes) still there, after the user's logout.

 

My questions are:

Is this bug or is it a misconfiguration of my clients and/or server?

Does anybody else have the same experiences with accounts on a server 3.2.2? What about server 4.0?

Does anybody have an idea for a workaround?

 

 

Thanks a lot for helping.

 

 

Bob

Posted on Oct 22, 2014 8:49 AM

Close

Q: Keychain issue with network users on 10.10 clients

  • All replies
  • Helpful answers

Previous Page 2 of 3 last Next
  • by Robert Hrovat,

    Robert Hrovat Robert Hrovat Nov 6, 2014 11:54 PM in response to ndsvfx
    Level 1 (9 points)
    Nov 6, 2014 11:54 PM in response to ndsvfx

    I tested the whole thing under the assumption that network users don't use iCloud and that they don't have local mobile home folders.

    The iCloud issue with network users is as old as iCloud itself. A 'genius' in the Apple store told me that iCloud just hasn't been developed to be used in combination with network user accounts. So we decided in our school to block it for the network users. They can live with it so far.

     

    As I mentioned in my original post there are about 16 processes that are still running after a network user has logged out. You can see (and kill) them if you log in as a local admin and open the Activity Monitor. By killing them one by one and trying again and again to log in as a network user you can maybe identify the responsible process that messes up iCloud.

    When identified it's easy to set an additional kill command for that process in the script which is described in the mentioned post.

  • by ndsvfx,

    ndsvfx ndsvfx Nov 7, 2014 11:08 AM in response to Robert Hrovat
    Level 1 (15 points)
    Nov 7, 2014 11:08 AM in response to Robert Hrovat

    turning off iCloud gets rid of the iCloud, iMessage, Facetime popups and most users are not running that there.

     

    But Home Sync at login not running and login keychain password request with HomeSync is still an issue that nothing seems to fix.

     

    It is some order of operations thing where HomeSync must not have the right permissions to access keychain at login, since after you login and enter the keychain password at the prompt, HomeSync happily runs at idle and at logout.

  • by Kevin Neal,

    Kevin Neal Kevin Neal Nov 10, 2014 4:21 AM in response to ndsvfx
    Level 3 (513 points)
    Servers Enterprise
    Nov 10, 2014 4:21 AM in response to ndsvfx

    I have the same problem with Server running 10.8.5 and clients running both 10.9 and 10.10 so I think it is quite a widespread issue

  • by ndsvfx,

    ndsvfx ndsvfx Nov 14, 2014 12:02 PM in response to Robert Hrovat
    Level 1 (15 points)
    Nov 14, 2014 12:02 PM in response to Robert Hrovat

    So a user in another thread found that if you just do a logout and login you do not get the password prompt. But if you do a reboot you do get the password prompt. I tested and confirmed that is indeed correct. So it is definitely a client issue. So something is getting reset at reboot but not logout.

     

    That does not fix HomeSync not running at login so that must be another issue

  • by Marcolepsy,

    Marcolepsy Marcolepsy Dec 14, 2014 1:13 AM in response to Robert Hrovat
    Level 1 (4 points)
    Dec 14, 2014 1:13 AM in response to Robert Hrovat

    I'm having the exact same type of problem, across 2 client sites, though my users don't use iCloud and do use network home folders (not syncing). In my case the passwords for Mail, Contacts, and Calendars are not retained.

     

    After MUCH testing I determined a logout / login combo hoses the Local Items keychain, but a restart does not. Now, WHY the password are stored in the Local Items keychain in the first place, instead of the Login keychain, is beyond me. I've put entries into the Login keychain and they survive just fine...

     

    I've had the issue though 10.8, 10.9, and now 10.10.

     

    Theoretical workaround #1... Has anyone tried using Profile Manager to create a Login Window payload which adds a LogoutHook script to terminate the secd process? This should work in theory...

     

    Theoretical workaround #2... Configure the client OS to store and retrieve the passwords in the Login keychain instead of the Local Items keychain. Does anyone know if this would even be possible, or how to do it?

     

    I'm about to report this to Apple, with my test results to show how I reached my conclusion, and will be including a link to this thread.

  • by Marcolepsy,

    Marcolepsy Marcolepsy Jan 8, 2015 6:05 PM in response to Marcolepsy
    Level 1 (4 points)
    Jan 8, 2015 6:05 PM in response to Marcolepsy

    OK everyone... I spoke to AppleCare Enterprise support, and eventually found that the engineers have been aware of this issue for quite a while, but there's no timeframe on a fix.

     

    In the meantime, an effective workaround is to reboot the Mac instead of log out.

     

    This kills the secd process and the problem does not occur.

     

    I'll keep you posted if there's an actual solution by Apple.

     

    Also, there's a similar (related) issue here... Network login requires client restart

  • by ndsvfx,

    ndsvfx ndsvfx Feb 6, 2015 6:50 PM in response to Marcolepsy
    Level 1 (15 points)
    Feb 6, 2015 6:50 PM in response to Marcolepsy

    Still not fixed in 10.10.3

  • by jreger,

    jreger jreger Jun 25, 2015 11:56 AM in response to ndsvfx
    Level 1 (0 points)
    Jun 25, 2015 11:56 AM in response to ndsvfx

    It is July: I have a school with 140 iMacs.  40 of those have been placed on order, and are capable of Mountain Lion or higher (I believe).  I'm abandoning the good old days (Snow Leopard) for the greener pasture of Yosemite.  I think I just vomited in my mouth, more out of fear than angst.

     

    I setup my test server on Monday, got my imaging all going using deploy studio, got 15 of my clients deployed, and by Tuesday started experimenting.  Quickly found the keychain issue, and by Wednesday resolved that there is little I can do; it stops all of the young kids at school from login w/roaming home folders.  What the heck???

     

    I've been on the phone with Apple Enterprise and Apple Education over the last two days.  They know about the issue.  What now?  Drop back, get older iMacs, and keep rolling with 10.6.8.  Or do I use "Local" folder location on the server.  That works great for MacBook Pro's in our lab, but extending that down to 3rd, 2nd, 1st, K is going to make life difficult for teachers.  Maybe I can use one of these custom logout hooks that actually did not work (the restart trick also does not work, though shutdown and start did).  Maybe I can teach the kids Cmd+Option+p+r?

     

    The good news?  Yosemite server seems to be running fine.

     

    Yosemite client (and previous cousins) seem to be significantly broken.  I've tried 10.10.3 clients bound to brand new 10.10.3 server w/update 3.2.2 and had this issue.  I've also had this exact issue with other clients bound to my snow leopard domain.  All clients were fresh installs (no clones). 

  • by Robert Hrovat,

    Robert Hrovat Robert Hrovat Jun 25, 2015 12:19 PM in response to jreger
    Level 1 (9 points)
    Jun 25, 2015 12:19 PM in response to jreger

    It really looks like Apple is not willing to support school environments with network user accounts anymore but is more interested to push a BYOD strategy where students work with local accounts only.

    So far in our school (130 Macs, 300 network accounts) only the script that Benjamin Losch published on the bottom of page 6 of this thread works fine.

    I installed it on the master Mac an publshed the master image via DeployStudio:

    The keychain issues have gone and with them also the locked file issues of Microsoft Office documents.

  • by jreger,

    jreger jreger Jun 25, 2015 1:53 PM in response to Robert Hrovat
    Level 1 (0 points)
    Jun 25, 2015 1:53 PM in response to Robert Hrovat

    Benjamin Losch, I owe you a beer, wherever you are (maybe he's like Keyser Soze, or should I not say that name?).


    Still, a little irritating that this is not officially addressed.  Maybe I just need to get better at writing scripts.  If I had 2-4 years, maybe I can learn this stuff.

  • by jreger,

    jreger jreger Jun 27, 2015 6:46 AM in response to jreger
    Level 1 (0 points)
    Jun 27, 2015 6:46 AM in response to jreger

    As a followup: using Mr. Losch's script I can properly use home folders when binding my 10.10.3 clients to my 10.6.8 domain (without management of system preferences, to prevent issues when setting up Internet accounts).  I'm still unable to do the same for 10.10.3 clients bound to my new 10.10.3 server (sharing home folder over SMB).  I'll be changing the new server to share AFP to see if that resolves the keychain issues.

  • by John Agapitos,

    John Agapitos John Agapitos Jun 30, 2015 10:21 PM in response to jreger
    Level 1 (29 points)
    Jun 30, 2015 10:21 PM in response to jreger

    Has anyone tried 10.10.4 to see if Apple fixed this issue

  • by lawaidit,

    lawaidit lawaidit Jul 2, 2015 1:20 PM in response to John Agapitos
    Level 1 (8 points)
    Servers Enterprise
    Jul 2, 2015 1:20 PM in response to John Agapitos

    I've tested it in 10.10.4, still no luck.

  • by jreger,

    jreger jreger Jul 3, 2015 1:32 PM in response to lawaidit
    Level 1 (0 points)
    Jul 3, 2015 1:32 PM in response to lawaidit

    Confirmed: same issue with 10.10.4.  Benjamin Losch's script works most of the time.  Only exception is when a network user transitions from an old iMac (2008, 4 Gb min) back to a new one (up to 2014's), and then the user has to reboot (and then all is well).  Have no idea, and no time to address right now...works well enough.

  • by John Agapitos,

    John Agapitos John Agapitos Aug 14, 2015 5:39 AM in response to jreger
    Level 1 (29 points)
    Aug 14, 2015 5:39 AM in response to jreger

    How about 10.10.5

Previous Page 2 of 3 last Next