Large Scale Mac OS X Client Management Using Windows Servers

Transcription

1 Making it easy to deploy, integrate and manage Macs, iphones and ipads in a Windows environment. Large Scale Mac OS X Client Management Using Windows Servers By: Charles Edge Originally published in 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 1

2 Introduction Managing large numbers of computers effectively is a tough task, no matter the platform. Just when many administrators had their workflows in place for managing systems on Mac OS X Server, along comes the end of the Xserve and for many, the end of being able to leverage Mac OS X Server in their data centers. While Mac OS X Server is still a viable option for small environments, it simply will not work for many who require fault tolerance, remote hardware management, clustering, rack density and a platform that can be virtualized. As we have been showing throughout this series of articles, the move from Mac OS X Server to Windows Server can be less cumbersome than many previously thought. The platform is considerably more scalable, with virtualization end-to-end and true high availability options. And in many environments, Active Directory has been integrated for years, so administrators are already well versed in Windows Server administration basics. The growth of Apple in large environments means that there are more and more enterprises looking to adopt a platform that allows the enterprise to not only provide services similar to how they are provided for other platforms, but also allows the enterprise to centrally manage the client computers. The Enterprise Device Alliance (EDA) has developed a strategy for leveraging existing Windows Server administrators and infrastructure in order to provide command, control and connectivity services to Mac and ios clients. The EDA includes Absolute Software, Centrify, GroupLogic, and Web Help Desk, all able to run on Microsoft Windows Server 2008 R2. Each of these vendors fills a very specific void for managing Mac OS X: Absolute Software: Change, configuration and patch management Centrify: Extending group policy objects to enable Active Directory-based management and a directory services plugin to ease the transition to Active Directory GroupLogic: Native Mac OS X file services hosted on Windows Servers Web Help Desk: Trouble ticketing and inventory management This ecosystem provides systems that work very well together or independently, maximizing the efficiency of staff and giving administrators replicatable, highly available, well documented and vendor supported infrastructures. The EDA has run 3 previous articles, outlining options for replacing the Xserve with Windows Servers, running the most critical and important services that enterprises need. These include: January 2011: Centralized Mac Home Directories on Windows Servers February 2011: Imaging and Patch Management using Windows Servers for Mac OS X Clients March 2011: Implementing File and Print Services for Mac OS X using Windows Servers In this, the 4th installment of the EDA series on moving from Mac OS X Servers to Windows Servers, we will look further at leveraging Centrify in conjunction with Absolute Manage to get the most granularly controllable environment possible. In this article we will also look at some of the tasks that can be performed by either solution and when it would be best to use on over the other. This isn't to say that you don't need both. In fact, it is important for large environments to have solutions for both patch management and policy management to help ease administration burden, centralize control and standardize systems. In this article we will explore this concept further, looking first at management using managed preferences, then at management using flat configuration files and finally look at scripting and distribution of these managed preferences and files. For more information on Absolute Manage, see For more information on Centrify s DirectControl for Mac, see ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 2

3 Managed Preferences No discussion of centralized management of Mac OS X can be complete without covering managed preferences. Managed Preferences allow administrators to push settings to client computers, control the user experience in Mac OS X and restrict access to various resources. In Mac OS X Server environments, Managed Preferences are controlled using Workgroup Manager to provide centrally managed preferences to clients, with those clients refreshing the preferences at each login and logout event. Many environments use what is known as a dual directory to provide Mac OS X clients with two directory services, Open Directory and Active Directory. In a dual directory environment, Active Directory is used for centralized authentication and single sign-on services. Open Directory is used for centralized Managed Preferences in these environments. A common use case for the Xserve in enterprises is to use Managed Preferences through a dual directory. With Apple s retirement of the Xserve, leaving many an enterprise looking for a replacement to a Mac OS X Server based dual directory environment. Manifests Managed Preferences use what are known as preference manifests to enforce these policies. Preference manifests are collections of property lists. A property list is a serialized file in an XML format. Property lists make up most settings in Mac OS X, with user settings usually stored in the Library/Preferences directory of a users home folder and system preferences usually stored in the /Library/Preferences directory. Apple includes a number of preference manifests and others can be added or created as needed, to allow for support for third party applications. Additionally preferences can be managed by giving client systems the contents of a property list to use, rather than creating an entire manifest. However, when doing so it is important to keep in mind that you will have less options when assigning a property list as a managed preference. Locating Property Lists Every setting is stored in a file. In order to use a property list, or any other file, to push out a change for a setting, one must first find the file that the setting is in. Additionally, it is important to make as little change to the file as possible, as other settings may be located within the file. Even if there aren t other settings when initially determining how a change is made, there may be one later, so making sure to know exactly what needs to alter within a file and only altering what needs to be altered is important. There are a number of different tools that can be leveraged to locate a file that has changed on a computer, but for this example we will use Absolute Manage InstallEASE. InstallEASE is free and available at Once installed and opened, we will create a snapshot of the system twice: one before and one after making a settings change. In this example we will find a simple setting: where the position of the dock is stored. To do so: 1. Open Absolute Manage InstallEASE. 2. Choose the Method: Automatically. 3. Click Continue. 4. Leave the Snapshot Source as the default and click on Take Snapshot ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 3

