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.

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

Reply
Question marked as Top-ranking reply

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 -


  1. 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
  2. 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. 😟

278 replies

Nov 4, 2014 4:36 PM in response to Benjamin Losch

Everything was done logged in as a local admin user, in Terminal, using sudo for all commands.


OK. In order to exactly duplicate the procedure I had to manually create usr/local and usr/local/scripts. In addition changing ownership on the scripts I also changed ownership on the new folders.


cd /usr

sudo mkdir local

sudo chmod 777 /usr/local


cd /usr/local

sudo mkdir scripts

sudo chmod 777 /usr/local/scripts


sudo pico /usr/local/kill_secd.sh

Paste content from post into editor

Control-0 to write out file

sudo chmod 777 /usr/local/scripts/kill_secd.sh


sudo pico /Library/LaunchAgents/com.company.killsecd.plist

Paste content from post into editor

Control-0 to write out file

sudo chmod 777 /Library/LaunchAgents/com.company.killsecd.plist


The errors I am getting back are:


11/4/14 7:15:01.268 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.user.501.100025.Aqua) Caller specified a plist with bad ownership/permissions: path = /Library/LaunchAgents/com.company.killsecd.plist, caller = loginwindow.618

11/4/14 7:15:01.268 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.user.501.100025.Aqua) Failed to bootstrap path: path = /Library/LaunchAgents/com.company.killsecd.plist, error = 122: Path had bad ownership/permissions


Manually checked permissions System, Wheel, Everyone; all with Read & Write.


Any ideas?

Nov 4, 2014 5:05 PM in response to Erich Wetzel

I had the same problem at first. I fixed it by doing a Get Info on the local and LauchAgents folders and making sure the permissions were System R/W with everything else Read only. Then I Applied To Enclosed Items, to push those permission down to the scripts. Another thing I did different was logged into the computer as "root" so I'd have the rights to do anything and remain in the GUI. I just needed terminal to do the chmod. You can enable the root user in Directory Editor. Then login in as "Other" and enter root as the username and the password you entered in Directory Editor when you enabled the root user.

Nov 5, 2014 4:23 AM in response to Erich Wetzel

I did it with ARD

(Apple Remote Desktop,

https://itunes.apple.com/de/app/apple-remote-desktop/id409907375?mt=12&uo=4, respectively

https://itunes.apple.com/us/app/apple-remote-desktop/id409907375?mt=12&uo=4for the US-Store)


There you could put files and issue terminal commands to multiple clients at once. Wich did the job for 12 Clients in about 5 Minutes.


Sorry, i did all the Steps i described as root so i had no issues with the rights system.

So if you need advice how to setup the root account in OS X let me know.

Alternatively you could do everything with sudo.


Greetings,

Ben

Nov 5, 2014 8:17 AM in response to Erich Wetzel

Thanks to all who have stuck this out. I have tried and confirmed working with above methods. To reiterate the permissions is important, System (read write and all others no access) but confirmed working on 10.10 client with Server 4.0.

Will try to push out through ARD on another test workstation, as I did it manually on a client machine, but don't see why it wouldn't work.


Thanks again.

Nov 5, 2014 9:36 AM in response to Erich Wetzel

Another issue that I cannot figure out how to get around.


We have users who are limited in the applications that they can run. Those users get a message that they do not have permission to use "kill_secd" when they log in. Profile Manager of course does not recognize the script and does not include it as an application to be allowed.


Outside of allowing all users to use any app on the client machine, any ideas how to get kill_secd allowed?


I'm trying to add /usr/local/scripts/ as a permitted folder and may have answered my own question.

Nov 5, 2014 4:34 PM in response to Philip GW

Yes, me too - with the correct permissions it works, finally!


I think the reason for the wrong permissions is the chmod 777 command:

Every created folder and file has by default the correct permissions: rw for owner (root), r for group and others (-rw-r--r--).

You can list the permissions of the contents of a folder with the command: ls -la /path_to_folder

The created script files are not executable because the x-flag is missing.

chmod 777 sets the x-flag but it also gives write permissions to the group and to others, which is too much (-rwxrwxrwx).

So instead of using chmod 777 you can use chmod +x to set the x-flag without changing the permissions. (-rwxr-xr-x)

Mavericks Server Keychain not properly storing information network users.

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.