You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Erich Wetzel Author

Level 2

384 points

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:34 PM

Top-ranking reply

John Lockwood

Level 6

13,691 points

Posted on Jan 28, 2017 12:32 PM

It is our experience that it is still problem, in fact several different problems. 😟

Whilst there are many issues two of the major ones are -

The 'new' local items keychain used for Apple programs passwords e.g. Mail, Contacts, etc. is stored in a per machine specific folder rendering it unusable for hot-desking
Each new version of OS X has increased the use of SQLite databases to store settings and data and when used over a network as with network home directories these either get corrupted or locked so they cannot be used making programs like Mail, Contacts, and even Safari unusable, recent new uses include local items keychain itself and the new suggestions database for spotlight and looking up contacts and calendar entries in emails etc.

While I am still in the processing of reporting these issues to Apple especially the new SQLite problems I am in the process of changing all our users and giving up on network home directories. 😟

View in context

278 replies

Nov 7, 2014 4:54 AM in response to JD_Zig

I do a step-by-step guide:

1. generate killall script)

- open terminal

- check if /usr/local/ does exist. Do

cd /usr/local/

If this returns "cd: /usr/local/: No such file or directory" create it with

sudo mkdir /usr/local/

it should ask for Password: now, enter your login password.

- type

sudo mkdir /usr/local/scripts

- type

sudo nano /usr/local/scripts/kill_secd.sh

- in the now open text editor within the shell put

killall -SIGHUP secd

in and pres ctrl-o and then enter, which saves the text to the script. press ctrl-x to leave the editor.

- type

more /usr/local/scripts/kill_secd.sh

to check if the nano operation was successful. it should print "killall -SIGHUP secd" as answer.

2. generate LaunchAgent script)

- type

sudo nano /Library/LaunchAgents/tld.domain.name.plist

where "tld.domain.name.plist" is just a placeholder for something like "com.yourdomain.nameofthescript.plist".

-in the now open editor paste

<?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>

into it and pres ctrl-o and then enter, which saves the text to the script. press ctrl-x to leave the editor.

-type

more /Library/LaunchAgents/tld.domain.name.plist (replace with your name of file!!!!)

to check if the nano operation was successful. it should print now the content of the script as answer.

3. make executable)

-type

sudo chmod +x /usr/local/scripts/kill_secd.sh

and

sudo chmod +x /Library/LaunchAgents/tld.domain.name.plist (replace with your name of file!!!!)

-type

ls -la /usr/local/scripts/

that should print (maybe among other things) the rights of the kill script:

drwxr-xr-x 3 root wheel 102 7 Nov 13:23 .

drwxr-xr-x@ 6 root wheel 204 7 Nov 13:17 ..

-rwxr-xr-x 1 root wheel 21 7 Nov 13:27 kill_secd.sh

if you want to check the rights of the LaunchAgent script do

ls -la /Library/LaunchAgents/tld.domain.name.plist (replace with your name of file!!!!)

4. that's it)

- close terminal, logout of the current User, log in again. That should do it.

JD_Zig

Level 1

5 points

Nov 7, 2014 10:41 AM in response to Benjamin Losch

Thanks Benjamin! the step by step works great. It fixed my mail problem. However a related problem I am having I was hoping it would fix as well. We use imessages and without restarting the client in between log ins previous conversations do not sync. You are able to create new conversations but any old conversations will not sync.. I was hoping this script would fix it as well. Any ideas on how to fix the iMessage problem? Thanks in advance.

bsandor

Level 1

0 points

Nov 12, 2014 6:29 AM in response to Erich Wetzel

I recently stumbled on this thread, and am hoping it will provide me some help. I have been having network account issues since moving to Mavericks (actually, we have been having ever-changing AFP issues since leaving Snow Leopard), but have been having trouble finding others with the same problem as me. We are also experiencing the Mail login issue, but that is a minor annoyance compared to the main problem. Mainly on the accounts that periodically switch computers (which is why we have network accounts with network home folders), the account periodically stops working all together. The user can log in, but then the computer completely freezes after a few seconds. I have tried everything I can think of, but the only solution is to backup then delete the user's home folder from the server, then create a new user home folder and manually copy their data (Documents, Desktop, a few preference files, etc.) back from the backup, then resync their email and calendars from the server after first login. Apple Support implies it is a known AFP bug, but offers no solution yet. I am considering moving to Yosemite in hopes that will fix it, but would like hear if anyone has had luck with this first.

