In the previous section, you learned about using preference files for preconfiguring a user's environment. You also learned that they can't be used for restricting access, since user preferences take precedence over System Preferences. The Managed Client for Mac OS X (MCX) settings are used here. These settings are stored in a key called MCXsettings, but are sometimes referred to as MCX rules due to their restrictive nature. MCX settings are used to apply preferences to workgroups, computers, or individual users. Most commonly, preferences are applied easily across your organization through the use of a network Open Directory server, but can also be set locally on a single machine. Using Parental ControlsMCX settings are commonly used in two main ways. The first use is for parental controls. Many applications in Mac OS X have built-in parental controls, and still other parental controls can be handled in the specified standard nonadministrator user account in the Accounts preference pane of System Preferences, as in the following ways:
When parental controls are put in place for a given user, his or her user record is modified to contain MCX settings. An example of this would be the parental controls for Safari. The Safari parental controls prevent a user from connecting to any Web site that isn't already bookmarked. You can enable this feature on any nonadministrator account by opening Safari's preferences window. Click the Security button, and check the box for "Enable parental controls":
After this box is checked, that user's record in NetInfo will have a mcx_settings attribute added to it:
The mcx_settings attribute has data that looks very similar to the XML data found in a preference file, but rather than having every application's preferences stored in separate files, they are all placed in this single user attribute. You'll notice that Safari's settings are still identified by com.apple.safari, that the settings are Forced, and that ParentalControlEnabled is set to TRue. Later, you'll see that MCX settings can also be applied in less restrictive ways that will allow users to make changes when they desire. Setting preferences in files or through NetInfo isn't particularly scalable in a large organization. You'll see in the coming pages how you can use Workgroup Manager with a network Open Directory server to easily deploy similar settings throughout your organization. Using Workgroup ManagerWorkgroup Managerpart of the Server Admin toolsallows you to access many more MCX settings, and all from one place. Workgroup Manager can manage the preferences of users both on your local system (even a nonserver version of Mac OS X) and in an Open Directory database. To manage settings on a local, nonserver version of Mac OS X:
You've now used Workgroup Manager to disable the AutoOpenSafeDownloads feature of Safari that you saw earlier in the preference file. This illustrates not only the alternate ways you can apply settings, but also the numerous other options you have available to you through Workgroup Manager. Plus, you've observed the descriptive text that accompanies each setting thanks to the Preference Manifest found inside Safari's application bundle. If you try some of the other options, you'll see that the Preference Manifest controls the values you can set for a given key, reducing the chance for error. You'll also notice that there is no mention of parental controls in the Preference Manifest for Safari. The Preference Manifest is not required to contain an entry for every possible setting you may place in the preference file or MCX setting for a user. It is up to the developer of an application to include a Preference Manifest and to choose what settings are made available for customization. This can be a bit onerous, as you cannot manage a setting if you do not know what that setting is called. In addition to Apple provided Preference Manifests, you can also manage certain third-party applications that abide by the Preference Manifests. As developers continue to modify their applications, Preference Manifests will start appearing, allowing you to manage those applications with the same level of granularity that you find now in Safari. In the meantime, you can use the same interface to add rules for items found in an application's plists, even without a Preference Manifest. You'll just need to do some extra research to determine the options and behavior given the absence of a descriptive Manifest. If you'd like to view the MCX settings field for the account you just modified, you can follow these steps:
MCX Information LocationsIt is important to note that not only are MCX records stored in the user's NetInfo record, but also Managed MCX preferences show up in the following locations:
You can delete and remove the last three in this list, but if you do not get the MCX config and cache records removed (the first two), then the managed preferences will return, whether or not the computer is connected to the server that initially set the managed preferences. This is by design, as you would expect preferences to be managed when users with laptops disconnect their computers for travel or home use. Therefore, if you have the firmware protected from booting into single-user mode, you have denied access to both Terminal and NetInfo Manager, and the user is not an administrator, it is next to impossible to remove the cache and disable the managed preferences, even if the computer is disconnected. Managing Users, Workgroups, and ComputersSo far, we've only been talking about managing the preferences of individual users. But what if you have thousands of users? If you're making nonrestrictive changes to the user environment, you could use the preference file method and drop the desired preferences in the /Library/Preferences folder on a machine. That would apply the presets to every user on that machine. If you wanted to apply the setting to many machines that have a shared /Network/Library folder, you could put the preference files there. However, neither of those options will place any forced restrictions on the users, since users can override those settings with preferences in their home directories. Using Workgroup Manager, you can apply managed settings via the Preferences button to users, as well as workgroup records and computer lists. By applying MCX settings to a group of users, you can, for example, give office staff one set of preferences and students another. If a user belongs to multiple workgroups, he or she will be prompted at login to decide which workgroup's settings should apply to that session. You can also apply managed settings to lists of computers to provide a given look and feel, or restrictions, to different classes of machines. For example, a kiosk computer in a hallway might have access to Safari and no other applications, while computers in a classroom might have access to a restricted set of applications or might prepopulate the Dock with those applications. If your DHCP server sends out your Open Directory configuration, it's possible that outside computers brought onto your network would bind to it. These computers would inherit any of the MCX settings applied to the Guest Computers list. You'll explore the settings you might want to apply to different users, workgroups, or computers in the remainder of this lesson. Managed Preference PrecedenceIt is plausiblebut not recommendedthat you must manage Dock settings for both a specific user and three or four workgroups. However, the user may also be a member of one of those workgroups. Perhaps there are managed Dock settings for a computer list and a person with a managed user account happens to sit down and log in to a managed computer with a managed workgroup account. Depending on the Dock settings, what happens? There are three scenarios that can result from this. The first precedence is to inherit, in which the user inherits managed settings, as in the following chart. Each type of management shows up only once, and even though they exist in different types of managed accounts, the end result is that the user's experience is managed as expected. The next type of managed precedence is combine, in which managed settings appear cumulative even though they exist in different categories of management, as shown in this illustration. Again, this is generally expected and can be planned for under certain circumstances.
The last precedence scenario is when two competing managed settings are set differently, such as when a user's workgroup's home page is one site, and computer list managed settings have the home page listed as a different site, as seen in the following chart. This is an override situation, where the computer list managed preferences override the user's workgroup's managed preferences. The behavior is expected in situations where you manage settings for computers or workgroups, and use individual user settings to override them when needed, such as for a teacher in a classroom.
Determining How Often Settings Should ApplyEach of the managed preferences allows you to specify how often you want your MCX choices pushed onto the user, group, or computer. Not all of these are available to every managed preference, however. The settings are as follows:
Note If you're using the Once setting in your organization and you make changes to a group or computer record, users who have customized their settings prior to the change may have their configurations overwritten by your new Once settings. Always test Once settings before enabling them for all users. |