3: Understanding Directory Services in Font

Printer QR Code ISO/IEC18004 in Font 3: Understanding Directory Services

The two directories need not be Active Directory and Open Directory; you might set up a magic triangle where both directories were LDAPv3 directories. One LDAPv3 directory service might be a large education site s central directory, and the other LDAPv3 directory might be a small department s directory server running on a Fedora box. Starting with Mac OS X 10.5 Leopard, Apple extended the ideas behind the Magic Triangle or Dual Directory by introducing augmented records. Augmented records allow a Mac OS X administrator to virtually add additional attributes to a record in an existing directory service by creating a related record in a secondary directory service. For example, this allows you to add Mac-specific attributes to user records coming from a central network directory service without having to modify the records in the central service. Mac OS X virtually merges the data coming from both directory services to make a single virtual record containing all the attributes from both directories. You could use augmented records on an Open Directory server to store managed preferences data for a user account stored in an Active Directory domain. Later in this book, we ll also look at another variation on the idea of supplementing a central directory by storing managed preferences data in another directory. Specifically, we ll describe using a local directory data store for managed preferences data in conjunction with Active Directory or a third-party LDAPv3 directory.

Summary

In this chapter we ve presented a quick introduction to directory services. We discussed the various directory services supported by Mac OS X and talked about common directory service configurations. We also noted how directory services and managed preferences are connected----on Mac OS X, managed preferences are stored in a directory service. We ll get into the details of this in 5, Delivering Managed Preferences.

The property list file format (.plist) is at the heart of many operations in Mac OS X. As a well-structured XML document, the .plist format is easy to parse programmatically. The format is important to understand, as Apple s preferences are currently stored in .plist files (however, Apple makes no guarantees of this format going forward). Not coincidentally, Managed Preferences are stored and delivered in a formatted .plist file, too. There are several tools available on Mac OS X that allow you to work with .plist files. These include Property List Editor.app and the plutil, defaults, and PlistBuddy command-line tools. Because .plist is the native format for Managed Preferences, it s essential for an administrator to understand the contents of a .plist file, and how to work with them. Therefore, we start this chapter with an overview of the .plist format, followed by an actual example that shows how Managed Preferences are stored and delivered in a .plist file. We then walk through the aforementioned tools that will help you deal with the .plist format.

Simply put, property list files are well-formed ( structured ) XML files that store keys and values. Keys are like labels or variable names. .plist files store simple hierarchies of data. The types of data that can be stored in a .plist file are ostensibly limited to a few chosen types, but one type----binary data----can effectively store any binary value. The basic types that a .plist file can store are strings, numbers, binary data, dates, and Boolean values. There are also container types. A container isn t any type itself, but contains basic types or other containers. The container types are arrays and dictionaries.

NOTE: These types weren t chosen arbitrarily: each type in a property list file has a corresponding class in Apple s programming frameworks, specifically the NSDictionary class. The NSDictionary class has methods that read and write .plist files (Table 4-1).