Starting with OS X 10.7 (Lion), there has been a shift from managing via Workgroup Manager and Managed Profiles (“MCX”) to managing via Profile Manager and Configuration Profiles (.mobileconfig). Configuration Profiles can be managed in a variety of ways, but OS X Server 10.7 provides a simple and efficient tool to help centralize the management. However, getting a Mac enrolled to the Profile Manager Server by using one of the common delivery methods always requires user interaction. This article outlines how to auto-enroll an existing workstation and how to integrate the process on a “never-booted” system without user intervention and in very few steps.
Quick Configuration Profile Overview
The Profile Manager is a more comprehensive way to manage Apple devices and makes this one of the most interesting features of the new 10.7 Server. Apple has introduced the concept of a Configuration Profile, which is an xml-based file that contains a collection of setting that can be applied either independently to a single or group of Lion and iOS registered devices. Compared with MCX, the configuration profile gives more flexibility for management use which includes a wide range of services; for instance you can now use configuration profiles to manage printers, network settings, certificates and securities. This can include anything from customizing simpler items like the Dock or Login Window to more complex configurations that requires the manipulations of preference file keys (.plist). What highlights the new profiles technology is the ability to remotely lock or wipe any enrolled device. This transforms the traditional management that we were used to, to a new and definitely more extended way of administration.
Profile Manager Requirements
New technology requires new tools. Server 10.7 provides an intuitive web-based tool that allows the creation, maintenance and distribution of configuration profiles as well as management of Lion OS X and iOS devices: Profile Manager.
Apple made the Profile Manager configuration easy so it only takes a couple of minutes to get the administration’s console login window prompted. Is that it? Not quite. Before you can begin creating any configuration profiles there are a number of administration aspects to ensure that the Lion Server is completely functional.
Open Directory Master: It is mandatory to set up the Lion Server to be an Open Directory Master. It requires that a static IP address and the hostname be correctly resolved by the DNS service, and to have a non-limited connection to the open Internet and the TCP ports 1640 and 2195 forwarded to the server.
SSL Certificate: the MDM (Mobile Device Management) requires the use of a SSL certificate. The SSL certificate role is to trust the communication between the devices and the server. If you don’t have the SSL certificate signed by a trusted certificate authority (CA), the self-assigned certificate, which is automatically generated during the Profile Manager configuration, can be used for the scope in conjunction with the Trust Profile.
Apple ID: A valid Apple ID is needed to request the Apple “Push” Certificate. The Apple Push Notification Service (APNs – hosted by Apple) notifies the devices of any changes to the configuration and lets it connect back to the server to have the updated configuration applied.
Once we configured the above we are now ready to go, enable the Profile Manager and begin distributing Profiles.
Common Delivery Methods
Now that a functional Lion Server is running and perhaps some profiles are already configured (I know, we just can’t wait), we can now start enrolling devices to the Profile Manager. Let’s have a look at the common ways to register devices:
- Self-Service Portal: People can independently enroll their own devices (yes, more than one as well) through the web-portal that responds to the URL https://your.server.com/mydevices.
- Email: You can email configuration profiles. The configuration profiles are simple xml files that can be sent easily as an attachment. Once the recipient downloads the profile onto their device, the profile is then automatically installed.
- Web Link: As with email, configuration profiles can be hosted on any webserver. To register the device, you can browse to the website from the device.Click the link to download the profile to have it automatically applied.
As you may have noticed, all the methods described above require the end user to interact with the process. Is that all we can do to get the devices enrolled? Let’s find a way to work around this.
Auto-Enrollment? Yes We Can.
The correct approach to have auto-enrollment applied is to deploy two specific configuration profiles: Trust Profile and Enrollment profile. The Trust Profile configures the devices to trust the Profile Manager server while the Enrollment profile allows remote management, task execution (like lock and wipe) as well as installing configuration profiles. Let’s take a quick look at the process:
First of all, we need to gather the profiles, both available from the Profile Manager’s web admin interface: Select Trust profile from the menu in the top toolbar.
Enrollment is done by clicking on the “+” button in the lower left pane to create the profile and then clicking on “Download” to get it to the desktop.
What we have to do now is copy both profiles to /var/db/ConfigurationProfiles/Setup (the “Setup” folder has to be manually created) for the workstations we need to enroll. Pay particular attention to the profile loading order; OS X loads the profiles using alphabetical order so we have to ensure the Trust profile is at the top. One way to ensure this is by adding an “A” at the beginning of the filename that will almost certainly begin with a “T”. Then restart the device and you are done. Once both profiles are correctly applied to the workstation it will automatically register the Mac under the “Device” list. The profiles will be moved from /var/db/ConfigurationProfiles/Setup to /var/db/ConfigurationProfiles/SetupCompleted so that they are only imported once.
The final step is to move the device to the defined “Device Group” which represents the Profile Configuration that will be pushed.
The creation of a simple installation package (.pkg or .dmg), which places the Trust and Enrollment profiles into the correct path, is the last act for auto-enrolling existing workstation through a deployment solution or ARD.However, to successfully integrate the process within a structured imaging process, we have to face a final hurdle. Follow me.
Structured Imaging Process: never-booted systems
The road to having our devices auto-enrolled is nearly finished. The last hurdle to deal with is the integration of the package into a structured imaging process, based on a never-booted system (InstaDMG for example). Installing the .pkg “as is”, or rather, installing the Trust and Enrollment profiles directly into the destination path of a never-booted volume, could give some trouble as the OS is not yet “ready” to accept the configuration profiles. To avoid any possible issues, the best way is to perform package installation after the first boot by running a script through “launchd”. Launchd is a background program that performs different actions (running the script at the boot in this case) without any user interaction and with root privileges. Those who are familiar with a never-booted imaging process may already have a post-configuration script running at the first boot which can easily include the package installation command. For those who are not familiar, let’s have a look in depth:
The goal is to build a package file which:
- Copies the package that contains the Trust and Enrollment profiles (let’s call it PM_Profiles.pkg, refer to the previous paragraph) on the root of the target disk (the location can be different).
- Copies the script that contains the installer and the cleanup commands (autoenroll_script.sh) into the /private/etc folder. The cleanup command will remove any files at the end of the installation so thatwill happen only one time. The script can be something like this:
#!/bin/sh # Package installation installer –pkg /PM_Profiles.pkg –target / # Cleanup rm –rf /Library/LaunchDaemons/com.company.autoenrollment.plist rm –rf /private/etc/autoenroll_script.sh rm –rf /PM_Profiles.pkg rm –rf $0 exit 0
- Copies the launchd plist job (com.company.autoenrollment.plist) into the /Library/LaunchDaemons/ folder. The plist looks like:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.company.autoenrollment</string> <key>ProgramArguments</key> <array> <string>/bin/sh</string> <string>/private/etc/autoenroll_script.sh</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
Using your favorite .pkg creator, let’s build the final package, paying attention to the file and folders location and privileges.
We are finally at the end; the package is ready to be included into the imaging process and will perform all the installations at the first boot leaving the system loading the profiles at the next reboot. That’s all.
A New Management Way
Now that we have all the workstations enrolled, it’s time to plan a management strategy. Part of the IT department’s role is to juggle between granting and denying user access to company resources while maintaining the highest level of security possible. The new configuration profile technology provides a simple way to streamline this process.
As Profile Manager offers the option to apply more than one profile to the same device, it may be extremely worthwhile to use a “Layered Structure”; or rather, start with a “basic profile” containing the settings to apply to all the workstations (i.e. Security, Login Windows, Directory Service, Certificates), then move up level by level, applying single profile settings for specific groups. Thiscan be useful to keep groups separated, like laptops and desktops, departments or floors. For instance you can apply the basic configuration to all the systems, manage printers by floors with dedicated profiles, and limit applications access to departments that need them; a single workstation could receive all or part of the configuration profile depending on role and location, ensuring a more comprehensive way to allow or prevent access to the company services. This method is useful when a change needs to be made to one of the profiles. Sincenot all users will be involved in the re-deployment activity, this will reduce usage of resources and time while limit support to a specific area.
There is no limit to the number of configuration profiles that can be applied to a single Mac, making Profile Manager a powerful tool to start planning a complete new way of “environment management”.
Profile Manager is Apple’s first attempt to provide a valid administration tool to manage OS X and iOS devices. The trip has started, the direction is right but the road is littered with pot holes. Profile Manager enables the management of most services and customizations expected from a management solution; it’s fast, it’s cheap, it’s simple and yet very worthwhile in a small and medium sized company. Having more than 20 macs and some iOS devices under management was a piece of cake for the Profile Manager. What is yet to be demonstrated if it’s robust enough compared to other experienced third-party solutions to meet the demands of a structured organization with hundreds or even thousands of devices to manage, with complex domains and a huge number of various policies. Personally, I would expect some headaches along the way. I already had some headaches, but there is no reasons not to give it a try, especially now that Apple is directly involved in the game.