Compositing Preferences

8
Chapter
Compositing Preferences
In previous chapters, we’ve mentioned that you can manage preferences for users,
groups, computers, and computer groups. But what happens if a given preference is
managed for multiple objects? For example, let’s say you manage the Dock settings for
the ‘‘MyOrgUsers’’ group, which contains all the users in your organization, and also
manage the Dock settings for ‘‘Joe User,’’ a specific user in your organization, who also
happens to be a member of ‘‘MyOrgUsers.’’
In this chapter, we’ll be looking at the answers to questions like this. We’ll examine how
managed preferences are combined, or ‘‘composited,’’ and how preferences set at one
level may override those set at another level. We’ll also make some recommendations
for organizing your managed preferences to make it easy to apply policy to most of the
machines in your organization, while still having the flexibility to handle exceptions to
that policy.
Managed Preference Interactions
There are three types of managed preference interactions you should be aware of:

Inheritance
: Groups can contain users and other groups. Computer
groups can contain computers and other computer groups. So
preferences managed for a parent group or computer group are
inherited by the children of that group. If Joe User is a member of
the MyOrgUsers group, preferences set for MyOrgUsers will be
inherited by Joe.

Combined
: Some sets of managed preferences can be combined.
These mostly involve lists of items. For example, you specify that
members of the group MyOrgUsers should have an icon for Firefox

in their Docks, and you also specify that Joe User should have an
icon for Thunderbird in his Dock. Joe will have both Firefox and
Thunderbird in his Dock because these preferences have been
combined from the MyOrgUsers group and the user record for
Joe User.
CHAPTER 8: Compositing Preferences
124

Override
: Most managed preferences don’t lend themselves to
combining because they are a single value rather than a list, and
instead will override the same preference set at another level. If you
had set the Dock for MyOrgUsers to autohide, but set the Dock for Joe
User to not autohide, the user-level setting overrides the group-level
setting, and, so, for Joe, his Dock would not autohide.
Preferences Precedence
The managed preference interactions of ‘‘Inheritance’’ and ‘‘Combined’’ are fairly easy to
understand. A user inherits managed preferences from all the objects the user or the
u s e r ’ s c o m p uter is a membe r o f -----groups of users, computer groups, and the specific
user and computer objects that correspond to the user account and the computer.
Managed preferences that don’t conflict with one another are combined.
However, in the case where preferences set at one level conflict with preferences set at
a n o t h e r l e v e l , i t ’ s h e l p f u l t o k n o w t h e o r d e r o f p r e c e d e n c e -----that is, the order in which
one level overrides another. Here’s the order, with highest precedence on top:
 User
 Computer
 Computer Group
 Group (of users)
A preference set at the computer level would override a preference set at the group
level. Preferences set for individual users have the highest precedence. This is a useful

arrangement that neatly solves a common problem. Let’s say your organization has
decided, in the interests of security, to enforce a password-protected screen saver to
activate after five minutes of inactivity. Since this policy should apply to all machines,
you apply it at the computer group level, to a group that includes all the computers in
your organization. Shortly after your implementation, an executive vice president calls
tech support to complain about this screen saver. After heated discussion, it is decided
to relax the policy for this user only. You could then set a more relaxed screen saver
policy at the user level for the vice president. Since user-level managed preferences
have precedence over computer group---level managed preferences, the vice president
gets what he wants.
This precedence of managed preferences suggests a strategy to use when
implementing your managed preferences. Preferences that should apply to all users in
your organization might be best applied at the computer group level. These managed
preferences will take effect for all users of a given machine-----even local users that do
not have network directory accounts.

CHAPTER 8: Compositing Preferences
125
NOTE: This is an important point to remember. Preferences managed for computers or
computer groups apply to
all
users of a given machine. If you need to make sure that even
newly created local users on a machine get certain settings, managing those settings at the
computer or computer group level is the way to go.
Preferences that affect a certain group of users (like a department, or students vs.
teachers), but not another group of users, should be applied at the group level. This is
most useful when different users might log into a single machine. Students might log
into a machine and find a very locked-down environment with a tightly restricted list of
available applications. But a teacher could log into the same machine and have more
options available to him or her.

