Mavericks Server Keychain not properly storing information network users.

I just created a test environment using Yosemite Server (4.0) and a Yosemite client. I could bounce back and forth between two network users (who's home folder's reside on the server) and Mail would properly log in every time; HOWEVER, Safari's saved passwords would get hosed and new ones could not be added unless I wiped out the network user's Keychains folder, forcing the system to recreate them. They would function properly until I switched between network users then the keychain would get corrupted again. While this is obviously disheartening, I did speak with a senior level support agent and we recreated the whole thing while he was screen sharing. He is attempting to replicate the issue on his system. Assuming he can, he will escalate it engineering. I feel optimistic that this may be fixed once and for all. I pointed him to this thread for extra information. Hopefully, they will get to the bottom of this. I don't understand the point of Network Users with Network Home Folders, if it flat doesn't work. I also don't understand why such a bug for a basic function of Server would get put off soooo long. It points to a lack of focus to small business users whose demographic seems to be what the Server app is for in the first place. PLEASE APPLE, CARE ABOUT US!

I have also created a test environment using Yosemite Server (4.0) and a Yosemite client (10.10). We are trying to use Network users and Network homes as others in this thread have been. Unfortunately we still have issues with passwords not sticking in Apple Mail/ Contacts/ and Calendars. If I reboot workstation, you can re-enter the password at the prompt and it saves in local items keychain. If you log-out and try to log-in (even with same user) the item is missing from keychain, and no matter how many times you enter the password in Apple Mail /Contacts / Calendars it will not connect unless you reboot and still re-enter password.

We don't want our users to know their mail passwords, so this is not an option even if we forced them to reboot every time they logged out.

Issue is the same whether profile has been created with Profile Manager or entered manually on the workstation.

This issue is not solved on Yosemite. I will follow up with Enterprise Support later today, and submit bug report.

Hello Erich

I have the same problem so I've been doing some testing and narrowed the problem down to one of the users' s processes that is still running after he had logged out.

I posted my results here (sorry, no solution):

Keychain issue with network users on 10.10 clients

Can you confirm my experience with the "secd" process as described in my post?

Hello Robert,

I have also set up a test environment with 10.10 and Server 4 and can confirm that the "secd" process is the culprit here. When the process is killed before the same user or another user logs in, the keychain works. I'm not sure why so many processes are still running for the logged out user. They seem to stay running even when other users log in and only seem to be cleared with a restart.

A logout script that kills the 'secd' process could be a workaround.

AMI289 wrote a similar script at the end of this post:

Re: Home folder unavailable after logout

The script forces the client to unmount a server volume when a user logs out.

I tested this script, it works well with 10.9 clients but it doesn't solve the secd problem of course.

It should be possible to modify this script that it kills the secd-process instead of unmounting a volume.

I'm not good in terminal commands and don't know how to kill a process that is identified by its name and not by its process ID (pid).

Does anyone know how to do that?

Robert

I think I might have a solution for some of you; however, the solution requires setting up NFS. By using NFS, the computer mounts a volume at boot (before user login) and if the user's home folder is on that volume, it will treat it like it's on the local hard drive. This will work two pieces of magic:

1) Fix the keychain corruption problems

2) If you are like me, you have a share setup for your company's documents, and fast user switching is out of the question. However, if you use fast user switching with this method, the shared volume mounts with read/write access for the first user AND later users without the first user having to log off first.

If anyone is interested in this, please post back and I will post the steps in detail. My hopes are that someone will be interested and be able to confirm my results.

Here are the GENERAL steps. Again, if you want the details then post back.

1) Install "NFS Manager" on server and clients http://www.bresink.com/osx/NFSManager.html

2) On the server, using NFS Manager, create an NFS export (something like "CompanyVolume") that contains the user's home folders, and if you want, the company's shared folders. Tip: It's easy to move a home folder if you enable the root user and log in as that user. If you do that, all the user's permissions will be copied perfectly to the new location.

3) Use Server.app to change the user's home folder to "Local", but then use Directory Editor to change it to something like: "/CompanyVolume/Users/UserName"

