Bind Mac OS X 10.8 Mountain Lion or 10.9 Mavericks to Active Directory

I’m going to quickly cover two ways of binding Mac OS X clients (up to and including 10.9) to AD:

Option 1: Deploy Studio (i.e. The easy way)

I highly recommend this method.  By creating a Bind workflow and adding it to your deployment workflow, the server does the hard work for you.  You simply have to populate the following fields.  I’ll give you an example of what I like to use for the value on each:

  • Target volume: Previous task target (whatever drive you are imaging)
  • Computer ID: Host name (you need to have prepopulated this for an account in the DS computers node, otherwise)
  • Domain:
  • Computers node: the path to the OU using the following syntax: CN=subOU,CN=mainOU,DC=subdomain,DC=domain,DC=com
  • Active Directory Computers’ administrator login/Password: short name and password for a domain account with create/join computer account rights
  • sign packets: disabled (default)
  • encrypt packets: disabled (default)
  • password change interval: 14 days (default)
  • Enable mobile accounts: unchecked (Doesn’t work well in my experience; see below)
  • Force local home directories: checked (Create and use a local home folder for each user)
  • Use UNC path from Active Directory with network protocol: checked/CIFS (assuming you do use SMB shares for your users)
  • Authenticate to domain: (or whatever domain your users are in)
  • Allow administration by: domain\admin group 1,domain\admin group 2
  • Custom mappings: none
  • Automate: yes!

But what if you aren’t restoring a machine, or don’t have a DS server configured?

Option 2: CLI

No big deal.  You can bind a machine after-the-fact using the dsconfigad utility.  Just run the following commands, using “sudo” for each.  Note that we are using “OU” instead of “CN” here.  It wouldn’t be a bad idea to throw them in a shell script with a variable for the host name…

  • dsconfigad -add “” -computer “hostname” -ou “OU=subou,OU=mainou,DC=subdomain,DC=domain,DC=com” -username “domainaccount” -force

The preceeding command will prompt you for the password of the account you are using to join the computer to the domain.  Next you can view the status with:

  • dsconfigad -show

Verify that it says you are bound to AD.  Below are the options I use with dsconfigad to configure the newly-bound account.  There are other options you can use.  However, these, as an example, should give you roughly the same results as the DS method above. One difference is that I added the -namespace switch. I haven’t seen this option in DS, but is designed to help if you are in a multi-domain forest, and have multiple users in different domains with the same username. That said, it seems to be broken, so you may have to open the directory utility and set the auth search domain manually (or do this with the “dscl” commands below), in this scenario. Without further ado:

  • dsconfigad -mobile disable (again, see below)
  • dsconfigad -localhome enable
  • dsconfigad -useuncpath enable
  • dsconfigad -protocol smb
  • dsconfigad -packetsign disable
  • dsconfigad -packetencrypt disable
  • dsconfigad -passinterval 14
  • dsconfigad -groups “domain\admin group 1,domain\admin group 2”
  • dsconfigad -alldomains disable
  • dsconfigad -namespace forest
  • dsconfigad -preferred

The following are the DSCL commands used to remove “All domains” in your forest from the search path, and replace it with your specific fqdn, if needed.  You can get the exact strings to use here for “DOMAIN” AND “fqdn” from Directory Utility. As an example: for the fully-qualified domain name: “” you would likely use “/Active Directory/MYDOM/” for the first command below, and “/Active Directory/MYDOM/” for the second.  The first is right there in the Directory Config Auth search path dialog and the second is available within the Auth Search path dialog by clicking the + and finding your fqdn.

  • dscl /Search -delete / CSPSearchPath “/Active Directory/[DOMAIN]/All Domains”
  • dscl /Search -append / CSPSearchPath “/Active Directory/[DOMAIN]/[fqdn]”

While we are at it, why don’t we join Open Directory as well??

  • dsconfigldap -a “”

That command will perform an unauthenticated ldap bind to the OD server, so that we can now manage settings of OS X, although I understand this is being deprecated in favor of profiles.  Oh joy…

That’s all that it takes!

MORE INFO ADDED: Ok, thanks to bernriegeth, who commented below, it occurs to me that I should go into a little more detail on the point of logging on with domain and mobile accounts.  In theory, if you always have a strong and reliable network connection back to the DC, and you are not doing heavy-duty multimedia work, then mobile accounts are the way to go.  As with a roaming profile or folder-redirection on a Windows client the folder and files you see when you log on are the ones stored on the server:  Your desktop, Documents, etc.   This is really convenient, right?

