Apple

Integrate Macs into a Windows Active Directory domain

Jesus Vigo takes a look at how to setup and configure Apple hardware running a modern version of OS X and get it communicating with a Windows Active Directory environment.

windows-with-OSX.png

Market share in the enterprise is largely dominated by Microsoft -- specifically, the reliance on the Windows Server family line to manage network resources, align desktops with corporate security policies, and maintain the flow of production amongst all the employees at a given organization. The process of administering all these systems -- desktops and servers alike -- are relatively straight-forward in a homogeneous environment, but what happens when OS X is introduced to the enterprise in the form of a sleek, shiny new MacBook Air or iMac? 

Apple hasn’t made great inroads in this segment. However, comparing its paltry 7% market share in the desktop market to its almost 93% in the mobile device market, there's only a matter of time before more companies begin to choose Apple products for its mobile and desktop computing duties in lieu of the generic, stalwart PCs they’ve been cycling in and out every three to five years. So, I ask you again, what do you do when your organization decides to upgrade to iMacs? How do you manage those nodes in addition to the existing Windows domain that's already established?

Integrating Macs will initially be easier than you think! Even with little to no prior OS X knowledge, Macs will bind* to the domain with relative ease, since directory services -- the underlying “file structure” of the network resources -- are standards-based and operate more or less about the same across operating systems.

Note*: Binding is the term associated with joining OS X to a domain. It’s virtually identical to joining a Windows PC to a domain, complete with checking domain credentials to verify the end user has the necessary rights to add the computer to the domain.

Minimum requirements:

  • Server hardware running Windows Server 2000-2012 Standard
  • Active Directory Domain Services (ADDS) setup and configured
  • Domain Administrator-level account
  • Apple desktop or laptop running OS X 10.5+
  • Switched network

I. Bind OS X to a Windows domain (10.5-10.9)

Follow these steps to bind OS X to a Windows domain:

  1. On the Mac, go to System Preferences, and click on the padlock to authenticate as an Administrator (Figure A)
    Figure A
    Figure A
     
  2. Enter your admin-level credentials to authenticate when prompted
  3. Next, select Login Options, and then click the Join… button next to Network Account Server (Figure B)
    Figure B
    Figure B

  4. In the Server drop-down menu, enter the fully-qualified domain name (ex. domain.com) of the Windows domain you wish to bind to the Mac, and click OK (Figure C)
    Figure C
    Figure C
     
  5. Next, you'll need to enter your domain-level credentials in order to proceed with the binding process (make sure that the computer name is unique and formatted properly, because this is the name that will be created** for the computer object in ADDS), and then click OK to process the enrollment (Figure D)
    Figure D
    Figure D

  6. Upon successful binding, the window will close and the Users & Groups preference will remain open, but a small green dot (along with the domain name) will appear next to Network Account Server to indicate connectivity to the domain (Figure E)
    Figure E
    Figure E

Note**: By default, Windows will automatically create the computer object account in ADDS if one does not already exist. However, domain or enterprise admins may (and often do) restrict this as a security feature to curb random nodes from being joined to the domain. Additionally, Organizational Units (OU) may be created as a form to compartmentalize ADDS objects by one or more classifications or departments. Many enterprises will utilize OUs as a means to organize objects and accounts separately from the items created by default when a domain controller is promoted and ADDS is created.

II. Modify Directory Services settings