4) On the clients, use NFS Manager to setup an automount (be sure to use the LDAPv3/server node, NOT the Local node. - must be bound to the server when doing this.) Also be sure that when it mounts, the users folder can be found at the exact location as shown in #3 above. I created a folder called CompanyVolume and setup NFS Manger to mount into that folder.

When you are done, you should have a folder on your client called "/CompanyVolume/Users/" which contains the user's home folders. This actually resides on the server. Open Directory tells the computer to log into the account using that home folder path. The computer treats it like a local volume when it's actually on the server.

Using this theory could you use a NAS on the network, like ReadyNas to act as the users home folder store. I'm very interested in finding a solution to this problem as I have put this system in my families small business.

On another note. I'm not entirely sure what has happened but I have lost all my network users in sever app. I'm rebuilding my Mac server on a solid state hard drive. Am I able to import users and/or to re-create and link to their home folder.

Thank

tom

Tom,

On the NAS, I have no experience on that, but from what I've read, Mavericks doesn't play nicely with NAS. I assume same holds true for Yosemite; however, creating an NFS share directly from the server seems to work well and plays nicely with file permissions you setup from the server app.

On your users. Open Directory seems to be very touchy. Be sure to create an OD Archive so you can easily restore it. If using mavericks, also use workgroup manager to export your users and groups. Using workgroup manager does a cleaner / simpler export where an archive will take any issues with it, like certificate problems. The only drawback to using a workgroup manager export is that it will not backup your passwords . With either technique you can restore or import back in. If using yosemite, there is no workgroup manager but there is a way to export users and groups from terminal. I've haven't had to do that YET. Might be something here: http://help.apple.com/advancedserveradmin/mac/10.8/#apd45e62480-b590-4223-86de-3 5407a78c411

i had success creating a simple "script" which kills the security daemon each time a user logs into a client machine.

the script is triggered via lauchd. secd is restarted by the system as needed, which normally means immediately 🙂.

This does the trick for me and enables me to log in different users without loosing mail passwords.

The kill script is somewhat simple:

killall -SIGHUP secd

i called it "kill_secd.sh".

the script which triggers it is somewhat more complex 🙂:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST

1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Label</key>

<string>kill_secd</string>

<key>ProgramArguments</key>

<array>

<string>/usr/local/scripts/kill_secd.sh</string>

</array>

<key>RunAtLoad</key>

<true/>

<key>UserName</key>

<string>root</string>

<key>GroupName</key>

<string>wheel</string>

</dict>

</plist>

lets call it something like apple would like it to be named: tld.domain.name.plist. it has tot be placed in /Library/LaunchAgents/.

Both scripts have to be executable. Execute

chmod 777 filename

on both. As you can see in the second script i put the first one in /usr/local/scripts/, but that one is up to you.

this does work in Mavericks and Yosemite.

The simplest way is always best and thank you Benjamin for your post. It works great on both Mavericks and Yosemite. FINALLY after over a year, a seamless solution with NO thanks to Apple. It's been a long time coming so thank you again!

One note to anyone using this technique, try it first on some poor test user. It didn't work the first time for me. Verify it using logs in console . I didn't have the permissions set up right. Should be read/write for system and readonly for wheel group and everyone.

Thank you very much, it looks like THE solution a lot of admins have been waiting for - but for some reason it doesn't work on my client 10.10 with server 4.0. (Arrrrgh! ;-)

I'm a newbie in terminal commands and scripts, so I'm quite sure that it's my fault. Could anybody help me to find out what I'm doing wrong, please?

What I've done so far:

- copied the 1st script into a TextEdit file and saved it as plain text named "kill_secd.sh" on the desktop.

- opened /usr/local/ and created a folder "scripts" there because there was none. Put the file into that folder.

- executed in terminal the chmod 777 command on the file there.

- copied the 2nd script into a TextEdit file, saved it under the name "tld.domain.name.plist" as plain text on the desktop.

- moved it then into /Library/LaunchAgents/

- executed chmod 777 on that file too

Restarted the Mac and logged in as a network testuser. Logged out and in again, and checked the keychain-2.db. It was broken again.

Checked Activity Monitor, secd was still running. Went to "kill_secd.sh" and told in info window to open with Terminal. It killed the secd immediately.

So I think it might be something wrong with the LaunchAgents script?