10.9: “OS X wants to use the ‘Local Items’ keychain”

[rsterner]

With Mavericks I’ve been getting a “OS X wants to use the ‘Local Items’ keychain” message when a new user logs on:

Entering the local Administrator password lets me continue. The problem is that our users are not given the local Admin password.

Here are the details:

• Started with clean 10.9 install
• Added required apps
• Customized Mac OS User Template:
o su -
o rm -r /System/Library/User Template/English.lproj/*
o cp -R /Users/test/* /System/Library/User Template/English.lproj/
• Capture image with Casper Composer 9.2
• Image MacBook Pro using Casper Imaging 9.2
• Managed by JAMF JSS 9.2
• Join CSUS Domain (Mobile Accounts enabled)
• Login with SacLink Username and Password
• Dialog Appears: “OS X wants to use the ‘Local Items’ keychain”
• Enter “Administrator” password that was created when Mavericks was originally installed for the new image.

My concern is how to avoid having a new user enter our secret Administrator password at their first login.

[lashomb]

This is a bug in Mavericks... if you go into ~/Library/Keychains, you'll see a folder with a name like 94ED610F-DD96-4ECF-A2BC-7D2F8651A464 (unique to your system). Delete it, reboot and everything returns to normal.

[appledes]

We had the same issue. We like using standard default templates for all users and this was getting in the way. This fix worked for us as well. Thank you.

[scottb]

I'm not sure that's a "bug", per se. (but it would be for a user template)
I was looking at this prior for another reason during testing.

I did this:

Turned off iCloud Keychains.
Deleted the ~/Library/Keychains/FOLDER WITH LONG NAME
Logged out/in.
Turned on iCloud Keychains.
New ~/Library/Keychains/FOLDER WITH LONG NAME created.
So, if you’re not using it, it sounds like it’s safe to nuke. If you or your clients are using iCloud keychains, I believe that's the folder it's using. Just a quick data point. There may be more to this.

[Kumarasinghe]

I had this issue when I compiled InstallESD using Casper Admin. Maybe something has got corrupted while compiling the image but now I use AutoDMG and not having this issue anymore.

[rsterner]

Thanks, Lashomb and the rest of you for your information. I have tried Lashomb's suggestion, and it appears to fix my problem. I did find that I could not empty the trash after deleting those folders, so I forced it with a Terminal command.

[michaelhusar]

In connection to manipulation of the user template:

I have Windows SMB FIler for the Userhomes. The Filer has trouble with translating the ACL "everyone deny delete".
So I deleted the ACL in the User Templates. But Mavericks seems to create the ACL anyway...

Did you succeed somehow to create user homes without any ACL from the very start ? (I made a launchdaemon to delete the ACL but it seems to kick in too late)

[clifhirtle]

If the Local Items keychain is simply what is iCloud sync eligible I would not assume that deleting it would have an downsides related to FileVault (keys, etc), correct? @rtrouton have you seen any issues related to Local Items and FileVault?

[rtrouton]

No, I haven't. As long as the keychain is user-specific, there shouldn't be any FileVault 2-related effects to deleting it.

[makander]

I started noticing this as well. Is there anyway of automating the removal of that keychain folder?

[arlomiller]

For me, I've found that all network users with network homes run into problems with mail b/c of this stupid thing. Mail will put their passwords for imap/smpt into the local items keychain, which means that when they login to a new computer they have to re-enter them. painful.

[bentoms]

I think the prompts for access to the "local items" keychain was mentioned as fixed with 10.9.2.

[moonan]

The 10.9.2 notes implied it was fixed but so far it's still a problem...

[michaelhusar]

Fresh install of 10.9.2 and also encountering the issue - we use PHS-mobile homes is syncing the library with the keychain…

[bentoms]

Had the same issue on 10.9.2.. @Kumarasinghe's post pointed me to try AutoDMG.. & now the issue has been resolved..

So seems Casper Admin compilation is the issue.

[bentoms]

Scratch that.. tested more via AutoDMG.. Casper compiled & MAS "clean".. same issue.

Posted my findings: http://macmule.com/2014/03/30/the-local-items-keychain-in-mavericks/

Even forked ADPassMon to resolve this as keychain minder wouldn't create new keychain: http://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/

BUT, it looks like this issue is affecting only a few of us :(

Can those of you unaffected test something for me & report back?

1. Log into a mac with an account
2. Log out
3. Change accounts password via either AD or users & groups without the user logged in
4. Log back into the mac with the same user account as step 1, if prompted to updated keychain.. click "Create New" or create new via keychain minder.

After step 4 you should be prompted for the "Local Items" keychain password, but if it's been forgotten.. then you're a little stuck with no login.keychain.

[#17]

Upgraded a dozen existing ML laptop users to 10.9.2 via Self Serve method, just one user had the Local Items dialog after logging in - didn't have the "LONG FOLDER NAME" in /Library/Keychains either. Going to start testing the forked ADPassMon.

[bthomason]

I am having this issue when I create a standard user.

[makander]

Is this fixed in 10.9.3?

[bthomason]

No it's not fixed in 10.9.3. I am having the weirdest issues. It seems if I use disk utility to restore the image it works fine, but if I use CasperImaging it gets the KeyChain Error. I'm not bound to any Directory service, just local accounts.

[bentoms]

@bthomason, when deoloying via Casper Imaging.. Are you also deploying other packages?

[Look]

I fixed an issue with new user Keychains simply by adding the empty folder:
/System/Library/User Template/English.lproj/Library/Keychains
It was a slightly different issue where we were getting a file (as opposed to a folder) called Keychains being created that was preventing the creation of the Keychains folder for any new users, however it's possible it might fix this issue as well.
Not sure of the implications of this method but it certainly seems to work on the machines I have tried it on.

[justinworkman]

@Look your solution seemed to fix the problem for me on an AD bound computer.