Hello

I did a lot of testing and have a small workaround

If the OD-User only logoff their is still a sharepoint connected to the server. When he then want to connect to the server he is able to login but Apple Mail is not able to work with the keychain for this user.

If the OD-User restart his iMac instead of logoff, this user is able to work on another mac without any problem.

So what I now do, is control every evening if their are still any computer have a sharepoint mounted an the server. In the Server.app I disconnect all the open afp connections.

What my real problem is to understand why Apple change the place where IMAP and SMTP Passwords are stored to the "local-items" in the Keychain. Now each OD User needs to login on each mac and enter both Passwords. We have some OD Users who need to work on more as 15 machines. This is ridiculous and not welcome in a business envoirement.

Can some people confirm this is also in their Network a problem?

At last I can't accept the statement from Apple that this bug will not be fixed in 10.9 and we need to update to 10.10. First 10.10 is a bugy as …., ferther 10.10 works in a complete different way and the User need to mount the User Folders over SMB instead AFP. At last 10.10 is a No-Go because their will not be a Workgroupmanager availible for Yosemite.

Please Apple. Take Care about the Business Clients otherwise you will be degraded to a "toys producer" that sell successfully products like iPad, iPhone & iPod but your Enterprise Businesses will be lost as in the middle 90's last century. Much of theses Business Clients will swap back to the product based on a Seattle Based Company

Hello Erich

Did you also tried the Yosemite Update? Was the Problem solved with Yosemite?

I am afraid to do the Update to 10.10 because I am sure afterwards it will generate dozen of new problems

Regards

Gérard

p.s. In Germany their is a proverb: "

vom Regen in die Traufe kommen"

All OS X Server developments after 10.6 are not work to use with. The 10.6 cost about € 1000 but it was worth its money. After it become a US$ 20 App it switch to a "Playmobil-Server" only useable for a home user sharing his sharepoints to his wife and kids.

RIP Apple as Business Supplier! (no xserve, no 17" MacBooks, no Antiglossy Displays)

Did you also tried the Yosemite Update? Was the Problem solved with Yosemite?

I can confirm that we are seeing the keychain issue at login in 10.10.1 and 10.10. 

We do not have an OS X server anymore, only Windows servers.  All clients are set up with mobile accounts in our building, so basically everyone who's using OS X 10.9.x or later is dealing with this annoyance.  I can confirm the following behavior on multiple already-configured machines:

1) After a power cycle, on an Active-Directory-bound mac, logging into a mobile account immediately produces an authentication prompt by HomeSync to unlock the 'Login' keychain.  Clicking 'cancel' at this prompt presents several other authentication prompts from other startup processes.  Entering your password here results in the prompt disappearing and the rest of the user experience goes as expected.

2) After either entering OR NOT entering your password at the HomeSync prompt, if you logout and then log back into that same account, the prompt does not appear - account login proceeds normally.

3) After EVERY reboot, without altering the keychain in any way, the prompts are shown upon logging into a mobile account.  (This is in contrast to other reports that state the opposite: a logout/login reproduces the prompt, but a reboot does not).

4) The suggestions on Apple's forums to reset/delete/recreate the default keychain (via Keychain Access.app AND via terminal and the ~/Library/Keychains/ entries) WILL work for a single reboot.  All subsequent reboots will cause the prompts to re-appear.

