Defaults, MCX and plists

A stroll through managing user preferences by hand editing Open Directory's MCX attributes.

For all of those apps that don't show up in Workgroup Manager's preferences interface, there may be some hope.

First off let me explain that this is information in it's current form is perhaps more of a parlor game than actual practically useful. For example, by going through the steps we'll outline you'll be able to force preferences for many 3rd party OS X applications. However, with the way Workgroup Manager is currently set up, you'll never be able to use the GUI to manage preferences after doing this, as it will overwrite your changes.

Having said that, this article should give you a much better idea of how to manipulate your system, what managed preferences actually do and how all of these pieces fit together.

1. Defaults

Lazy Cocoa programmers, and these are usually the best kind of Cocoa programmers, won't reinvent the wheel when coding their applications. This means that they'll use the libraries that Apple provides to implement common tasks.

Application preferences are no exception to this. Apple provides the NSUserDefaults Cocoa class to handle most all preference related tasks. Applications using this method don't actually read and write to their own preference files. Instead they register with the user's defaults database which manages on a system-wide basis a user's preferences.

You can get a good example of what's going on by using the defaults command.

defaults read

For example will display all registered preferences that they database currently has.

It's here that our journey starts. We're going to find a preference that we'd like to force on a user, manually add that to the user's MCX attribute in their Open Directory account and then watch as we can now manage applications that we'd otherwise have no way to control.

So to start off with, pick an application that you'd like to manage. To keep things simple I'm going to use my app, Keychain Minder, since it only has one preference. However, feel free to use whichever app you'd like.

Before you manage the app, you'll have to run the application so that it can register it's preferences. At this point you'll be able to find out if you're going to have any luck with it or not. Using the defaults command you can search through the defaults database to see how the application registers itself, and what preferences it keeps track of. Developers that play nicely should register their app by using their DNS domain in reverse order followed by the application's name. The idea being that if you paid for your own DNS domain name it's going to be unique to you.

For example, my application registers itself into the database as com.afp548.KeychainMinder. If you've run this app on your machine, you can read it's preferences out of the database.

defaults read com.afp548.KeychainMinder

In our example, we see the one preference key that the application uses.

{CheckLoginKeychain = YES; }

We can change this entry with the defaults command if we wanted to.

defaults write com.afp548.KeychainMinder '{CheckLoginKeychain = NO;}'

Would swap the YES with a NO. You can even write to defaults domains that don't exist. This will cause an appropriate .plist file to be created.

So we now have the information that we need. A default that has been registered in the user's database that we want to manage. In our example, we're going to force the YES so that Keychain Minder always checks to see if the default keychain is unlocked regardless of whether or not the user has edited their local .plist file.

2. Workgroup Manager Customization

You'll want to create a user in Workgroup Manager for testing this out. It's probably easiest if you start off with a managed preference for that user through the GUI. So use WGM to always manage the user's dock preferences so that it's always fully magnified.

Once you've done this you can use the Inspector in WGM, enable this in the preferences if you haven't already, to view the actual contents of the user's record. So select the Inspector bulls-eye then use the pull down menu to select "Users" and pick your test user. If you don't see anything in the right hand side of the window, make sure to select "Accounts" in the toolbar of the WGM window.

Now select the "MCXSettings" attribute and view or edit it (edit only becomes available after you've authenticated using the lock in the upper right hand corner).

Copy the contents of the "Text" window at the top of this drawer. Paste it into a blank file ending in .plist and then open it up by double-clicking it if you have the Developer Tools installed. If you don't have the Dev Tools you won't have Property List Editor installed which is going to make this process much much harder.

Once Property List Editor has opened up, you'll be able to browse this .plist. Click through this and you'll find the file to be rather simple to understand. It's just a listing of application default domains and key/value list of enforced preferences.

Although you could figure this out on your own, it's easiest to now open up your target applications .plist file also. This way you don't have to figure out the .plist syntax for it. Instead you'll be able to just copy from one list to the other.

Once you have them both up, you'll notice that WGM keeps all the MCX listed by the applications default domain name. Using the Property List Editor create a new entry in the mcx_application_data dictionary for the application that you want to manage.

Once you have the entry you can essentially copy in the preferences from the application's actual .plist file. If it seems complicated, you're right it is. It should make sense when you look at the structure. If you're interested in trying to force some preferences and only set once others, just do this in WGM and look at the code that it produces.

When you are finished, use the "Dump" button in Property List Editor to dump the preferences to plaintext xml which you can that paste back into the MCXSettings attribute in WGM. Keep in mind that you'll not be able to use the WGM to manage preferences again, since it will overwrite your customizations when you save.

3. Practical Use

As you've noticed, this is not the easiest way to do things. Hand crafting your own MCX will take some patience, WGM was created for a reason after all! You'll also be giving up your ability to make changes in the GUI.

For some I'm sure these sacrifices will be more than acceptable. WGM restricts you to only managing Apple's software and many admins have need to manage other applications that take advantage of NSUserDefaults. For those admins you should now be more than dangerous.