The first step is to setup the Mac server to run Open Directory as a Directory Master. You’ll be prompted to do this from the first boot of the server. If you’ve already set up your Server just go back to the Server Admin program and add open directory in the services checklist. Next, join the server to Active Directory within its Directory Utility.
The major necessary tweak to your Apple Open directory is to disable Kerberos in Workgroup manager. Since both Apple and Windows use Kerberos authentication you want to eliminate confusion and allow active directory to take the lead permissions and authentication. You can disable Kerberos for Open Directory by going to the attributes section of the Workgroup manager and changing the attribute name of KerberosClient. Changing the value to KerberosClient_DO_NOT_USE will simply help remind you of this change later. If you’re unable to make this change, it’s likely that you are not authenticated for the LDAP domain (Open Directory). In the top bar go over to the tiny lock and click it and it will ask you for the administrative login and password you set up during the Open Directory Setup Wizard.
Next go to Workgroup Manager and in the bar listed as authenticated as LDAPv3 select other and choose active directory -> ALL Domains and authenticate here. Go back to LDAPv3 and create a new group for computers or users and then choose the members tab of that group and select the “+” to open a side bar listing possible members. By default this list will be LDAP members but if you again change this part (top of the side bar) you can view and add members from Active Directory. Find the computer or user from active directory and add it to the group.
For the most part settings changes are pretty straight forward. Almost anything controlled through local system preferences can be tweaked here in Work group manager. Once you have a group established you choose the “settings” button and tweak settings as you see fit. Each setting can be enforce either “Never”, “Once” (for at the first login on a new machine), or “Always”. Everything from Screen Saver time limits to Network Printer and drivers can be configured from Workgroup Manager but I will only list the particular settings changes I found helpful when faced with particular issues integrating with a Windows environment.
As an organization of mostly windows machines we use login scripts that map network drives according to OU membership in Active Directory. Using Mac Open Directory you can accomplish drive mapping and authentication by using two of the settings in Workgroup Manager. You will need to use Login->Items for Drive Authentication and Dock Items to “Map” particular drives and folders to the dock.
Note: you can add folders to the dock without using the Login->Items portion of this walkthrough but often this will mean the user will have to update their authentication for the network resources every time their Active Directory Password Changes, an unnecessary nuisance for users.
Under Login->Items you first want to make sure that you are listing the root Share-Points which workgroup manager will give the “kind” URL. This will allow you to check the box for “Authenticate selected share point with user’s login name and password”. If you attempt to add a subfolder of the shared resource and get a “kind” of Folder you will not be able to check that box which really defeats the purpose of this settings change. It may be useful to check the box for “Hide” so that the finder does not open at every login for the user. Also check the box for “Network Home” if the user has a Home Folder defined by Active Directory.
Under Dock->Dock Items you can define the programs and folders that will be included in the dock. As a mapped drive equivalent to a windows environment, choose “Manage: Always” and under the Documents and Folders Category add the specific locations you want to always be available on the users dock. Make sure to leave “Merge with user’s Dock” checked and include a check for “Network Home” if you have defined it for your users in Active Directory.
Note: there are a host of minor settings changes that are not by default available to tweak through Workgroup managers but if you follow the directions described in the following link you’ll be able to change some settings that would typical be left up to the user’s discretion.
Under the Server Admin Utility, if you add the Software Update Service then the web Server Service will be automatically enabled. There are almost no setting changes required for these two services to run properly. Software Update is a worthwhile addition to your Server setup if you intend to have a group of computers check for software updates at the same time and you want to save time and limit bandwidth by having the update packages already available on the network.
Note: Initial setup caused a major bandwidth spike on our network (both downstream and upstream). I can only assume the downstream had to do with the almost 9GB of update packages that needed to be downloaded but I’m still unclear why the server would need to upload almost that much to the internet. Regardless of the reason until the server finished, after about 2 hours, we did have issues with slow internet speeds throughout the building.
Once you’ve started the Software Update Service and chosen how you want to administer updates you’ll have to configure the machines in your network to check your server for updates instead of the typical update location. For this just go to Software Update in Workgroup manager preferences pane for some group and change the URL to include your server’s DNS name. The typical format is listed below as an example and works perfectly in most cases.
This setup is essentially the Mac equivalent to the Windows Sever Update Service (WSUS) but without the use of Apple Remote Desktop you can only change the server that each computer checks when Apple System Update is run locally, which for most Sys Admin’s is still unacceptable. Luckily sending a UNIX command to network computer to run system update in the background with elevated privileges is easily done as a scheduled task with Apple Remote Desktop.
Apple Remote Desktop ($79.99 in app store) provides many of the group policy functionality we expect from a standard windows server. Major features for administration include the ability to deploy and install DMG packages on network machines and send any UNIX commands to client machines and have them run with elevated privileges. ARD is a necessary addition to your mac server if you are going to attempt to administer a group of mac computers without granting user’s local admin rights.
Software Update on a local machine requires administrative rights, but most IT departments don’t let their users administer their machines which means you have a problem unless you like visiting your mac users on a biweekly basis (you social dynamo). Luckily, ARD will allow those of us with better things to do to apply updates using a UNIX command call that runs updates as the system administrator. The following is the code that I’ve used to apply all recommended updates.
This code always includes two lines that will avoid failure due to unnecessary updates and a line to reboot the computer immediately after updates complete. We schedule our updates for the wee hours of the morning so the reboot is not an issue for the user that saves their work daily but if you’re a kind SysAdmin there are different reboot commands that will allow users to save their work before restarting. (Experience with our windows users has proven our clients cannot handle this privilege and will in fact ignore the “please restart” notice for weeks on end.)
ARD will report failed updates and tell you when the computers are back to the login window. And schedule these task will prevent you from needing to retype this command each week.
Despite the fact that login items allows you to authenticate network drives at user login, there doesn’t seem to be an easy way to tell Mac OSX to use the user’s login name and password for printers that are being shared from a windows server. Given that you have the proper drivers for the printers, connecting and using them is not an issue but as we quickly found out it can be a huge headache for the users and your helpdesk personnel if 8 keychain entries for the printers have to be updated every time a user’s active directory password changes. As of right not I can tell you our best solution was to create a separate AD user with a static password and input that for each printer for each Mac user. A terrible pain I know, blame the lack of corporate support Apple built into its machines, but assuming the user does not need to create a brand new keychain you should not be bothered by the issue again. *will update if a better solution reveals itself in a vision*
The other thorn in my side from Apple is their implementation of the App Store. While the app store is a great invention for the typical home user from a corporate perspective its licensing and installation procedures make administering Mac’s more difficult in a few ways. The major issue I have is that I do not want to have corporate employee email accounts used as app store users. If someone leaves, it’s going to make it difficult to recoup the software the company paid for and change the email address on the account to a new employee. The best alternative I’ve found for corporate app store purchases is to setup dummy email accounts for every Mac in your business and point these accounts to a single mailbox. This solution is useful in that it will consolidate recipients from the app store and keep purchasing power with the corporation and not with the individual user. While this is a solution for signing up for the app store it doesn’t solve the main issue with the app store. The app store could very well mean the end of purchasing software and receiving a copy of a DMG file that can be deployed using ARD. I can see the appeal of avoiding the illegal sharing of its software but every purchase from the App Store means the IT staff has to manually do the install at every effected machine. That’s just another reason to hate the walled garden that is Apple. *again: will update if something better comes up*