5) Attempts to kill the secd process on startup, as indicated in other posts, appears to give mixed results - I need to do more testing here (as do Apple's software engineers.........)  Sometimes the prompts show, sometimes they don't, sometimes the machine seems to hang/stall while logging in.

Again, all of these have been tested on multiple computers running various flavors of OS X beginning with 10.9.2.

Fix this NOW, Apple, seriously.  Or just stop releasing updates/upgrades without first testing them adequately.  You're starting to get worse that MS.

Thanks mbrown.atx

When I read your Thread I would suppose it is probable not occurred by the Server (OS X Server or Windows) but by the normal OS X Clients Mavericks & Yosemite.

I think it is important to known which components are responsible for this Keychain Problems. I think your Windows Server provide a SMB Sharepoints for the User Folders?

Can you or other user can confirm this?

Regards

Gérard

I agree - the issue seems to be on the client side, and does not seem to depend on the server or its type.

All of our mobile user accounts have network home folders which are accessed via AFP and NOT via SMB.  We use ExtremeZ IP's file server software, running on a windows server, and its shares are all offered up via AFP, and we've configured the client computers to create mobile account home folder connections via AFP in Directory Utility.

All of that said, I've found a workaround that I'm still testing:

After being unable to get the prompts to go away with my test machine, I decided to try blowing away the mobile account and starting fresh.  Here's what I did (I'm assuming you already have a working local admin account on the computer - do this from that account):

1. System Prefs->Users and groups->Find the troublesome account and click the '-' to remove it.  Choose the option to leave the home folder intact (do not delete home folder, but delete user account).
2. Rename the deleted account folder to it's original name from an Admin account.  Easiest to do this via terminal with "sudo mv /Users/username\ \(Deleted\) /Users/username", where username is the user's original name.
3. Delete/Move the Library folder from this user's account folder.  With terminal, to delete, "sudo rm -rf /Users/username/Library", or to move, "sudo mv /Users/username/Library /Users/username/Library.backup"
4. Unbind computer from Active Directory, reboot.
5. Log back into local admin account.  Re-bind machine to Active Directory, reboot.
6. Log into troublesome account.

I am still testing this procedure to see what other effects it might have, but thus far it's worked very well. 

At this point, the only thing I can think of that is DIFFERENT on our other machines is that HomeSync's settings were actually altered to fit our environment.  Specifically, we only set automatic syncing to occur every 4-8 hours depending on user preference, and we only sync the Desktop and/or Documents folders.  However, this essentially sets HomeSync to not sync any folders by default, and to do so at login/logout/automatically.

I will post back after I've done more testing, but I suspect attempting to change the sync targets/frequency in any way may end up breaking the keychain again.

I am seeing the exact same issues

OSX 10.10.1 & Server 4 (14S333)

OSX 10.10.1 Clients

Maybe we need to wait till 10.11, but probably the that new OS X will then be castrated to an iOS-Like operating system with missing all the functionality we are talking about here ;-)

I've managed to fix this issue in our environment!  It appears to have been caused by some lingering OS X server settings.

We de-commissioned our 10.6 OS X server app because we felt we could do most of our mac management via scripting and another package deployment/asset tracking tools.  However, even after deleting the server.app from the Applications folder, and upgrading all the way from 10.6 to 10.10 afterwards, it seems some settings were still being pushed out to our clients (crazy as it sounds). 

In particular, the /Library/Managed Preferences/$user folder would, after being deleted from client computers in an attempt to resolve this issue, recreate itself as soon as the mobile account is logged back in.  The FIRST time this happens after deleting the folder, no annoying homesync authentication prompt comes up.  If you leave this folder intact and then reboot, you get the prompt again. 

Realizing this folder is associated with OD and OS X server, I began researching how to completely remove OS X server settings, which led me to this Apple support note: OS X Server (Mavericks): Remove pre-release version before installing OS X Server - Apple Support

After following the removal instructions in step 1, I've been able to create new mobile accounts in 10.10/10.9 clients, alter their homesync settings, and reboot to my heart's content - no more authentication prompts, from homesync or anything else.  For existing mobile accounts, I have had success by first removing the /Library/Managed Preferences/ folder and then rebooting.

It's still early, but so far all accounts on which we've removed the /Library/Managed Preferences/ folder have not recreated it after rebooting, and the authentication prompts have disappeared.

So, if you're getting these homesync authentication prompts at login for mobile accounts in your environment AND you've EVER installed a version of OS X server, this may be the fix for you.

If I find out more specifics, I'll post them here.

I'm joining the club of sites with Network Accounts and Keychain issues.

Server still running 10.7.5 and no upgrade possible because Apple refuses to sell Mavericks Server anymore, but it is mandatory if you want to upgrade to Yosemite.