Nov 12, 2014 9:39 AM in response to bsandor

I am using ARUH since the first OS X Server Version and i never had something like this.

As a quick fix you could change the used protocol from AFP to SMB?

Erich Wetzel Author

Level 2

384 points

Nov 12, 2014 9:48 AM in response to bsandor

I have had a problem like that in the past. I have not had any trouble with that issue since moving to 10.10 Server 4 and 10.10 clients and using SMB for all connections.

JD_Zig

Level 1

5 points

Nov 13, 2014 8:26 AM in response to Erich Wetzel

Hi Erich, In server app 4 what settings do you have? Share home folders over SMB? Encrypt connection? Also are you also selecting share over AFP and SMB? We are using Yosemite clients will just setting share home folders to SMB force it to be SMB3?

Also for bsandor, we use to have the freezing issue and found out that it was a cache issue. The fix is deleting cache folder first then in WGM setting up cache redirection. Here is a link to setting it up: http://houseofmac.wordpress.com/2010/11/03/os-x-network-home-folder-redirection/

Nov 13, 2014 8:45 AM in response to JD_Zig

can you still setup cache folder redirection using WGM on a yosemite server?

Erich Wetzel Author

Level 2

384 points

Nov 13, 2014 10:01 AM in response to JD_Zig

My current settings for the home folder we have set up are:

Share via AFP and SMB

No encryption or allow guest access

Make available for home directories via SMB

Erich Wetzel Author

Level 2

384 points

Nov 13, 2014 10:14 AM in response to ajm_from_WA

I Imagine that you could use WGM for cache redirect via MCX as most of the preference items are still in there.

I am using Profile Manager and do not know how to do the redirect with it.

Apple is getting away from MCX as I understand it though.

Erich Wetzel Author

Level 2

384 points

Nov 13, 2014 10:34 AM in response to ajm_from_WA

Just set up the redirection via WGM and MCX on 10.10

I will start a new discussion asking for advice on the same for Profile Manager.

Erich Wetzel Author

Level 2

384 points

Nov 20, 2014 3:27 PM in response to Erich Wetzel

Possible new issue related to all of this.

Updated clients to 10.10.1 and Mail.app has begun dropping an established connection to the mail server which in our case is a 10.9.x Server 3 machine. Mail.app then asks for passwords; which of course are never accepted unless a reboot is made. The mail server is fine and can be accessed from other devices with no trouble. More of the same I suppose.

bsandor

Level 1

0 points

Dec 1, 2014 11:47 AM in response to Erich Wetzel

So, I upgraded all the clients and the server to Yosemite this weekend - which of course loaded 10.10.1. Also changed the home folder share to SMB. I won't know for a while about the frozen accounts issue for a while (thank you JD_Zig - I also implemented your suggestion for the cache redirection).

BUT - now I have frequent email disconnect issues, much more than I had before with 10.9.5 and AFP.

Rebooting seems to temporarily fix it, but that is complicated by a MacPractice bug we now have with 10.10 that flairs up every time we reboot a workstation.

This is beyond frustrating. I would go back to 10.6 if I could.

Dec 10, 2014 7:43 AM in response to Erich Wetzel

I found this now unusable, too. Since the 10.10.1 update the passwords are stored if you enter them in

mail, if you logout of the user account and log back in, they are gone and are not accepted at login. Only

a reboot helps momentary... With or without kill script. Sad.

Erich Wetzel Author

Level 2

384 points

Dec 10, 2014 7:56 AM in response to Benjamin Losch

I have found the same result as Benjamin Losch. We have gone back to reboot on every logout. That does not stop the periodic failure of Messages to keep the messages and problems with Mail requesting passwords seemingly at random. When those two events happen, we immediately reboot and login seems to get back to normal.

For anyone who has not, please contact Apple enterprise and let them know of our concerns. They told me that there is a team working on this exact issue. Interesting how iPhone updates for lost ringtones are addressed quickly and this issue has lingered since my first post nearly a year and a full OS ago.

Dec 10, 2014 8:15 AM in response to Erich Wetzel

You are so right. I do not understand why this mayor bug could be around such a long time. I fear it has to do with fast declining importance of pro solutions.

Mavericks Server Keychain not properly storing information network users.