OS 10.9 Mavericks keeps prompting to unlock "Local Items" keychain

After migrating a machine to Mavericks, or after binding a Mavericks machine to a new domain, we were getting repeated prompts to unlock the "Local Items" keychain.  No password would unlock the items.

The following steps resolve the problem:

• Go to ~/Library/Keychains (user's Keychain folder)
• Look for a folder that is a long series of numbers and letters: "ADS676BB8-CEJD-45..."
• Delete the folder and IMMEDIATELY restart the Mac

You should no longer be prompted for the Local Items keychain password.

Note: after you restart a new folder with a similar name as the old one (a long series of numbers and letters) will appear in ~/Library/Keychains.  Don't panic, this is normal behaviour.  The new folder corrects the problem.

Unable to search the GAL in Lync 14 on 10.9 Macs

We have received many reports that OS 10.9 Macs using Lync 14 are unable to search the Global Address List (GAL).  When a name is entered into the search field no results are returned.

The root cause appears to be two missing files in the user's Microsoft Lync Data/[user's sip name] folder:  GalContacts.db and GalContacts.db.idx

If a computer that was running Lync 14 was upgraded to 10.9 from 10.8 or earlier there is no problem searching the GAL from within Lync.  The problem occurs on 10.9 Macs with fresh Lync installs.

The fix is to copy GalContacts.db and GalContacts.db.idx from a working computer to the non-workign 10.9 Mac.

• Install and configure Lync on the 10.9 Mac
• Log into Lync with the user's AD account credentials
• Close Lync
• On a computer that has a working Lync GAL go to ~/Documents/Microsoft User Data/Microsoft Lync Data/
• Open the "sip_[user.name]@[domain.com]" folder.  ie: sip_tom.smith@mydomain.com
• Locate the GalContacts.db and GalContacts.db.idx files and copy them to a USB stick or the network
• On the 10.9 Mac with the new Lync install go to ~/Documents/Microsoft User Data/Microsoft Lync Data/sip_[user.name]@[domain.com] and import GalContacts.db and GalContacts.db.idx files
• Launch Lync and test the GAL search

 

Microsoft Lync Keeps Requesting a Keychain Password for OC_KeyContainer

We have received several reports that Microsoft Lync (version 14.x) was constantly requesting a Keychain Password and displaying the following dialogue box:

The blocked out area shows the user's e-mail address.

On working systems there was an "OC_KeyContainer" in Keychain:

As well as a saved password in Keychain:

On system that had a problem these items were missing.

The solution we found was to go into ~/Library/Keychains and delete the "OC_KeyContainer_[user's e-mail address]. 

Remember that on 10.7 and above the user's library folder is hidden and you must show it by opening Terminal and typing "chflags nohidden /Users/[user's home folder name]/Library

After deleting the OC_KeyContainer file, launch Lync and log in and you should no longer receive the Keychain pop-up.

If you open Keychain Access.app you will notice that a new OC_KeyContainer Keychain and password have been created.

Note: if the OC_KeyContainer Keychain and password already exist in Keychain Access.app, delete them before removing the file from the user's Library folder.

Macs Unable to Connect to Secure Sites: OCSPD File Deleted

We received a report that 400+ Macs in two countries and a dozen locations were suddenly unable to login.  A quick fix was to remove the network cable, log in using the locally cached credentials and then plug the Ethernet cable back in.  However, the users were then unable to connect to any web-page using https, Outlook mail (using OWA) or any other connection that required secure communication.

All the Macs were bound to AD and being managed by Casper.

We soon found that by removing the JAMF binary we were able to log in but we still could not access any secure resources.  This made sense because at login/start-up the computer attempts to talk to the JSS and if secure communication is not possible the computer will hang.

Working with Apple Alliance Support (excellent as always) we were able to determine that the root of the problem lay in the fact that all the computers were missing the ocspd file from /usr/sbin/.  The ocspd file is used during certificate validation and if it is missing or corrupt a secure connection can not be established.

Using Composer we created packages to deploy new ocspd files.  Note: you must install like-for like, i.e. a good ocspd file from a 10.7.5 Mac must be deployed to another 10.7.5 Mac.

Unfortunately within a few minutes of deploying a new ocspd file, it was deleted.  After more digging through logs we found that it was a JAMF process that was causing the deletion so we removed the JAMF binary from all the Macs, pushed the good ocspd packages using ARD and it resolved the issue.

After the good ocspd packages are deployed, remove all the old computers from the JSS, ensure that a valid push-notification certificate is installed and that "enable certificate-based communication" is ticked in the framework settings of the JSS.  You should then be able to re-Recon all your Macs and the ocspd file will not be removed.  TEST FIRST on a few Macs!

If you suspect this issue the first thing to do is go to /usr/sbin and see if the ocspd file is missing.  If it is you must replace it with a known good ocspd file.  As described above, the easiest way to do this is with Casper Composer but if you do not have a copy of it you can do the following steps and deploy using ARD.

• Copy a good ocspd file to /usr/sbin/ to the non-working system
• Set ownership and permissions:

sudo chown root:wheel /usr/sbin/ocspd
sudo chmod 755 /usr/sbin/ocspd

•  Once the file has been copied and permissions applied the issue should be resolved- no reboot is required