Your next steps will be to modify the Directory Services settings. Here's how:

  1. To ensure the highest level of compatibility between OS X and the network resources on the Windows network, certain changes must be made to the Active Directory service with the Directory Utility -- so, go to System Preferences | Users & Groups, and click Login Options
  2. Click the Edit… button next to Network Account Server, then click Open Directory Utility… (Figure F)
    Figure F
    Figure F
       
  3. The Directory Utility lists various services associated with network account directories (Figure G), and it allows you to modify settings as needed 
    Figure G
    Figure G

  4. Double-click Active Directory to edit its configuration (Figure H)
    Figure H
    Figure H
     
  5. Click on the arrow to unhide the Advanced Options, select User Experience, and check the following boxes:
    a. Check Force local home directory on startup disk (Figure I), which will force the creation of a profile on the local HDD for all users that logon to the node (if you plan to serve profiles remotely from a server, leave this setting unchecked)
    Figure I
    Figure I

    b. Check Use UNC path from Active Directory to derive network home location (Figure J), and select the network protocol to be used: smb: (Note: This setting will switch the default protocol for network resource paths from Apple’s afp: to the Windows' friendly smb: -- also known as Common Internet File System, or CIFS).
    Figure J
    Figure J

  6. Next, select Mappings (Figure K), which pertains to specifying unique GUIDs for certain attributes used within ADDS to identify a computer object account. OS X will generate these at random by default when bound to the domain; however, you may wish to use a particular set as generated by your enterprise admin.
    Figure K
    Figure K

  7. Finally, select Administrative (Figure L), and configure the following three optional settings based on the ADDS schema setup of the organization:
    Figure L
    Figure L
     
    a. Checking Prefer this domain server will perform two-way communication to/from the domain controller of your choosing
    b. Checking Allow administration by will allow nodes to be managed by the administrator(s) who's responsible for overseeing systems, based on security group membership or user account(s)
    c. Checking Allow authentication from any domain in the forest may or may not be necessary to ensure that the OS X computers authenticate to the proper domain, as configured by the domain/enterprise admin.

There you have it -- a basic look at how to setup and configure Apple hardware running a modern version of OS X and get it communicating with a Windows Active Directory environment. I also threw in a few extra tips to help make a smooth transition and minimize errors.

One additional tip (and common best practice) is to host an Open Directory domain along with the Active Directory service. Multiple directory services will add to the burden of managing two distinct operating systems, but you’ll be surprised to find out that it may actually make administration of these systems easier! This dual-directory environment will allow Windows PCs to be maintained and managed solely through the Active Directory side, while Open Directory -- when setup with OS X Server -- can be used to maintain and manage the Apple computers. 

Giving the Apple hardware the second directory binding to ADDS will allow them to seamlessly communicate with the Windows desktops and share file and printer resources from Windows servers and nodes, and vice-versa. This eliminates the need for costly 3rd-party software plugins. The Macs will receive much of their management directly from the domain controller hosting the Active Directory service, but it must “translate” the processes into commands that OS X will understand. Even then, it does introduce another variable when troubleshooting. And let’s be honest, the newly released OS X Server 3.0, which is only $20 in the Mac App Store, is a full-fledged server OS that’s as simplified and easy to use as OS X.

III. Additional resources

Here are some additional resources for more information:


About

Jesus Vigo is a Network Administrator by day and owner of Mac|Jesus, LLC, specializing in Mac and Windows integration and providing solutions to small- and medium-size businesses. He brings 15 years of experience and multiple certifications from seve...

16 comments
vnodkumar1987
vnodkumar1987

Anyone knows how to automate this using a script ?

RickL66
RickL66

Hi Jesus, good article, it got me going with my network which has a Windows Server 2012 R2 as the AD. However, there is one annoying thing that I can't seem to figure out. I have several shared folders on the server, and I've set up permissions to access each folder depending on each user. However, each person on the Mac can see all the shared folders (but can't access the ones they don't have access to, which is a good thing). How do I HIDE the folders that a user does not have access to? Take a look at this screen shot - http://www.luko4.com/shares.png - the user jbond does not have access to the folders I've crossed out in red, but they are visible to him. How do I hide them? On the windows machines, it works fine, the user only sees the folders they have access to. I'm not a Mac expert, but I am a Windows expert. Help?

ItWorxz
ItWorxz

Hi there might suggest the following for your Minimum requirements:

  • Mac Specific Active Directory Device OU container to hold your Macs, may want to create one for Apple Desktops, Laptops, Tablets, and Servers.
  • Domain Administrator-level account > This is not correct, you need to have a user account that has authority to add and modify (possibly delete as well but not for the binding phase) the AD Device OU created above.
    Domain Administrator-level account is not a minimum, and in my case not possible by myself and was insufficient in our locked down environment.
When adding the device, you need to specifically add the device to the Device OU in the Domain that you need the device to reside in.

Using the Fully Qualified Domain Name resolves the confusion around the .local suffex. Though in many ways would be great to remove the .local naming convention, as it does add to the confusion of getting Apple computers into enterprise environments.

On the benefits side off having apple devices on Enterprise allows for organisations to:
  • Removes replication of services: Email; Calendars; Pod Casts; File Servers; Proxy Servers; Internet Connections; User management; etc.
  • Sllows for the Apple devices to have Enterprise monitoring so that Organisation Policy and Compliance Requirements can be monitored and reported against.
  • Single Sign on and user management.
mohsenbb
mohsenbb

Thank you so much for your good and clear tips..... I have a question, how can I set my personalized Desktop (als admin) for all users? I mean I would like that all users in net. (AD domain) have a same desktop without saving on Hard disk. I must unchecked " force local home directory  on startup Disk "  and in this case I don´t know where is the Public desktop. Thanks a lot 

tomhillsnetwork
tomhillsnetwork

@themacjesus Hi Mac Jesus!

I've followed your guide but I fail when binding. it "cannot find node name error 2000".


I've tried googling the error but I have synced my clock to that of the AD server and I can ping via IP and DNS and it resolves to both but it will not bind.. same error.


I was wondering if you'd be able to help?


I've tried via directory also, but it cannot find the server.


Thanks!

JeffTheNetworkGuy
JeffTheNetworkGuy

Jesus, I am currently trying to add a couple of new macs to a domain that I help out with and am getting frustrated.

I find a below comment about the .local domain name interesting and I am wondering if that is the issue that I am experiencing. Would this also apply to an internal AD domain called "efree", where servers have the name server1.efree and so on? 

I also see that there is a reference to bonjour and that your list of requirements lists a switched network. As bonjour is a broadcast based protocol, does this mean that if the domain controllers are in a different subnet from the user devices that this will not work. If they get added to the domain from the same broadcast domain can they then move off of it to a different routed subnet?


Jeff


bigbigbilly
bigbigbilly

Yes, OS X Server 3.0 is a full-fledged server OS.

johnmckay
johnmckay

Why bother though?  Mac or MS PC does a job; and it's being done fine with current PCs, AD and the Group Policies etc.  Given all this documented hassle and fact most PCs are actually added by scripts due to needing admin rights to start with...  why would I want to introduce Macs and add more layers to control my environment. Why would I possibly even contemplate trying to copy my GPs to a mac compatible format? Why would I want to spend the effort to do so knowing it would be very unlikely to mirror the working solution that ISNT broken?


Most folk I talk to do very little with their Mac but love it because they feel different, and think they are above their peers because they have one; I've seen many come, then go a few months later.  I've one too but it sits and is never used any longer as we all use MS day-in, day-out and are happy. 


List the benefits of adding macs into the forest and justify the extra workload and the added risks.  Apart from someone wanting to use a macair, list some actual business benefits and justification.  Suppose I support 10,000 users and 1000 want a mac.....   how much additional work would that be?

NOTR
NOTR

Nice article, but you should mention that bonjour uses .local and you won't be able to bind the mac if the AD domain ends in .local. I think there should be more articles like this, from start to finish on how to change AD names (RENDOM) or adding a new domain with trusts, migrating users, etc. I've been through it 1.5 times and it's not fun. It would be cool to hear what others are doing to overcome this. 

T3CHN0M4NC3R
T3CHN0M4NC3R

No wonder no there's so little Macs in the enterprise...

themacjesus
themacjesus

Hi @JeffTheNetworkGuy! Sorry that you're having trouble binding those Macs to the domain. For your first question about the "efree" domain, AD does not use the ".local" suffix like the Macs do. AD actually uses domain names (ending in .com, .net, etc.) for its domain suffixes.


As for the Bonjour question, that was not referenced in the article, but rather included as a comment by a fellow reader. By default, OS X server does add the ".local" suffix to a server's hostname - unless .private is used for a VPN server or a unique domain name is used instead. However, the focus of the article is to join Apple computers to a Windows Active Directory network. OS X's Open Directory is optional, but required for this to work. Bonjour applies to the OD setup in that the protocol was designed by Apple to allow Apple devices to natively communicate with each other on the same network. Windows servers do not use Bonjour to communicate with other nodes, instead it uses TCP/IP and for that, a switched network - even if it's just one switch providing connectivity for all the devices - is used to ensure that the devices are part of the same subnet.


I hope this clears up the differences. Best of luck in getting those Macs bound to AD!

themacjesus
themacjesus

@johnmckay I appreciate your input on the article above. But none the less, it is presented as a solution to a very real issue that affects a growing number of businesses - small, medium and large - across the world. The fact that OS X, Windows, Linux and the multiple variations of Unix abound exist means that at some point, somewhere, someone will be in a situation where they must manage more than one OS and make them communicate in order to share resources and keep productivity to SLA levels.


While this may not be your specific situation per se, it doesn't marginalize the legitimacy of a need that organizations are experiencing.


Try not to look at it as a Mac vs Windows situation, but in simpler terms, using the built-in functions of a system to communicate with another, non-native system using standards-based protocols at the OS level. At the end of the day, whether it is called Active Directory or Open Directory, it really is a directory service that is run from a server in order to provide security authentication and access to network resources, among others.


As far as being asked to list the benefits of integrating Macs to AD, describing the work load or justifications, sadly, I feel you may have missed the mark of the article. I do not work for Apple nor am I a Mac advocate above all other technologies available. Contrary my belief has always held that one must use what allows you to get your work done easier, smarter, more efficiently. If you have no real need to integrate any other OSes into your existing environment, then this article may not be scoped for your particular needs; however, if the paradigm continues to shift and organizations grow to adopt BYOD or perhaps you find yourself at a new job and the CTO has decided to implement a heterogeneous network to support Apple devices, for example, then you'll have some technical documentation to assist you in performing the job you've been tasked with.


Thanks again for your views!

NOTR
NOTR

@johnmckay If you were the owner of the company, you can mandate that everyone uses PCs (even that would be a tough sell to employees.) You have to adjust to the growing usage of Macs in the enterprise and failing to support them is failing at IT. You have to adapt and learn what others are doing to work with Macs in the enterprise. 


The biggest benefit of adding Mac users to the domain is single sign on. This allows Helpdesk employees to focus on more interesting projects. Adding macs to AD also helps to gauge inventory. 


I understand your frustration, but this is site for solutions, not flame wars. 

themacjesus
themacjesus

@NOTR Very true!


I have yet to encounter this issue myself since typically, AD domains have been required to hold domain extensions (.com/net/org, etc) and not .local. But I do agree that it will cause issues come time to bind stations.


As for the advanced management features, that's definitely something to consider once the basics are down. AD management is part skill, part art and managing Macs within the AD schema takes some 3rd-party plug-ins and apps to ensure the commands are properly translated to a Mac understandable language.


Thank you for the input once again NOTR Happy Holidays!

themacjesus
themacjesus

@t3chn0m4nc3r04 lol Macs are still a risky proposition for many Enterprises - not just because of the cost - but rather since some applications used in the business world only function on specific versions of Windows and/or Windows-only apps. Even with BootCamp enabling access to a full, Windows environment, when added along with the cost of new hardware, support & training costs and of course, software licenses, it's not the best situation for all business types.


However, BYOD is changing the tides and many organizations are adopting this wave to allow their employees to bring in their personal equipment to work comfortably and it's an easy way to boost productivity.


Thank you for writing in and have a happy new year!

themacjesus
themacjesus

Thank You for the insight NOTR and I agree, we're all here for solutions to Enterprise issues.