These are not either/or, but can be used in combination. You can set the preferences
that apply to everyone at the computer group level, and set preferences for groups with
special needs at the group level, as long as you remember that groups have the lowest
p r i o r i t y -----that is, preferences you set for computer groups will always take precedence
over similar preferences set for a group of users.
Finally, exceptions to general policies can then be applied at the computer or user level.
You might disable CD/DVD burning on all your machines as a policy, and then override
that policy on one specific machine by managing the preferences for its specific
computer object differently.
Preferences and Group Hierarchy
Users can belong to more than one group. Computers can belong to more than one
computer group. Groups can be members of other groups, and computer groups can be
members of other computer groups. While powerful and flexible, this arrangement can
also lead to complexity and confusion. If a computer is a member of two computer
g r o u p s ----- o n e s e t t o a u t o h i d e t h e D o c k a n d t h e o t h e r s e t t o n o t a u t o h i d e t h e D o c k -----it
can be hard to predict which preferences the individual computer will get. (While you
might be able to discern a pattern in this scenario, the rules for how these conflicts are
resolved have not been documented by Apple and so may change in a future release of
OS X.)
Your best strategy is to avoid this situation. Keep your group and computer group
memberships simple and easy to understand. I like to create computer groups for very
specific sets of managed preferences: a computer group called ‘‘LoginWindow’’
contains all our organization’s managed login window preferences, and all computers
are added to this group. I don’t use hierarchical computer groups (where a computer
group contains other computer groups), but if you do, keep the structure as simple as
you can to prevent unintended managed preference interactions.
CHAPTER 8: Compositing Preferences
126
MCXCompositor
We’ve seen that it is possible to define managed preferences at a variety of levels: user,

group, computer, and computer group. Further, users and computers can be members
of multiple groups. So there is a lot of potential managed preferences data to sort
through to determine which managed preferences actually apply to a given user.
MCXCompositor is a process that runs at login (and other times as well) that does the
work of sorting through all the available managed preferences and compositing them
together for the current user. You do not have to worry about running this tool. Mac OS
X runs it automatically as needed------generally at system startup and at each user login------
but you may be interested in its results.
When MCXCompositor runs, it caches the composited preferences in /Library/Managed
Preferences. This is considered an implementation detail, not to be relied on, and
subject to change in the future. Still, it can be interesting and instructive to browse the
contents of this directory on a managed client.
At the root level of /Library/Managed Preferences, you are likely to see several .plist
files, and one or more subdirectories, each named after a user that has logged into this
machine. An example is shown in Figure 8-1.
Figure 8-1. /Library/Managed Preferences
Download from Wow! eBook <www.wowebook.com>
CHAPTER 8: Compositing Preferences
127
One .plist file on my machine is /Library/Managed Preferences/com.apple.
loginwindow.plist. We can examine it using the defaults command:

> defaults read /Library/Managed\ Preferences/com.apple.loginwindow
{
AdminHostInfo = HostName;
AdminMayDisableMCX = 0;
DisableConsoleAccess = 0;
EnableExternalAccounts = 1;
HideAdminUsers = 0;
HideLocalUsers = 0;

HideMobileAccounts = 0;
IncludeNetworkUser = 0;
RestartDisabled = 0;
RetriesUntilHint = 0;
SHOWFULLNAME = 1;
"SHOWOTHERUSERS_MANAGED" = 1;
ShutDownDisabled = 0;
UseComputerNameForComputerRecordName = 0;
"com.apple.login.mcx.DisableAutoLoginClient" = 1;
"mcx_UseLoginWindowText" = 0;
}

We can use dscl with ---mcxread to compare this with the managed preferences I’ve
assigned to a computer group that my machine is a member of:

> dscl /Search -mcxread /ComputerGroups/loginwindow com.apple.loginwindow
Key: HideLocalUsers
State: always
Value: 0

Key: AdminHostInfo
State: always
Value: HostName

Key: SHOWFULLNAME
State: always
Value: 1

Key: SHOWOTHERUSERS_MANAGED
State: always

Value: 1

Key: HideMobileAccounts
State: always
Value: 0