4 Figure 1- Snapshot to set baseline 5. Authenticate if prompted to do so. 6. Once the snapshot is complete, change the position of the dock to the desired setting. 7. Go back to InstallEase and click on Take Snapshot again to compare the settings. Figure 2 Snapshot comparison 8. Once the final snapshot is complete a list of changed files will be displayed in the Snapshot Data InstallEASE step ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 4

5 It is then possible to replace the com.apple.dock.plist in order to make changes on client systems. However, it is not preferable to do so because while most preferences will be stored in a property list, most property lists will have more than one setting. Therefore, administrators should rarely simply replace files to change settings but instead should change the parts of the files that contain the settings that need to be altered. The com.apple.dock.plist (located at ~/Library/Preferences as can be seen in Figure 2) is no different than most. As mentioned earlier, a property list is a serialized file in XML format. Some are readable to the human eye and others are not. Therefore, using the defaults command provides a means of looking at the contents of a property list and changing the contents programmatically. To view the contents of the com.apple.dock.plist file, we can use the defaults command, along with the read verb followed by the path of the file without the file extension. For example, to see the serialized data for a user named cedge: defaults read /Users/cedge/Library/Preferences/com.apple.dock As can be seen when viewing the contents of com.apple.dock.plist, there are a number of settings stored here, including each item that has been put into the dock. Locate the position key and you will notice that it is set to right, left or bottom, according to where it was placed. Changing the orientation using the Dock System Preference pane will then be reflected in the com.apple.dock.plist file. To change the orientation use defaults command along with the write verb. The key that will be change will come after the location, and in this case the key will be a string (Boolean and integers are also common). In the following example, we will make the dock go to the right of the screen: defaults write /Users/cedge/Library/Preferences/com.apple.dock orientation -string right Items stored in arrays are a bit more tricky to work with. The defaults command can still be used to edit property lists with arrays, although many prefer the plutil or plistbuddy to manage them. Overall, editing settings using a script will get more complicated as the structure of the property list gets more complicated, but makes pushing out settings changes en masse using a tool like Apple Remote Desktop possible. Using Directory Services to Manage Property Lists Pushing out shell commands using Apple Remote Desktop can be cumbersome. Clients can fail to run the command, with thousands of users it can get difficult to verify that all of them have the newly implemented settings and of course, once a setting has been deployed, users can change them. Therefore, managed preferences allow for the centralized management of settings, and more granular controls on whether or not users can change those settings. Open Directory provides an easy way to push managed preferences out. However Open Directory needs to be run on Apple hardware and requires clients be bound into two separate directory services, when another solution such as Active Directory is being used for authentication. Open Directory does allow administrators to nest Active Directory security groups and users into groups, but doesn t have Organizational Units, which many an enterprise leverages for managed settings. Open Directory is based on LDAP. Active Directory is also based on LDAP. Therefore, both have attributes, which include fields for user names, addresses and things like that. But each also has a number of fields that are proprietary. It is within proprietary fields that the Mac OS X Managed Preferences manifests are defined. These fields, or attributes, are defined in what is known as a schema, or a layout of the directory services database. LDAP allows for extending this schema to include attributes that are not part of the stock implementation ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 5

6 Using Centrify to Manage Property Lists In Active Directory environments there is often a concern about the amount of replication that extending the schema can cause, or the fact that schema extensions cannot be undone once they have been put in place. Centrify does not require administrators to extend a schema to use managed preferences. Therefore, in this section we will look at leveraging Centrify to provide the attributes for managing preferences in Mac OS X. Active Directory uses Organizational Units to determine which objects (e.g. Users, Computers, etc) a policy is applied to. A policy is similar to a managed preference in that it controls various settings. Centrify uses the policy framework in Windows Server 2008 to apply policies to objects. These policies are then simply payloads placed into attributes that Mac OS X client systems interpret as managed preferences. Controlling the dock is a built-in policy (managed preference) in Centrify. Once Centrify has been installed, the Group Policy Management console can be used to deploy policies to client systems and users. To do so: 1. Open the Group Policy Management console from Start -> Administrative Tools -> Group Policy Management. 2. Browse down the tree to Group Policy Objects. 3. Right-click on Group Policy Objects (GPO) and click on New. Figure 3 Creating Group Policy Objects 4. At the New GPO dialog box, provide a name for the GPO. As more GPOs are created, each can be used as a Starter GPO, or template. For the initial GPO, simply provide a name ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 6

