Managing system.keychain

From radmind

How to manage the system keychain will depend on what services are required and managed at your installation.

The system keychain is located at:

/Library/Keychains/System.keychain

An incomplete list of items stored in the system keychain:

• Local KDC certs and keys (Machine specific)
• Local System Default certs and keys (Machine specific)
• Auto connect WiFi Passwords (may be machine specific depending on usage)
• VPN passwords

Because of the amount of machine specific information stored, most people will include it in a negative, but depending on how your base image is laid down - you will need to ensure that is properly created on first boot.

OS X Installer creates a onetime launchd item for this at: /System/Library/LaunchDaemons/com.apple.configureLocalKDC.plist

This calls

/usr/libexec/configureLocalKDC

So if your base image contains no system.keychain - or you want to create a fresh one on first boot manually the steps are:

# test for presence, zero-length, or delete as preferred
systemkeychain -C
/usr/libexec/configureLocalKDC

Creating a system keychain will also set/create /private/var/db/SystemKey which is used by the system to unlock the system.keychain and this file must be managed with system.keychain as a set (either in positive or negative space)

One a related note, 10.5 introduces a local KDC with a number of machine specific keys. Some of this information is stored in the system.keychain, while much of it is kept in

/private/var/db/krb5kdc

which is also set up by the configureLocalKDC and this should be considered when specifying both your negative space and your first boot process.

How critical managing this may depend on the complexity of your environment. OS X will boot and run fine with a positively managed blank system.keychain - but any services that rely on a proper local KDC or any other items stored in system.keychain will not work properly and tracing some of these issues back to a improperly managed system.keychain may not be obvious.

note most of the information in this article was gleaned from mailing list posts from Wout Mertens and Greg Neagle - thanks to them for their original investigations