Adding Macs to an Active Directory Domain – Part One
Posted in: CITRT, General IT, Integration, Join the Journey, Mac OS X, WindowsWe continue to add more and more Mac computers to our network. Up until now, we have been happy to simply have the Macs be standalone machines, and haven’t wanted to undergo the learning curve to add them. We are now at a point where managing user accounts and access has become difficult, and we want to move all of our Mac users onto network accounts. Thus begins our journey into the abyss.
Starting out, the Mac integration seems simple enough. Using the built-in Directory Utility, you are able to bind the Macs to the domain with very few issues. Simply entering the fully qualified name of the active directory domain and clicking “Bind” should do the trick and add the machine to AD just like a Windows machine.
You are presented with several advanced options during this process.
Our first hurdle was determining what each of these options do. In a nutshell, here were our findings (and our default settings above.)
- Force local home directory: This is something you will want to do, especially if you want applications to be available when users are off the network. Not checking this box will place a ton of files on your server in the “network user home” directory. That means that applications get installed here, the library folder is here, music is here, etc. Not a good thing if you are a laptop user or are ever offline, and it creates more network traffic as well.
- Use UNC path from AD: Checking this box will map the AD user home folder upon login and will place it on the dock by default. This is pretty useful if you have users who use their network folder a bunch. In our situation, our network home folder in the windows environment was mapped to the user’s My Documents using Group Policy and offline files, so most of our users have a lot of documents there.
- Default user shell: Just leave it as it is. /bin/bash works just fine.
- Create mobile account at login: This is the most tricky one. So we’ll talk about it later in detail.
Here is what show up under the mappings tab of Directory Utility.
Unless you really have a need to change anything here, it works great when left alone with the defaults. And then we are left with the administrative tab.
The administrative tab is important for administering the machine.
- Prefer this domain server: This is fine if you really want to set it, but is not really necessary in our case.
- Allow administration by: This is useful when the user is connected to the network and will allow the active directory network user account to make changes on the local machine… if they are a member of one of the groups added here. In our testing, this seemed to only take effect at the GROUP level not at the user level, meaning we were unsuccessful in adding an individual user here for administration. ALSO NOTE <ALERT> i.e. this is important! This seems to work fine when a user is connected to the network, however, what happens when the user is at home and can’t see the network? Any guesses? If you guessed that the user’s admin privileges are not cached and the user WILL NOT have administrative privileges when they are offline, you are correct. Impact of this is that a network user goes home and while at their house needs to install an update, etc. Because they can no longer see the network they will not be able to approve the update unless they have a second local user account with admin rights. Not good, and probably confusing to the user. This is a pretty major flaw in my opinion.
Mobile Accounts
Let’s talk a little more about creating mobile accounts. Creating the mobile account at login seems like a great thing to do. In fact, it is the ONLY way that your users will be able to login using their network credentials when they are offline. (Under Tiger, there was an option to cache credentials, which has now been replaced by Mobile Accounts.) As we have previously mentioned though, if the user is offline they are no longer an admin, which really limits the ability of the user to administer the machine when off the network. In addition, the mobile account user will be able to sync their folders between the network and the local machine. This is great in theory, however not nearly as intuitive as Microsoft’s offline files, which automatically determined the latest version and save the appropriate one. In the Mac implementation of sync, the user has to choose which version of the file to keep, which is dangerous in my opinion, and an extra burden on the user. We choose NOT to sync the files for these reasons.
So where did we finally land on integrating our Macs with Active Directory? Due to the limitations of offline administration and creating mobile accounts we decided to take a look at a few third party products.
Next time: How we implemented Macs in Active Directory with Admitmac.