7 Figure 4 Source for New GPOs 5. Once created, right-click on the name of the newly created GPO and click on Edit to bring up the Group Policy Management Editor. 6. At the Group Policy management Editor, open User Configuration and then Policies. 7. Click on Centrify Settings and then click on Add/Remove Templates in the Action menu. Figure 5 Adding Templates 8. Click on the Add button. 9. Click on the centrify_mac_settings XML Document in the list and then press the OK button ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 7

8 Figure 6 - Settings 10. Click on the OK button and Mac OS X Settings should then be listed underneath Centrify Settings. 11. Repeat the process to add the centrifydc_settings XML Document into the list. 12. Browse to Dock Settings. Figure 7 Dock Settings 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 8

9 13. Double-click on Adjust the Dock s position on screen. 14. Click on Enabled and then choose the desired position on the screen. Replacing Flat Files When users in the Organizational Unit next authenticate from systems bound to Active Directory they will receive the new dock position. Figure 8 Positioning Screen Properties Configuration Files Property lists allow administrators to change a lot of settings, but not all settings. Some settings are still stored in older, nonserialized file structures. These are predominantly files ending in the conf extension as are common in Linux and Unix. For these, there are a number of different strategies for changing the settings they include which we ll look at in this section. The structure of configuration files is usually pretty straightforward. For simplistic settings, each setting will be stored in a line. For settings that are a bit more complicated, a number of lines may be used for a given object and a separator, or delimiter, will be used to indicate the end of one object and the beginning of another. As with property lists, the easiest way to make settings changes is to replace the file that has the setting that needs to be changed. However, as with property lists, a given file can have a number of settings and replacing the whole file can be overly intrusive to make a small change. In the event that there is a single setting stored in a flat file, or to prepare a user with all of the settings in a file then simply copying a new file over the top of an old file is one way to make changes. But scalability is a concern and so invariably administrators look to edit flat files using a script. To replace a flat file, Apple Remote Desktop, shell scripts and other solutions can be used. But an issue that invariably comes up is trying to isolate what change caused a problem in larger environments. Therefore, having a centralized solution that manages tasks such as copying files to local clients to reference in the event of a problem can be helpful. Absolute Manage is such a tool. To use Absolute Manage to copy a file that makes a settings change on clients is a simple task. In the following example, we will copy a file that has only one setting in it: ntpd.conf. This file is used to store the network time servers that a client computer uses. Copying a file from a system that has a time server that is desired will result in a client that has the same time server defined. To do so: 1. Open the Absolute Manage Admin tool from a client computer. 2. Select a group of computers to make the change on. 3. From the Commands menu, select Copy File/Folder 4. Enter the name of the file to be copied in the File: field and the location on the target system to copy the file to in the Target Path field. 5. Check the box for Replace existing file. 6. Click on the Execute button. Figure 9 Absolute Manage: Copy File 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 9

