7.1. Managed Preferences
Managed preferences in Mac OS X provide administrators with a valuable tool set for managing many aspects of the Mac OS X computing environment. Their capabilities run a wide berth, providing many functions, such as managing individual userland application settings, applying user restrictions to inserted or removable media, controlling application access, and deploying network proxy settings. And they can also provide for managing computer hardware energy saver settings, including the ability to centrally deploy computer shutdown and reboot schedules.
Managed preferences in OS X are based off of Apple's MCX system, so the terms are often used interchangeably. Short for Managed Client OS X, MCX is a piece of Apple's solution to the user and computer management equation. MCX settings utilize LDAP for their application. This is typically Apple's Open Directory, but it is certainly possible to extend the schema of alternative LDAP servers to provide full functionality (such as Active Directory or eDirectory).
Managed preferences are configured through the Preferences interface of the Workgroup Manager Application, as shown in Figure 7-1. On a macro level, preference management can be applied at four different levels, each represented by a tab in the top-left region of Workgroup Manager. These levels include individual users, groups, individual computers, and groups of computers. Standard groups, once managed, are referred to as workgroups. The other levels are simply referred to as managed users, managed computers, and managed computer groups.
Figure 7.1. Managed preferences overview
In Mac OS X 10.4, computer groups were nonexistent. Preceding them were computer lists, now deprecated except for basic policy management and otherwise functionally equivalent. Computer lists are limited in two crucial ways. They cannot be nested and computers could only be a member of a single list, a limitation particularly cumbersome in larger environments. One noteworthy computer list-based feature of 10.4 was the guest computer list. The guest computer list was used to manage any computer, which was configured with an untrusted bind to an LDAP domain and didn't have a unique computer record with the appropriate Ethernet address. This is a fairly common occurrence in loosely managed environments, and the presence of this catchall computer-level management list was very useful. This functionality still exists in 10.5 and 10.6, but is implemented as a single computer record, the guest computer. The guest computer can be found under the computers tab of WGM, but is not available until explicitly created. To do so, there is a nifty Create Guest Computer menu item found under the Server menu in Workgroup manager.
Certain management settings are not available at the user and workgroup levels. These management levels apply to active user sessions, so settings outside of this purview, such as login scripts, energy saver settings, and login window preferences are only managed on the computer and computer group levels. Time Machine settings are another noteworthy management capability only applicable on the computer level. On the flip side, the computer-oriented management levels do not share the same deficit—they have access to the entire purview of applicable management. Because of this, having a well structured and populated managed preferences paradigm that includes users, groups, and computers is highly recommended.
7.1.1. Preference Interactions
One key feature of MCX behavior to understand is the way that managed preferences are determined when managed on multiple levels. Apple defines three different managed preference behaviors, referred to as preference interactions, which determine the resultant policy from multiple levels of management. Overriding preference interactions refer scenarios where two different levels manage the same domain, each explicitly providing conflicting settings. In these cases, OS X prioritizes management levels, as shown in Figure 7-2.
Figure 7.2. Account types election in Workgroup Manager
This works out well for the most part, although there are a few ramifications to discuss. Most important, managed preferences applied at the user level will be the dominant preference, persisting for that user in any environment that they log in to, despite any computer or computer list managed preferences that are applied. After this, you have computer and computer groups taking precedence over workgroups. This proves to be beneficial in lab or kiosk environments where the nodes are typically special usage and may need specific configurations. Workgroups, though the lowest on the totem pole, will be your primary application point. The granularity of user-based management is both a blessing and a curse. While it's great to ensure VIP status for certain users and implement further managed preferences for problem users, it also becomes a management nightmare in medium-to-large environments where a number of policies overlap on a given object due to a combination of users, groups, computers, and computer groups.
Another form of interaction is referred to as combined interactions. Some examples of these include printers, login items, and dock items. In a combined interaction scenario, preferences from all of the different levels are aggregate. Therefore, if you have a login item deployed for a specific user and a login item deployed for a group the user is in, then both login items will take effect when the user logs in.
Inherited interactions are the third type of preference interaction, and simply refer to a managed preference that is only managed at a single level.
NOTE
Introduced with 10.5 was the ability to combine preferences across groups. In 10.4, users would be prompted to select a workgroup upon login, and solely that workgroup's preferences would be applied. With 10.5 and later, you can define settings across multiple workgroups. When a user logs in, and is a member of multiple workgroups, they can be configured to receive the combined policies of those two groups. This was a big boon, as it simplified the management of complex hierarchies, particularly opening up the ability to apply management across nested workgroups. The ability still remains to mimic the 10.4 behavior, if needed.
For the most part, standard preference interactions apply when combining workgroup management. However, an obvious conflict presents itself: When an overriding preference interaction occurs between two groups how is precedence determined? In the case of nested groups, where one of the conflicting groups is a member of the other, the child-most group will override its parents. That is, if GroupA is nested inside of GroupB, GroupB's managed preferences will be applied. If the conflicting groups are independent, the unfortunate answer is that there is no way to explicitly set precedence in such an event—the resulting preference will be determined from the first group sorted alphabetically. This typically shouldn't be a problem, as a properly structured system should avoid conflicting group settings. If the situation is absolutely unavoidable, one option available is to utilize computer access lists, which serve as a handy filter for workgroup-based management.
At this point, you may wonder how it is possible to determine the type of interaction that will be applied to a managed preference. The answer is actually a little more straightforward than may be expected. In fact, the answer will be fairly obvious. Any preference, which has a single definitive setting, will result in an override scenario. There can be only one after all. Combined interactions are utilized in list-based management panes, such as dock items, login items, home sync items, printers, system preferences, and applications. In each of these cases, the user will be presented with the aggregate of explicitly allowed items.
7.1.2. Utilizing Tiered Management
Once mastered, the system provides for very flexible and granular management. In order to truly utilize the system to its potential, you must first have a good understanding of the environment where it is being deployed. This is typically best accomplished by tailoring the system to the organizational structure of the business that it serves. Take note of the various delineations in your workforce, and consider categories such as tenure, job roles and duties, departments, and locations, if applicable. Perhaps some of these categories transcend others, but the goal is to tailor the specific groups that you would want to target for management; the more specific, the more adaptable the system will be for your needs.
Picture a fairly large media organization, like Mediaco. Mediaco has two different campuses, each with fully staffed departments. Mediaco has numerous editors at both locations that need access to the global company media repository. Each campus also has a file server hosting data for multiple departments. A flexible group management structure for this is outlined in Figure 7-3.
Figure 7.3. Tiered management
In this example, you have created numerous groups to represent your structure. The user, John Doe, has been added to the group, Building1 Publishing Department Editors. This group is in turn members of both the All Publishing Editors group, but also the Building1 Editors group, which is once again nested into multiple groups. In this example, even though the user is only a direct member of one group, you can still apply management at six different workgroup tiers. Through the root All Editors group, you may add a login item for the company media repository file share. You can then specify your departmental file server login item on the group, Building1 Publishing Department Editors. Now, when John Doe logs in, he has both his department's SharePoint and the global SharePoint mounted and ready for access.
Computer groups can be similarly tiered, though there is a strong case to be made for the ability to provide logistical-based management. For instance, Mediaco wants to turn off desktop computers at night to save energy costs. Immediately, the need to distinguish between laptop and desktop machines is apparent. Further delineation may be advisable in your organization to account for backup/maintenance schedules, usage patterns, and so forth.
There really isn't a wrong way to deploy groups provided your methodology meets your needs. There certainly are methods to improve efficiency and security. The more specific and tiered your group structure, the happier you will be whenever a policy change is needed. Likewise, the more controlled and consistent your structure is, the easier it will become to avoid membership mistakes. These mistakes can be particularly costly. Workgroup structure is also utilized for file system access controls via POSIX/ACL permissions as well as service access control lists (SACLs). Having a fine-tuned workgroup and computer group structure will provide you with a clean, consistent system that has the ability to adapt quickly, securely, and (hopefully) with consistency. Having a decent structure from the start cannot be overstated because responding to the latest need by simply creating another ad hoc group will ultimately lead to an incomprehensible mess.