The “Local Items” keychain is something that you may have the misfortune of running into when changing passwords via an external directory service due to password expiry or a using forgetting their passwords in Mavericks.

Use utf8 character encoding while reading the private.key and private.key to get a string as content instead of byte array. There are many options available as signOption. To make the JWT efficient we will be using only the following: issuer — Software organization that issues the token. Subject — Intended user of the token. Node wants to use the “Local Items” keychain. Ask Question Asked 2 years, 5 months ago. Repeated “Safari wants to use the 'Local Items' keychain” alert.

I spent some time tackling it when forking ADPassMon to not only update Users passwords not via the pref pane, just through ADPassMon, & then also updating the users keychain password.

Below are my observations on the new keychain.

Contents

Probably not, but I’m sure you’ve heard of iCloud Keychain, this new “Local Items” keychain appears to be where password items that can be synced via the iCloud Keychain are kept (alongside them residing in the Login Keychain if created on the Mac).

Not exactly.

On a Mac running 10.9, open Keychain Access. Below the login keychain you should see the “Local Items” Keychain.

If you click the “Local Items” keychain you may see it populated with various password items, if using iCloud Keychain this will also include passwords saved on other devices connected to your iCloud account.

If you navigate to ~/Library/Keychains/ you’ll notice there is a sub folder which is named like: “A8F5E7B8-CEC1-4479-A7DF-F23CB076C8B8″

This is actually the Macs UUID, which you can get via the below:

Node Wants To Use The Local Items Keychain

Within this folder you’ll see keychain-2.db, this is the actual “Local Items” keychain itself. It’s an SQLLite DB with contents that are obfuscated via some method.

Again, not exactly.

When a users password changes, if they know their old password then things will be fine. They can update both the login & the “Local Items” keychain passwords either when updating their password via the “Users & Groups” pref pane or if using a network login, they can update via the login window.

I think anyone supporting Macs in an environment with expiring/changing passwords would say the same. This is where the “Local Items” keychain becomes a pain.

When prompted to update a keychains password, the user may click “Update Keychain Password”

This should then give a prompt to unlock the “login” keychain.

If the user has forgotten the keychain password, they will then receive prompts to unlock the login keychain.

Familiar enough. We use Keychain Minder to then prompt the users to assist with the users updating, unlocking or creating a new login keychain.

Keychain Minder has been a great aide with this familiar issue over the years, & still works if the user knows their old keychain password.

But when trying to create a new keychain, you’ll again be asked for the “Local Items” keychains password:

If the password is not known, (& by now it is likely the user doesn’t now their “Local Items” keychains password), then Keychain Minder will error:

But the pain doesn’t stop there. If you the go back into Keychain Access you’ll notice that there is no longer a login keychain, just the locked “Local Items” keychain.

If the user then tries to save a password in an app like Safari, they’ll be advised that no keychain can be found & asked to create a new one:

The user will then be prompted to create a new keychain:

One more alert will appear advising that this will delete all their saved passwords:

But, almost immediately after which they’ll be asked to unlock the “Local Items” keychain again:

If the user then tries to update their password via the Users & Groups pref pane, this seems to complete but no login keychain is created & the “Local Items” keychain is still locked.

Worse still, if the user the logs out or restarts, they are presenting with the prompt to unlock the “Local Items” keychain upon login:

Sadly, when using the security create-keychain command in on it’s own to create a new keychain the issue persists. (This is probably the same method employed by Keychain Minder to create new keychains).

In attempting to tackle this issue, I came to the conclusion that some daemon (identityservicesd or securityd) was somehow caching the “Local Items” keychain. Unloading & reloading those daemons was not an option as not all companies will allow their users to be Administrators, & felt too much like a hack for me to proceed with. But I did find an Apple kb article, that details how to stop the “Local Items” keychain prompts.

The above helped me to come to a solution in my forked ADPassMon, when launched it can check to see if the login.keychain is locked:

If the users selects “Create New Keychain” they are then prompted to restart:

Node Wants To Use The Local Items Keychain

The below code snippet of from ADPassMon, in order to resolve this issue I am doing the following:

Getting the Macs UUID
Emptying the folder containing the “Local Items” keychain.
Deleting the login.keychain
Restarting so the daemon processes can do what they need at the next login to create new login & local items keychains.

Node Wants To Use The Local Items Keychain System

I hope this has been helpful, & please check out ADPassMon.