- Install Ansible on Windows - Thu, Jul 20 2023
- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
Given Microsoft’s historically contentious relationship with Apple, it never ceases to amaze me at the relatively high degree of interoperability that does exist between a Mac OS X workstation and an Active Directory Domain Services (AD DS) domain.
For instance, a domain-joined Mac workstation allows users to enjoy the following privileges:
- Kerberos authentication and delegation, including Single Sign-On to local, AD, and Open Directory resources
- AD password policy enforcement
- Support for AD user and group accounts
- Windows home folders
Of course, Mac computers do not have a Windows Registry and so therefore cannot be managed by Group Policy (the password policy issue previously mentioned is a notable exception). If you desire an even tighter coupling between Mac workstations and Active Directory resources, then check out nifty third-party solutions like Centrify.
In this tutorial I will show you how to bind a Mac computer to a Windows Server 2008 R2 Active Directory domain. Specifically, I will assume that your Macs run either Mac OS X 10.5 Leopard or Mac OS X 10.6 Snow Leopard. Let’s get to work!
Mac OS X network configuration
Before attempting a domain join from a Mac computer, we need to make sure that we have our server- and client-side networking correctly configured. This means, in a nutshell, that our Macs have:
- An IP address and subnet mask
- A DNS hostname
- A connection to a Windows DNS server
You can specify a DNS hostname for your Mac either by using Terminal or by using the Sharing Preference Pane. Of course, a properly configured Windows Dynamic Host Configuration Protocol (DHCP) server will assign your Mac workstations a correct IP address, subnet mask, and preferred DNS server address.
Finally, and this should come as no surprise to Windows server administrators, you will need to perform the domain join either as a domain administrator, or as a user account that has been delegated the privilege to join workstations to the domain.
Add a Mac OS X computer to Active Directory
Without any further ado, let’s turn our attention to the specific steps required to accomplish our chosen task. The following procedure is essentially identical between Mac OS X Leopard and Mac OS X Snow Leopard systems; where there is a difference, I will note it.
1. Open the Directory Utility program. In Mac OS X 10.5 Leopard, run a Spotlight search for Directory and click Directory Utility.
NOTE: In Mac OS X Tiger and earlier, this utility is named Directory Access. Believe me, the renaming of Directory Access to Directory Utility in Leopard has caused many Mac administrators headaches!
The above single step is all that’s required to open Directory Utility on Leopard. Unfortunately, in Mac OS X 10.6 Snow Leopard, the same procedure is a little more cumbersome (the pane is not searchable via Spotlight, for instance).
To open Directory Utility on Snow Leopard, open System Preferences and then click Accounts from the System row.
In the Accounts prefpane, click Login Options. Then, next to Network Account Server:, click Edit….
2. Okay, now we are on the same page regardless of our recent version of Mac OS X. In Directory Utility, navigate to the Services tab. Next, select Enable for the Active Directory plug-in. Then click the Pencil icon.
3. At this point we really get down to business. At the very least, the two pieces of information that are required in order to join a Mac workstation to Active Directory are:
- Active Directory Domain: Use the DNS name of the domain, not the NetBIOS short name
- Computer ID: This is the DNS hostname of the workstation
Before you click Bind, let’s click the Show Advanced Options disclosure triangle to review some of the advanced binding options.
4. The most important choice in the User Experience panel is deciding whether or not you need to create a mobile account at the user’s first domain login.
In my experience, mobile accounts are necessary only when you manage Mac OS X laptop computers and need your users to be able to log in from work and from off-campus locations.
5. The Mappings panel enables us to optionally bind three key UNIX (and, by extension, Mac OS X) attributes to associated Active Directory schema attributes.
6. Finally, the Administrative panel allows us to specify a preferred Active Directory domain controller. Also, and this is important in most implementations, we can assign the Active Directory global groups that are allowed administrative access to the Mac workstation.
7. When you click Bind in Directory Utility you are prompted for Active Directory credentials with privilege to add computers to the domain. Verify also the location in AD where you want the Mac computer created. In the following screen capture, we are placing the host Macbox in the default Computers container in AD.
Verification and Login
1. You can verify that the Mac is successfully bound to the AD domain by reviewing the Directory Servers tab in Directory Utility. The window shows both graphically, by virtue of the colored circle icon, and in text the status of the binding.
2. Now it’s time to log in! At the Mac OS X login screen, simply select Other from the user list (this assumes that the computer is configured in this way; you can make these changes in the Accounts Preferences Pane).
Users can employ any of the standard username conventions supported by Active Directory. For instance, if the user Zoey wanted to log into the 4sysops.local AD domain, then she could use the following forms for her username:
zoey
4sysops\zoey
For Further Study
There is so much more to learn in the realm of Mac-Windows integration. Expect several more blog posts on this subject in the future. In the meantime, please have fun studying the following links to related resources:
- Apple White Paper: Best Practices: Integrating Mac OS X with Active Directory
- MacWindows.com
- Apple Seminar on Mac OS X-AD Integration
Great article… One thing I’d add in, is that it’s a very good idea to sync the clock on the mac client with your DC before binding – If the clock drifts more than 7 seconds out, Kerberos auth will fail ( See: http://www.squiggle.org/2011/01/problems-binding-mac-to-active-directory )
@Geoff
Extremely good point, but by default the allowed clock skew is 300 seconds (5 minutes), not 7 seconds.
http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html
Thanks for the insight, guys. Hey, what other Mac-Windows integration topics would you like to see coverage on here at 4Sysops?
Would love to see something related to Mac login scripts in as much of a pure AD environment as possible. Maybe something along the lines of mounting external SMB shares based on group memberships.
I deploy my windows clients using WDS for OS and WPKG for package management, wondered if anything similar is available that an deploy mac systems from an infrastructure with no mac servers…
I had that issue with the Mac clock being off from the Windows clocks for a while. I decided to make all the Apple computer sync with the PDC and have the PDC sync with a Mac server that got it’s time from time.apple.com.
My tiny issue with Mac integration is that the Mac’s don’t register themselves with the DNS server properly. Anyone have a fix for that?
Michael, your OSX/MS DNS issue might have to do with whether secure dynamic updates are enabled on your MS DNS server (Ref: https://wiki.cmich.edu/groups/techops/wiki/a63b1/).
And keep the ideas coming! I am seeking clearance from Michael to write more on Mac/Windows integration here, and I’ve noted every one of your suggestions thus far.
Useful article, but there’s an OSX/AD scenario which hardly anyone on the interweb has really covered in any useful detail; adding it here would be exceptionally good for those who are more or less familiar with AD but new to Mac OSX.
Upgrading AD from 2003 legacy or native mode to 2008 native mode does NOT automatically carry any existing Mac OSX users along with that upgrade in a robust and reliable manner. To be certain that it will work requires specific handling at both ends – AD and OSX; the issues _can_ get even more complex/messy if the OS X version is <=Leopard.
Boradly, it is necessary to remove all references to the user [and machine if it exists] in AD, then clean out all the existing AD/LDAP/DNS/DHCP and other settings at the Mac OSX end before rebooting the Mac and going through the steps you have just outlined.
A detailed explanation/illustration of that process could be a boon to new/naive users.
Thanks Timothy. I concluded it was “secure” updates that was blocking the Macs, but I, like most admins image don’t want to unsecure my DNS servers. It’s a minor annoyance if anything.
To Robert’s point. I’ve decided not to update my AD from 2003 native, because I fear the Macs, will put up a fight.
Michael
I can understand not wanting to upgrade AD if one has a lot of users on OSX, but to many AD admins such upgrades aren’t really a matter of choice if they want to get the best out of their systems. I still think the process of maintaining OSX integration during migrations is one that needs documenting.
Hi
I’ve just trieds this guide, to get my Mac (Lion) to join my AD. And it seems to go OK, until I have to login. I click on “Other”, and typein:
domain\AD-user
password
for my AD, but i donget any firther – can You maybe give me an hint what to do, where to look ?
Thx
/Søren
Hi
I am having a nightmare with Lion. Under Snow Leopard I have had no problems joining MACs to the AD domain. I have just upgraded one of my clients to Small Business Server 2011 and when I try and join the MACs to the domain I can get the Directory server showing correctly – but when I come to login, I get a message that Network Accounts are not available.
Any ideas?
Hi Cadgey,
I attended a lecture by Mark Russinovich a couple of weeks ago and he stated that “Apple doesn’t know how to make Windows software.” True words, indeed.
I am writing a new post for 4Sysops on the Lion/AD issue.
Thanks,
Tim
Tim
Sometimes I wonder if MS know how to make Windows software 🙂
I’ll look forward to the Lion article; I’ve managed to avoid that particular issue so far but I can already see the light at the other end of that particular tunnel ….
I just added a Lion box to my AD. It was a bit slow, but it connected fine. The Mac/Windows Servers get real touchy about DNS and the time on their respective clocks. Also helps, to have the name of the domain, in the “Search Domains” in the Network Preferences, as well as the “local”.
Great Writing….
thanks to help beginners like us….
for me it took some time to verify first couple of tries failed… thereafter made changes in network settings specially add DNS …
then it works well…
thanks again….
Just added my virtualized OS X 10.8.3 (Fusion 5) to a work domain for testing things, and your site gave me the hints on how to manage it. Apple support site was worthless. The names have changed for some of the labels, but follow the icon graphics from the “Snow Leopard” and beyond, use the default setting for your domain, and it works. A bit slower than my experience with Windows clients, but that is not surprising (Mac + virtualization + 100MB connection). Thanks for the hints.
Thank you for these instructions.
Honestly, I did not really learn anything from it.
Could you may expand on your experience with Windows Server 2012?
Are there any caveats Apple administrators need to be aware of? Such as I saw a thread some where where PC users were having issues bringing up SMB shares hosted by Mac Leopard Servers.
As long as Microsoft uses LDAPv3, I think I have a chance of making AD binding work with Server 2012. But if MS somehow distorts the LDAPv3 spec or adds proprietary features, Mac OS X Server and Mac clients may have issues authenticating/binding to DCs.
Thanks Again
I’m wondering, what does binding do to your existing computer account? And is there a way to use the “switch users” functionality to go between local account and AD account?
I’d love to know this too. We have a MAC with an account that has years of use and if I bind this to the domain will it damage the existing local account?
As a side note: one critical thing we learned when previously adding a MAC, if an account on the MAC is named the same as the account on the domain, you’ll be reinstalling the OS from factory default after you try to login with that account. At the time we didn’t try domain\username so maybe that was the problem. We just logged in the username (and I assume that would have been the local account) and the MAC started doing things we couldn’t explain so we had to reinstall. THIS is the reason I’m hesitant to join it to the domain today.
Hi,
Thanks for this article which is a hugely valuable contribution to this aspect of osx / windows integration. I happen to manage such a network and it’s a nightmare. It’s exacerbated by macs not connecting cleanly to our 802.1x wireless network. Added to this we have ipads that need to be shared by students that is even a bigger nightmare. We have tried to use a MDM that publishes shared use as a feature of their software on their web site but is a poor difficult and not 100% successful if/ when implemented.
So I would like you to kindly share your thoughts on ios authentication with AD and Apple device authentication on wireless networks as a future article.
Thanks again for this information.
N