10 While this feature of Absolute Manage seems duplicative to the Copy Items option from Apple Remote Desktop, it is worth mentioning that Absolute Manage has some options not available in Apple Remote Desktop. The event that occurred is tracked in Absolute Manage whereas it is distributed across the machine that sent the change in Apple Remote Desktop. Also, Absolute Manage runs on Microsoft Windows and can therefore run in, for example, a Windows Virtual Machine, something that cannot be done in Apple Remote Desktop. Replacing Flat Files En Masse Using Centrify Both Absolute Manage and Centrify give administrators the ability to either replace a file on an entire Organizational Unit or group object in Active Directory. In our previous example using Centrify, we looked at using Centrify to manage a Dock. Here, we will look at taking a system that has been set to centrally manage logs. In order to facilitate such a task the newsyslog.conf file has been populated with the desired settings. Next, we will show how to replace a file using a group policy from Centrify, picking up where we left off in the previous example: 1. Create a new directory in the SYSVOL directory (e.g. called Centrify), which is by default C:\Windows\SYSVOL. 2. Copy the newsyslog.conf file into the newly created Centrify directory. 3. From the Group Policy Management Editor, browse to Centrify Settings and then Common UNIX Settings. 4. Double-click on Copy files. 5. Set the Copy file policy setting: to Enabled. 6. Click on Add 7. Enter the path to the file (relative to the SYSLOG directory) in the Filename field (or use the Browse button to select the file. 8. Enter /etc/newsyslog.conf into the Destination field. 9. Use the Specify permissions and ownership option to set the file permissions to 0600, the UID to 0 and the GUID to Click on OK. 11. Click on Apply. Figure 10 Creating new syslog The system will then process the policy when restarted. That policy will be implemented in the form of a new copy of the newsyslog.conf file being placed into the /etc directory of the client computer. Editing Flat Files With A Script As referenced previously, overwriting a file is an acceptable practice to make a change in a file with only one setting, but if a file has a number of settings it is too intrusive to the user experience for deployed systems. For example, if we were to replace the /etc/copys/printers.conf file then we would delete all of the printers that a user has installed. While this may be a good idea on a newly imaged system, it is a bad idea on systems that already have been used for some time and may have additional printers installed. When it comes to making a change in a file, there are about as many ways to edit a file as there are people who write scripts. One of the easiest ways is using a text editing tool such as sed. In this example we will look at using sed to make changes in a file that has a lot of settings: printers.conf. Here, we will disable sharing for all printers. To do so we will use sed in what is known as in-place mode, which uses the i option. We will then follow the i option with an empty extension because the in-place mode in Mac OS X requires an extension. This is done using 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 10

11 the that can be seen in the file. We will then use the s/ to indicate that we will be substituting text (or replacing text) and then have the text to be replaced followed by the text that it will be replaced with. We will then define that the setting will be changed globally in the file, which means that all instances of Shared Yes will be replaced with Shared No. Finally, we will define the file to make the change to: sed -i "" 's/shared Yes/Shared No/g' /etc/cups/printers.conf We could also do the opposite, enabling printer sharing for all installed printers that have printer sharing disabled, but we will go a step further and use the.backup extension of the i option of sed to also backup the file before we make the change, thus having a backout plan in case the change goes bad: sed -i.backup -e 's/shared No/Shared Yes/g' /etc/cups/printers.conf This is a very simplistic incantation of sed. You can actually do a lot more with it, but for the purposes of making the small change we needed to make this is actually all we needed sed to do. This command could then be deployed by either using the Absolute Manage Send Unix Command, similar to the Apple Remote Desktop Send Unix Command or a Centrify based policy. Scripting Configuration Changes Managed Preferences, copying files and editing files are common ways to make configuration changes on client systems. However, some settings are distributed across a lot of files or are in a lot of places within a file. Changing each can be difficult and so Apple in these cases often provides a command to make changes when needed. In these cases, scripting configuration changes is the most effective way to ensure a system is in working condition following a change. There are a number of these types of tools in Mac OS X. A great example of this is when looking to enable Remote Management, the Apple Remote Desktop client. To do so, an administrator is best served using the kickstart command found in: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart. Another great example is using systemsetup to change Energy Saver settings and set startup disks. And no systems adminsitrator s toolkit would be complete without networksetup, which allows administrators to configure most network settings in Mac OS X programmatically. Deploying Wireless Networks Deploying a wireless network can be done using the networksetup command, which has a few options specifically geared to working with wireless networks. To obtain a list of all of the networks that a system has used, use the networksetup command along with the -listpreferredwirelessnetworks option, specifying the hardwareport. The hardwareport is the name of the wireless network adapter, which can be seen in the System Preference pane. By default the hardwareport for wireless is called AirPort, making the default command to see all wireless networks in a systems preferred list: networksetup -listpreferredwirelessnetworks AirPort To remove items from the list, use the -removepreferredwirelessnetwork option. Here, the networksetup command is followed by removepreferredwirelessnetwork and then the hardwareport (AirPort by default), followed by the name of the network to be removed. To remove a network called Skynet: networksetup -removepreferredwirelessnetwork AirPort Skynet 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 11

12 In monolithic imaging environments it is often necessary to clean out all networks that a system was joined to. To remove all of the preferred wireless networks and therefore fully clean out the list, use the - removeallpreferredwirelessnetworks option followed by the hardwareport: networksetup -removeallpreferredwirelessnetworks AirPort To add networks, use the -addpreferredwirelessnetworkatindex option. This option will require the hardwareport, then the network, then the index number to be assigned to the network (or 0 if iti s the first) and then the security type of the wireless network (e.g. OPEN, WEP, WPA, WPA2, WPAE or WPA2E). To add a network called Skynet that uses a password of SarahConnor: networksetup -addpreferredwirelessnetworkatindex AirPort Skynet 0 WPA SarahConnor Pushing A Script Out Through Centrify To deploy a script through Centrify: 1. Copy the script to the scripts folder within the domain name entry in the SYSVOL directory. 2. Open the Group Policy Management Editor and browse to the Scripts (Login/Logout) setting under User Configuration. 3. Double-click on the Specify login script policy. 4. Enter the name of the login script that was copied into the scripts directory. 5. Click on Apply. 6. Click on OK. As with the previous policy, the shell script will be processed at the next login of the user. As with Open Directory-based login scripts, the script will run as the root user during login. There is also an option for logout scripts. Figure 11 Pushing a script using DirectControl 2011 ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 12

13 Pushing A Script Out Through Absolute Manage Login scripts are not the only type of scripts to be run. Running scripts immediately or as part of a workflow can be a key element of imaging and patch management. The ability to run a script gives administrators the ability to make changes in enterprises quickly and effectively. Centrify provides the ability to run scripts as a part of a policy. This allows the task at hand to be enforced each time the policy is run. But when performing upgrades and making settings changes that require immediate use and require to be made part of a workflow for reinstalls, Absolute Manage makes for another tool that can be used. Similar to Apple Remote Desktop, but with even more options, Absolute Manage allows administrators to run scripts in an object-oriented fashion. To run a script using Absolute Manage: 1. Using the Server Center Windows 2. Click on Execute Script from the Commands menu. 3. At the Execute Script screen, choose a Unix Shell Script as the Executable type: 4. Click on the File: option in the Executable section and provide a file to be run. 5. If there are any operators for the script, enter them into the command line options. 6. If the script requires elevated privileges click on the checkbox for Executable requires administrative privileges. 7. Using the Execute as: field provide an account to run the script as. 8. Click on Execute when ready. Figure 12 Execute Script Dialog The script will then be run against all of the clients that were selected. In environments with both Absolute Manage and Centrify administrators then have a number of options in their toolbelts ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 13

14 Conclusion Large enterprises typically employ one solution to manage policies and another to manage patches and software distribution. This is because each is uniquely suited to allow administrators to perform certain tasks. In this article, we ve shown a number of different scenarios and different ways to go about dealing with them. When choosing the method to use to deploy a given change into an enterprise, the most important question to ask is usually whether or not the change should be enforced persistently. If so, then the best mechanism to make that change is usually with a policy management system. In this article we looked at doing so with Centrify. If a change is a one-time change and is not to be enforced then enterprise administrators have a decision of whether to use a policy management system or whether or not to use a patch management system. If the change has to do with a managed preference then in most cases, sticking with the policy management system is the appropriate way to deploy the change. If the change has to do with software distribution then deploying the change is usually best done with a patch management system. In this article we looked at using Absolute Manage as the software distribution mechanism for such a system. However, there are a lot of cases that fall in the middle. There are also some cases where a given change is better suited using another type of tool. In these cases, it is recommended to make the change in the way that impacts systems in the least way possible. The reason being that most problems in an environment come when a change is made. Often times a change to one part of a system can impact others. Choosing to make the least amount of changes possible in a system (e.g. changing a single setting in a file versus replacing the whole file) means that you will invariably have less support incidents based on changes that are made. The goal being to not let a change to a users dock preferences cause a tsunami elsewhere! Different tasks have different times or levels of importance. Group Policy, as provided by Centrify, is a client pull solution, which means that the client will eventually wake up and pull down the settings when it gets back online. Configuration Management, as provided by Absolute Manage, uses a push model, meaning that the client needs to be online and accessible to accept commands from servers; however, configuration management tools can push to clients immediately rather than waiting for the next pull interval. Use the right tool for the task as each has its place. Finally, adding a little scripting goes a long way. While both Centrify and Absolute Manage are designed so that administrators can perform many of the most common tasks without needing to resort to scripting, the ability to write a script to make a change on a system can boost productivity of deployment staff immeasurably. As we ve shown in this article, a lot of tasks that would otherwise need to be done manually can be scripted, and doing so can save a lot of man hours that can be used in far better ways than walking around to make an easy change on hundreds or thousands of computers. About the author... Charles Edge is the Director of Technology for 318 Inc, a national provider of IT Services with a focus on the Apple platform. Charles is also the author of a number of books on Mac Systems Administration, including the Enterprise iphone and ipad Administrator s Guide from Apress. You can reach him at cedge@318.com ENTERPRISE DEVICE ALLIANCE. ALL RIGHTS RESERVED PAGE 14