Clients upgraded from 10.7.5 to 10.9.5. All went well until we started to log in / log out. Then we ran in the problems described in this thread.

Installed the kill script and everything is ok. Except for the 3 new minis we bought last weekend and that are running Yosemite.

The kill script doesn't do enough magic there and the user keeps losing the contents of the Keychain.

What I've noticed so far is that the folder ~/Library/Keychains contains multiple folders with ABCDEFG-ABCD--ABCD-ABCDEFG alike names.

One of those folders belongs to the mini and contains the Keychain file "keychain-2.db". It's visible in the Keychain app as "Local Items".

After logging out and back in, this keychain will be empty and the file name will change to "keychain-2.db-corrupt".

I've deleted this folder and restarted the Mac.

That resulted in a new empty keychain.

But Mail would still refuse to save the e-mail account password.

So I logged in on a 10.9 machine. Located the keychain entry for the mail account in the "Local Items" keychain and copied it to the "login" keychain.

Logged out of that machine and went back to the 10.10 machine.

Logged in and found the mail entry in the "login" keychain. Unfortunately that wasn't enough for Mail. It kept asking for the password.

So I copied the entry from the "login" keychain to the "Local Items" keychain. Started Mail and tadaa!!! No more asking for the password.

Logged out and in and everything bad again.

Restarted the Mac and found a fresh and empty "Local Items" keychain.

Again copied the mail entry from "login" to "Local Items" and verified that Mail would not ask for a password.

Next I changed the permissions on that keychain folder so the owner would only have read access. And set those permissions also on the keychain files in that folder.

Logged out and back in. No luck. Mail again asked for the password. And the "Local Items" keychain was empty according to the Keychain app.

Restarted the Mac and this time no problems! Mail didn't ask for a password and the Keychain app happily reported that there was an entry in the keychain.

It seems that it keeps working, as long as I reboot. Logging out/in is a no go and results in an empty keychain.

Just my 2 cents.

Likewise, same problem, nothing "works" except restarting, this is on 10.10.2 with network home folders.

We have the same problems with 10.2.2, network home folders.

Mail, Calendar, ... works only once or after after restart ! Logout - Login :  Mail asks endless for the passwords.

Now I connected as root from another computer with ssh, and there are many user-processes runnig after logout !!!

If kill them by the Terminal, the network user can login and Mail.app works.

(at)AppleSupport: Please fix the user-logout !!!

Best,

Luda

PS.

Running processes after logout:

Load Avg: 0.94, 0.89, 0.84  CPU usage: 0.0% user, 0.49% sys, 99.50% idle   SharedLibs: 19M resident, 23M data, 0B linkedit. MemRegions: 10456 total, 531M resident, 48M private, 154M shared. PhysMem: 2219M used (871M wired), 5968M unused.

VM: 312G vsize, 1070M framework vsize, 0(0) swapins, 0(0) swapouts. Networks: packets: 1924662/775M in, 1960823/1098M out. Disks: 48198/1685M read, 28117/587M written.

Hello

I would like to know if their is a difference between the following clients?

1) Clienst wo have been clean installed with 10.9 or 10.10

2) Clienst wo have been upgraded through the years (e.g. 10.4 to 10.6, 10.6 to 10.9)?

If yes is their a difference between cliens wo updated directly from 10.6 to 10.9 or clients, have been updated from 10.6 to 10.7 to 10.8 to 10.9?

I suppose their must be a difference. Clients 1) & 2)

Regards

Gérard

Hello,

We moved from NFS server to OS X server. The idea was to allow spotlight indexing in mail app. First we go back to 10.6.8 server version, all newer being just for playing. Then we lost all the local keychains items as other peoples in that post. Killing secd process was not satisfactory because login again  on the same account made mail apps unresponsive. We write a LogoutHook with that script:

#!/bin/bash

killall -9 secinitd

killall -9 secd

exit

The local items are right, and mail is running after logging again.

Thanks to everybody here, and good luck.

Raoul.

The client version is 10.10.2