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

Erich Wetzel Author

Level 2

384 points

Dec 8, 2015 8:11 AM in response to Erich Wetzel

If you use Profile Manager AND have settings for Loginwindow set up for your managed clients, the great script Christoph has written will not work. There may be other issues related to client management as well.

I also tested this by adding a custom item to Profile Manager with the details to run the script but it appears that the selectable Loginwindow items override the additional custom item I added.

I had the script running manually but it would not run on a log out. After removing all Loginwindow settings from Profile Manager I was able to get the script to run automatically. However, when I logged in the next user I still found 8 or so processes left over. So I am guessing that the attempt to close the processes is working but the KILL request is not being executed on my managed client.

Erich Wetzel Author

Level 2

384 points

Dec 8, 2015 8:19 AM in response to Erich Wetzel

Can someone tell me how to negate this command so I can have the defaults back to the actual default since I need to remove the scripting as it will not work for me due to the Profile Manager conflict.

sudo defaults write com.apple.loginwindow LogoutHook /usr/local/bin/scripts/logout_helper.sh

Thanks

-Erich

Dec 8, 2015 9:13 AM in response to Erich Wetzel

BTW

Your are using the Profile Manager instead of the Workgroup Manager. I gave the Profile Manager a change but I want back to the WGM. I can't to all the control I did with the WGM. I can't understand why apple killed the WGM. The Profile Manager is in my opinion a PlayTool to configure only devices like iPhone & iPad

Gérard

Erich Wetzel Author

Level 2

384 points

Dec 8, 2015 10:06 AM in response to Gerard Dirks

Gerard,

I agree that WGM seemed better thought out and more flexible, but made the choice to go with Profile Manager as it is what Apple supports and WGM has not been updated in years. Over the nearly 25 years I have been doing this, I have found it best to just keep shifting to what Apple supports rather than what I think is best. I have had situations where I held onto the past and found it was much harder to move forward from something that was no longer supported to whatever was up to date.

I had a tough time as a non Unix person moving from all GUI to the current way things are done with a significant amount of command line work. But that's what they are putting out... I had to adapt.

Dec 8, 2015 1:16 PM in response to Erich Wetzel

Hi Erich

I agree with you - Profile Manager will be the future if we like it or not. But sometimes some settings can't be set without Workgroup Manager, that's why I still use it.

There's one thing everybody should know about WGM:

Although Apple sais that it isn't compatible with 10.10 or newer, it still is:

It's true, you can't install it on 10.10 or a newer system - the installer blocks the installation. But if you copy an installed version of WGM from a pre 10.10 system, it works, even under 10.11.1.

Robert

Dec 8, 2015 1:37 PM in response to Robert Hrovat

I use the WGM also in my test envoirement of 10.10 & 10.11. It works in general but when I contact Apple with a problem they refuse to help because the will not support it.

If they tell me how I can use all the features of WGM with the Profile Manager it will be fine, but I never find any comparise Table of both programs

The answer is no. The PM is a *******. I would lovely known why Apple killed such programs and replace them with this useless software. This is named as strategy, but nobody knows what the Apple Strategy is.

They had a smoothly Server 10.6.8 with Server Admin.app & WGM. Never had a problem. Now 5 years later we have a complete buggy envoirement with one of the bugs named in the title of this thread "Mavericks Server Keychain not properly storing" We always learn "never change a winning horse". But Apple change everything and I would say, none of the professional User are satisfy with it!

WHY? Arrogance, or are they really better. It learns they are not better because it doesn't work so the first will be the correct interpretation!!!

Dec 17, 2015 4:13 AM in response to Gerard Dirks

Hello

Yesterday I had an interesting talk with an supporter of the largest swiss-retial-chain. because of problems with one of their clients (a couple of hunderd macs) they escalate a case up to Cupertino.

Resume: Problem is not solved and will not be solved!!! The way of how we are working is a "cul de sac". This is not the way how Apple want that we working, with OpenDirectory, Network Users, etc. This is OK for me. The Problem I have with it is the way "they did not communicate this to their "large accounts" clients.

When you sold hunderds of mac to a client for project and afterward you hear this service will be discontinued, both has a real problem. The client has an not finished project and the dealer had to take this mac back he was not able to integrate this systems in the envoirement of the client

They, Apple, ignore the wishes of the clients, I don't know how to declare this correctly, but for me it is a sign of arrogance!

Gérard

Dec 17, 2015 4:40 AM in response to Gerard Dirks

BTW

I have not renew my developer status at Apple. It is a waste of time and money! This because in my opinion we are not working in a "cul-de-sac"-way, but Apple will be on a "cul-de-sac" with their Marketing & Innovation-Strategy!

Gérard

Dec 17, 2015 11:57 PM in response to Gerard Dirks

For those who don't believe it but are able to understand the german language! Here the answer from one of the Account Managers (from the largest Apple Reseller in Switzerland) to his Client!

Zitat:

Nun haben wir einen Fall via Apple-Schweiz bis Cupertino eskalieren lassen und die Sache ist klar: Apple weiss von den Problemen, wird sie aber nicht (wohl nie) beheben, da die Netzwerkaccounts nicht „ihrer Strategie“ entsprechen….(offiziell bestätigen wird das Apple nie, aber zumindest wir wissen nun, dass wir von Netzwerk- auf lokale Accounts wechseln müssen.

Regards

Gérard

Phipsi

Level 1

0 points

Jan 2, 2016 6:37 AM in response to Gerard Dirks

Ich verstehe immer noch nicht warum das Apple dann im Server vorsieht das man Netzwerk Accounts verwenden kann wenn es sowieso nicht funktioniert.

Jan 14, 2016 7:03 AM in response to Erich Wetzel

We experienced this problem and setup a workaround before finding this forum post.

What we did was redirect ~/Library/Keychains to /Users/Shared/%@/Library/Keychains using MCXRedirector.

In Profile Manager, go to the device group of your computers, then go to custom settings and set this up:

We also redirect Cache and the Adobe folder in Application Support. That's what Item 0 and Item 1 are.

This permanently fixes the prompting for passwords, but it stores the keychain locally, so it won't travel to another computer.

If the keychain really is that important, we can copy it from one computer to the next.

This doesn't affect us much since our users typically only use one computer. We will only have to restore the keychain if we give them a new computer.

Phipsi

Level 1

0 points

Jan 19, 2016 11:43 AM in response to scottsign11

Nice Workarround

macmartin

Level 3

507 points

Jan 24, 2016 1:08 AM in response to Erich Wetzel

In my opinion a server os without having the option to use network accounts is unusable in the long term.

Even Windows server can manage this for decades.

OS X seems to degrade more and more to a colorful toy.

*sigh*

Greetings

macmartin

Level 3

507 points

Jan 24, 2016 1:20 AM in response to scottsign11

I am very interested in your workaround.

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 lokal keychains folders?

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

Best regards

martin

Jan 25, 2016 5:58 AM in response to macmartin

Yes, that stands for the username.

The entire folder stored in the /Users/shared/username has the same permissions as if it were in their own Library. They have permissions but other users don't.

I found that since upon first login, the keychains folder is deleted and a new one is created on the local HDD, you have to restart the computer after they login the first time so it starts using the new keychain.

Mavericks Server Keychain not properly storing information network users.