However, if your connection drops and you try to open a document you will very likely hang the entire system, to the point that you can’t even force-close an app until the connection comes back or you power the machine off.  What kind of sloppy programming is that?  The fact is, Macs are consumer devices, and aren’t designed to be used as part of an enterprise network.  Additionally, in our environment, all of the iMacs have a pretty good physical ethernet connection to the server 99.9% of the time, but those are the machines that are dedicated to heavy-duty graphics and video work, and you do not want to be doing that work over a WAN connection.  For this type of scenario, you really want to just use a local folder, even if you are logging on with a domain account.  Thus, my recommendations above.

Moreover, if you are using a wirelessly connected or traveling iMac or MacBook, you don’t even want to go that route.  Because, once you find yourself without a connection to the DC, you cannot log on to the device at all.  This even applies if they are already logged on when they get disconnected.  At that point if the user is an admin and attempts to make an administrative change on the system, their domain credentials are not accepted to do so since they are not cached, and the system cannot contact the DC.  This is bad.  This is, again, worse than the situation with a Windows client where at least you can authenticate with cached credentials in this situation.  So, on those devices: Sure, join them to the domain (I recommend not using a mobile account, especially in this situation), but make sure to create a backup, local user account for when they are without a connection.  I hope that clears everything up!  🙂

~ by Jay P Morgan on October 22, 2012.

7 Responses to “Bind Mac OS X 10.8 Mountain Lion or 10.9 Mavericks to Active Directory”

  1. very useful documentation. I just set this up for OS X 10.8.2 + Windows 2008 AD using the GUI way.
    AD integration including network smb home works fine as long as the client is connected to the LAN.
    As soon as the client (a MacBookPro) is offline or network connection is switched from LAN to WLAN, problems arise, that make the mobile use impossible: Sometimes the mobile user logon process never ends, sometimes it works, but network home is missing, sometime it wants the keychain password for sync, but input is not possible, or it starts syncing for ever.
    I got the impression, that this network home stuff in Mac OS X is still inmature in comparison to Windows roaming profiles.

    How did you solve these problems?

    My users often change the network, mostly without logging out (e.g. when changing to a classroom for giving a presentation), therefore I need a rock solid solution.

    • Glad I could help. That is exactly why I never enable the mobile account. In theory it sounds good, and if you have used roaming profiles with Windows you expect a good experience. In practice the OS X mobile accounts are very buggy and problematic. Fortunately, once your users get used to using command+k to connect to their server (I tell them to save it in the list) then SSO at least makes it a little bit easier to connect; they shouldn’t be presented with an additional login anymore.
      My recommendation:

      • mobile accounts unchecked
      • local home checked


      • ok, I disconnected from AD, reconnected and changed the settings to:
        creating mobile account: unchecked
        local home dir: checked.
        But the result is, that the credentials are not cached and the user cannot logon if AD is not available (offline or in an other network).
        That’s obviously no solution for my mobile users.

        Do I really have to switch back to local users for an OS released in 2012?


      • Da’oh! Ah, yes, I should have mentioned that critical piece of info, right? Yes, unfortunately on our macbooks I decided to create a local user account for each user. When they are connected, they can use the domain account if they wish, but when they are going to be offline they need to log on with the local account. That way they don’t have to worry at all about the OS hanging or other issues that can arise with the mobile accounts, or the issue you refer to where the user cannot log in without a connection. I found no other stable way for them to work. I agree with you: the “enterprise” features of OS X are not very good, in comparison. I guess I try to keep in mind that this is not an enterprise product. Apple has made it clear that they are a consumer-product company, not enterprise. Thus, the enterprise add-ons tend to feel like an afterthought; they can be a little flaky. But hey, if you do find anything that works better, let me know!

      • ok, I switched back to local accounts (it’s a bit “last century computer administration”). I found very useful documentation at princeton:

        My setup is now as follows:
        local user account on MacBook Pro with 10.8.2
        AD binding still available
        OD binding to my deployment server for distributing MCX Records once (printers and network drives).

        Different network locations defined according to princeton docu for LAN, WLAN etc. where users have to switch manually when changing the network (lateron I plan to evaluate “sidekick”, if it’s available for 10.8).

        That setup seems to work for me.

  2. So i have kind of a dumb question cause i am very new to Mac. Once you are on the active directory domain, how do you access the local admin account. the only thing it lets me do is network accounts now. :/

    • Make sure your local account has a unique name. Don’t use “administrator” or anything else that also exists on the domain when you create your local accounts. If your domain name convention is first-initial last-name, use full first and last, for example, or vice-versa.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s