Blogbusters864

1. There is a method of offering partial Mac client management and access to other Mac OS X Server services under Active Directory that doesnt require schema modification. The approach is twofold.
2. Mar 24, 2005 138 Preparing a Read-Only LDAP Directory for Mac OS X 138 Populating LDAP Directories With Data for Mac OS X 139 Accessing an Active Directory Domain 139 About the Active Directory Plug-in 141 Configuring Access to an Active Directory Domain 143 Setting Up Mobile User Accounts in Active Directory.
3. Make sure your users have access to the network services and resources they need by managing the user and group attributes on a directory server. How to give users the access they need To browse the Directory Utility User Guide, click Table of Contents at the top of the page.
4. You can use the Active Directory connector (in the Services pane of Directory Utility) to configure your Mac to access basic user account information in an Active Directory domain of a Windows 2000 or later server. The Active Directory connector generates all attributes required for macOS authentication from Active Directory user accounts.

Joining a Mac to Active Directory has continued to get more and more difficult over the years. High Sierra and Mojave now require a Active Directory functional level of Windows Server 2008 or later and are still pretty tricky to get to join it.

One of the projects that I’ve been meaning to complete for a while now has been getting my Mac OS X computers to participate in my Active Directory (AD) domain. I got Active Directory working with Linux – so surely it should be possible to repeat the process on a system with BSD Unix at the core? Yes, as it happens, it is.

Before I explain what was necessary, it’s probably worth mentioning that the process is not the same for every version of OS X. As explained in a Microsoft TechNet magazine article from 2005, early implementations of OS X required schema changes in Active Directory in order to make things work. Thankfully, with OS X 10.4/10.5 (and possibly with later versions of 10.3 – although I haven’t tried), schema changes are no longer necessary.

By far and away the best resource on this subject is Nate Osborne’s Mac OS/Linux/Windows single sign-on article at the Big Nerd Ranch weblog. This told me just about everything I needed to know (with screenshots) but, crucially, when I tried this over a year ago on my OS 10.4 system I could not get the Mac to bind with Active Directory. This was despite having disabled digital signing of communications (not required for OS X 10.5) and it turned out that the problem is the internal DNS domain name that I use which uses a .local suffix. As described in Microsoft knowledge base article 836413, OS X treats .local domains as being Rendezvous/Bonjour hosts and needs to be told what to do. There is an Apple article that describes how to look up .local hostnames using both Bonjour and DNS; however I’m not sure that’s what fixed it on my OS X 10.5.2 system. My TCP/IP, DNS and WINS settings were all being provided by DHCP and, even though I added local to the list of search domains, it was the second listed domain (after the DHCP-suppled entry) and successful binding seemed to occur after I had pinged both the domain name and the domain controller (by name and by IP address) and performed an nslookup on the domain name. Another thing that I considered (but did not actually need to do) was to create a reverse lookup (PTR) record in DNS for the domain name. Retrying the process and binding to a domain with a .co.uk suffix presented no issues at all.

Nate’s article is for OS X 10.4 (Tiger), and having got this working in OS X 10.5.2 (Leopard), I thought I post a few more screenshots to illustrate the process:

1. First of all, open the OS X Directory Utility and Show Advanced Settings. Switch to the Services view and ensure that Active Directory is selected, then click the button with the pencil icon to edit the settings:
   
2. Enter the domain name (home.local) in my case and computer name. In the Advanced Options, I left the user experience items at their defaults (more on that later):
   
3. Switching to the administrative options reveals some more settings that are required – I checked the box to enable administration by the Domain Admins and Enterprise Admins groups, but others group or user accounts can be added as potential computer administrators:
   
4. Click the bind button and, when prompted, supply appropriate credentials to join the Macintosh computer to the domain (i.e. AD credentials). This is the point where the location of the computer account is defined.
   
5. If you receive an error relating to an invalid domain and forest combination being supplied, this is likely to be a DNS issue. Check that DNS name resolution is working (using the OS X Terminal utility and the ping or nslookup commands) and note my earlier comments about support for .local domain name suffixes – you may need to follow Apple’s advice to add local to the list of search domains:
   
6. Once successfully bound to Active Directory, the group names for administration of the local computer will be expressed in the format domainnamegroupname. The system event log on the domain controller that processed the directory request will also show a number of account management events, as the computer account is created and enabled, then the password is set and the associated attributes changed (password last set and service principal names):
   
7. In the OS X Directory Utility, Click OK, and move to the Directory Servers view – is all is well then the domain name will be listed along with a comment that the server is responding normally:
   
8. Active Directory/All Domains should also have been added to the Authentication and Contacts views in the Search Policy:
   

Following this, it should be possible to view AD contacts in the Directory and also to log on using an AD account (in domainnameaccountname format). Although this worked for me, I was having some issues (which I suspect were down to a problematic AirPort connection). Once I had switched to wired Ethernet, I was able to reliably authenticate using Active Directory, although I did not re-map my home drive to the network (Leopard’s SMB/CIFS support is reported to be problematic and I felt that can of worms could stay closed for a little longer until I was comfortable that AD authentication was working well). Instead, and because my computer is a MacBook, so will often be disconnected from my network, I changed the User Experience options for Active Directory to use a mobile account – effectively creating a local account on the MacBook that is mapped to my domain user:

At the next logon, I was prompted to create a mobile account and once this was done, I could access the computer whilst disconnected from the LAN, using the using the AD credentials for the last-logged-on user.

One more point that’s worth noting – if you have existing local accounts with the same name as an AD account, the permissions around user account settings get messy, with the AD logon resulting in a message that there was a problem creating your mobile account record and the local logon reporting that there was a problem while creating or accessing “Users/username“.

Mac Os X Active Directory

That’s all I needed; however I did compile a list of links that might be useful to others who come across issues whilst trying to get this working (perhaps on another version of OS X):

Mac Server

• Apple: Integrating Mac OS X and Active Directory; configuring access to an Active Directory domain (OS X 10.4); and about Active Directory Access (OS X 10.5).
• Big Nerd Ranch: Mac OS/Linux/Windows single sign-on.
• MacWindows: Integrating Macs and Microsoft Active Directory.
• Microsoft TechNet Magazine: Cross-platform security. Yes, you can! Secure your Mac on a Windows network.
• Mike Bombich’s Leveraging Active Directory on Mac OS X.