Adding Macs to an Active Directory Domain – Part II

In a previous post, I discussed our process for adding Macs to our Active Directory domain and the issues we encountered with the native Apple Directory Utility.  In this post, I will discuss why we chose to go with AdmitMac for our deployment.

In my original testing we had several issues with getting AdmitMac to work.  Namely, getting the drive mappings to display on the user’s desktop on login.  However, one thing that I have come to appreciate about the folks at Thursby software is the quality of their technical support.  Even though we were not a licensed customer, one of their support reps spent an hour on the phone with me walking me through the configuration step-by-step.  Don’t let that give you pause, there really isn’t so much that I needed an hour of support… it really is simple, but he walked me through everything and answered a ton of questions.  Good stuff.

So let’s talk about the reasons that we used AdmitMac.  First, AdmitMac is easy to install.  The wizard will walk you through several options and will install a new item into your Directory Utility.  Notice that it does not use the built-in active directory service.


Once the software is setup, you will go into the AdmitMac Service to make any changes.  You will be given several options for authentication.



Notice here that you are able to give the users the same options for local or network home that you can give them using the Apple utility, however now in one place.


The local login policy was the one major issue we found with the built-in Apple AD service.  Using AdmitMac, you can set the number of times a user can login remotely before needing to attach to the domain again, AND the user will have administrative priviledges when they are remote as well.  Not having administrative privledges remotely with the same user account was the deal breaker for us, and what ultimately pushed us to this solution.


Here you can set who is the admin of the computer, either domain users or groups.

By default, domain users are placed into a new set of folders on the local hard drive, specifically Macintosh HD/domain/domainname/username.In addition, the AdmitMac product has a “home mover” utility that will take the local user account that already exists and make a copy of the files into this new folder structure, with all the appropriate permissions in place.  Thus, little to no impact on the user.

I was able to successfully use “home mover” to move my files into the new structure.  Note that if the user’s home directory is huge, and there won’t be enough diskspace to make a copy, AdmitMac will let you know before it starts.

Overall, we have had zero issues with our AdmitMac deployment over the past month.  I would recommend you take a look at Thursby software if you are looking for an easy to use solution for Macs and Active Directory.

Adding Macs to an Active Directory Domain – Part One

We 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.