How to Use Active Directory and Macintosh Clients without Schema Changes

Last updated October 17, 2007

On this page:
Introduction Part 1 Environment Part 2 Basic AD authentication on clients Part 3 Setup the Open Directory Server Part 4 Setup Workgroups on the Open Directory Server with AD users Part 5 Test the Managed User Accounts Part 6 Setup Single Sign-on on the OD Server Part 7 Create Shares for Single Sign On Part 8 Test Single Sign On Reader Comments Comments to Version 1.0 of this page Comments on version 1.1: Stuck at Step 4 TIP: AD and home users in Mac OS X 10.3.3-plus TIP: Binding OS X 10.4 to AD when it fails at Step 5

Related info at MacW

Active Directory and Active Directory and MacWindows Active Active Directory Inte Windows clients con Mac OS X authentic

Introduction
Greg Priglmeier (a Systems Engineer at the Minneapolis Star Tribune) sent us this report called How to use Active Directory and Macintosh Clients without Schema Changes. This method uses a Mac OS X Server on the Network. He said: I have been working on AD integration for several months and I'd like to share a document that I generated for complete Mac

authentication and workstation management. Details: Windows 2003 AD Server, Mac 10.3.3 Server and Client.Basic AD Authentication for clients. How to use AD and Open Directory together to manage Mac clients with Workgroup Manager. Single sign features and how to set this up on the OD Server. Priglmeier is interested in feedback, so if you'd care to comment, please drop us a note. . On May 24, we posted an updated version of this document.

How to use Active Directory and Macintosh Clients without Schema Changes
by Greg PriglmeierSystems EngineerMinneapolis Star Tribune Version 1.23June 28, 2004 This guide is designed to be used by experienced administrators. I have tried to cover all the basic information without getting specific to a particular AD / OD environment. Note: Text that is new since version 1.2 of this document is in blue.

Part 1 Environment
A Windows 2003 Server running Active Directory: Several Windows user accounts for testing. A share point to test single sign on. A Mac OS X 10.3.3 Server running Open Directory: Several Mac user accounts for testing. A share point to test single sign on.

A Mac OS X 10.3.3 client. Note:Use a network time server with all machines to sync your clocks.

Part 2a Basic AD Authentication on Clients

Login locally to the client and launch Directory Access. Verify that the Active Directory plug-in is checked and select Configure. Enter the following information: AD forest examples: 'myforst.com' or 'myforst.root' AD Domain examples: 'mydomain.com' or 'mydomain.local'

Computer examples: 'MacID#' or 'AssetTagInfo' ID Optional items: Check 'Authenticate in multiple domains' Check 'Allow administration by: your domain admin accounts, etc here' Verify that everything is correct. Click the 'Bind' button. Wait for the process to complete. Choose the Authentication button. Click the Authentication button and choose custom search.

 Choose your AD domain from the list. Choose the Contacts button. Click the Add button and choose custom search. Choose your AD domain from the list. Launch System Preferences/Accounts: Choose 'Login Options' Select 'Display login Window as: Name and Password' Verify that 'automatically log in as' option is not on. Restart the client computer and login using an AD network account. Launch /System/CoreServices/Kerberos application: Verify that you have a valid Kerberos ticket from the Windows PDC. This should look something like this: useraccount@domain.local (yes, '.local' works)

Part 2b. Basic Open Directory Authentication on Clients.

Login locally to the client and launch Directory Access. Verify that the LDAPv3 plug-in is checked and select Configure. Create a new configuration. Enter the following information: Check 'enable' Configuration name: 'OpenDirectory' Server name: 'LDAPservername.domain' LDAP Mappings: 'Open Directory Server' Enter your search base information. I use the same search base for

all machines. Examples: 'dc=domain,dc=com' or 'dc=domain,dc=local' Choose the Authentication button. Click the Add button and choose custom search. Choose your OD domain from the list. Choose the Contacts button. Click the Add button and choose custom search. Choose your OD domain from the list.

Part 3 Setup the Open Directory Server

Login locally to the OD server using your admin account and launch Directory Access. Verify that the Active Directory plug-in is checked and select configure. Enter the following information: AD forest examples: 'myforst.com' or 'myforst.root'

AD examples: 'mydomain.com' or Domain 'mydomain.local' Comput examples: 'ServerID#' or 'OpenDirectory' er ID Optional items: Check 'Authenticate in multiple domains' Check Allow administration by: your domain admin accounts, etc here Verify that everything is correct.

Click the 'Bind' button. Wait for the process to complete. Choose the Authentication button. Click the Add button and choose Custom Search. Choose your AD domain from the list. Choose the Contacts button. Click the Add button and choose Custom Search. Choose your AD domain Restart the server. Login locally to the OD server using your admin account and the launch Server Admin application. Select Open Directory/Settings Change the role to: 'Open Directory Master' Select Open Directory/Protocols. Enter your search base and write it down for later use. Examples: 'dc=domain,dc=com' or 'dc=domain,dc=local' Choose 'Save'. Choose the Authentication button. Click the Add button and choose Custom Search. Choose your OD domain from the list. Choose the Contacts button. Click the Add button and choose Custom Search. Choose your OD domain from Restart the server.

Verify that the LDAPv3 plug-in is checked and select Configure. Create a new configuration. Enter the following information: Check 'enable'. Configuration name: 'OpenDirectory' Server name: '127.0.0.1' LDAP Mappings: 'Open Directory Server' Enter your search base information from the previous setup. Optional items: Check SSL Launch System Preferences/Accounts Choose 'Login Options' Select 'Display login Window as: Name and Password' Verify that 'automatically log in as' option is not on. Shutdown your AD Mac client computer. Restart the server.

Part 4 Setup Workgroups on the Open Directory Server with AD users

Login locally to the OD Server using your admin account and launch Workgroup Manager. Select the domain icon (small globe) on the left and choose the AD domain. Authenticate to the AD domain using the Windows Domain admin login and password. Select accounts/Users.

After a small pause there should be a list of AD user accounts available. Select the domain icon (small globe) and choose the OD LDAPv3 domain. Select accounts/Groups. Create a test group for user management named 'Managed Users' and save it. Select the Managed Users Group and the Members button. Select add (the '+' button) Select the domain icon (small globe) on the right and choose the AD domain. Double click the users you wish to add to the group and save. Select the Managed Users Group and Preferences button. Choose some options to manage. Example: Select Finder. Manage these settings: 'always' Select 'Use Simplified Finder' Save.

Part 5 Test the Managed User Accounts

Power on the client computer(s). Login in using the test account created earlier. Verify the user's desktop appears to be Managed through Workgroup Manager. Example: Is the Finder managed as you set it?

Part 6 Setup Single Sign-on on the OD Server

Launch Server Admin and select Windows. Select General. Change Role to 'Standalone Server' Enter the following information for your server: Description Computer Name Workgroup Select Advanced. Change enable WINS registration to 'Register with WINS server' Enter the IP address of the WINS server. The 10.3.3 AD Plug-in now supports kerberos authentication to the Active Directory server for Samba. This will give you single signon. You need to set this up by hand. You will have to unbind your server and rebind the server after you make this change to the samba config file. Here are the instructions: Edit the /etc/smb.conf file and add or modifiy these these three lines in the global section: use spnego = yes realm = DOMAINHERE.COM security = ADS Now rebind the AD Plugin. Verify the name you use for the bind is the exact name of the server, example: Hostname = myserver.apple.com Computer Name = myserver Bind as "myserver" in the Active Directory Plugin. DO NOT use Fully Qualified Domain Name. Verify the WORKGROUP is correct for the right domain as well

and ensure local and domain master browsing is off in the Windows setup. Shutdown the client. Reboot the server.

Part 7 Create Shares for Single Sign On

In the Finder, create a folder named 'Test Share' Create a share point on the OD Server using Workgroup Manager. Select the Sharing button. Select 'Share this item and its contents' Enter the Owner, Group and Everyone information. Example: Owner: 'admin' RW Group: 'Managed Users' RW Everyone: -- None Save.

Part 8 Test Single Sign On

Power on the client computer(s). Login in using the test account created earlier on the Windows AD server. Verify the single sign feature. Select new finder window/Network icon. Browse to the OD server. Choose connect. A window with the share points should appear.

 Select some sharepoints. You should not have to authenticate! Browse to a windows server. (Note: don't use the PDC for a sharepoint) Choose connect. A window with the share points should appear. Select some sharepoints. You should not have to authenticate! Comment on this tutorial below

Reader Comments
Comments to Version 1.0 of this page [Note: you are reading version 1.2 of this page.] May 18, 2004A reader called Perdurabo When one tries to perform Step 5 of this document it fails because there is no information to configure the client machine to grab preferences from the OD server. Seems like a glaring error unless I'm missing something. May 18, 2004Brent Westmoreland also notes some holes, but offers to fill them in with some new information: In "Part 2" and "Part 3" of Greg's write up for binding to an AD domain he instructs people to join the domain without first synchronizing the time with a Domain Controller. If you do not first provide time synchronization services to your Domain Controller, then you may have trouble binding to AD through GSSAPI. You could also experience problems with single sign-on later if the clocks between the two grow too far out of skew (by default this is 5 minutes). Additionally, under "Part 3" where he says: "Login locally to the OD server using your admin account and the

launch Server Admin application. Select Open Directory/Settings Change the role to: 'Open Directory Master' Select Open Directory/Protocols. Enter your search base and write it down for later use. Examples: 'dc=domain,dc=com' or 'dc=domain,dc=local'" He does not specify whether you use the same search base as the AD server or whether this is a new search base to be used exclusively for Open Directory. This could be confusing for AD administrators who are not familiar with OD. It may also be helpful to give some troubleshooting information for the ADPlugin, I usually tell people who are having trouble to enable Remote Login from the System Preferences menu. Then use an SSH client from a monitoring client to attach* to the machine that is having trouble with the ADPlugin and issue the following commands: sudo killall -USR1 DirectoryService The above command puts lookupd in debug logging mode. Next, issue the command: tail -f /Library/Logs/DirectoryService/DirectoryService.debug.log | grep ADPlug This will allow realtime viewing of the Debug AD log in realtime. Finally, attempt to do your adbind or adlogin from the client having trouble. The ADPlugin will spew loads of useful information into the terminal window and typically allow you to figure out what might be going wrong. *As a footnote: to attach to a Mac using ssh from another Mac open Terminal.app from the /Applications/Utilities folder and type: ssh user@hostname.com

and enter the appropriate password. Comments on version 1.1: Stuck at Step 4 [Note: you are reading version 1.2 of this page.] May 28, 2004Michael Richards has a problem with the above Active Directory Integration instructions I am using the second version (1.1) of the MacWindows article How to use Active Directory and Macintosh Clients without Schema Changes. At step 4 I get stuck at "Select the domain icon (small globe) and choose the OD LDAPv3 domain. " First, there is no listing of that in the drop down menu. If I select Other and select LDAPv3 and click OK, the window never goes away. I end up having to click Cancel to get rid of the window. That's where I am stuck. If you can shed some light, please drop us a note.

TIP: AD and home users in Mac OS X 10.3.3-plus

Question June 8, 2004Nathan Mueller Greg Priglmeier's directions "How to Use Active Directory and Macintosh Clients without Schema Changes" are PERFECT! However there is only one thing lacking. How can I get AD users Mac home directories to store on the 10.3 server? Is there a setting in LDAPv3 that can be used the map the home directories? Answer June 11, 2004Josh Wisenbaker If you want to store the home folders on a Mac OS X Server using

AD for authentication then you are going to need to make a schema change or use the LDAPv3 plugin and loose all that easy AD integration work. There is something that most people miss however. By default the AD plugin creates local homes, mounts the SMB home that is in the user's AD profile on the desktop and puts the SMB home folder in the Dock. Starting with 10.3.3 Apple fully supports using network based SMB homes and there is a hidden option in the AD plugin to activate it. dsconfigad is the command line version of the AD plugin. It has two hidden options, -localhome and -mountstyle. If you execute a 'sudo dsconfigad -localhome disable' then the plugin will not create a local home, but rather use the windows SMB home folder as a network home. You can use the -mountstyle flag to specify SMB or AFP for the mount, although SFM isn't kerberized and you will get a challenge box on login for the AFP share. Greg Priglmeier agrees. "Josh is correct. AD creates home users by default." September 28, 2004Pete Shaw In response to Nathan Muellers question : I just wanted to note that I have managed with a OD master (with KDC running) OS X server with Active Directory plugin bound to Active Directory that I have managed to get network user home folders working on the OS X Server. (Josh's answer seemed to imply you could not do this with AD plug-in enabled) I had to manually alter the edu.mit.kerberos file to reflect two domains (as the autoconfig did not seem to work (I believe the OD master can overwrite also unless autocreation lines are removed). I should also note to save other people from spending too much time on this - if they make the same mistake I did. You should enter the fully qualified domain name of the server in the directory path to home folder. As I was copying some Windows entries I made the mistake of only putting the server host name in (even though this would resolve - and I had tested this). Once I resolved this everything

worked a treat. Obviously this required the command line options of dsconfigad as mentioned by Josh of dsconfigad -localhome disable' & 'dsconfigad -mountstyle afp'. September 28, 2004 -- Two readers sent suggestions: Dedrick Allen: What protocol are you using to attempt to connect to the Exchange 5.5 Server in question? Microsoft added Exchange support to Entourage X and in Office/Entourage 2004. However, its only supported for Exchange 2000 and 2003 servers because it uses WebDAV which Exchange 5.5 does not support. There are other ways to connect Entourage to Exchange 5.5 servers such as plain old POP3/SMTP and IMAP. However, you should find out from your Exchange administrator to make sure these services are enabled on the Exchange server because each service can be enabled/disabled individually. Dave Leary: I have the same Apani/Nortel setup and I have never been able to get any MicroSoft product to work over VPN since I upgraded to OS X, years ago. For me the solution was to use Apple Mail, which works well, except for the issue that it sometimes drops signatures. For some reason, the signatures come through fine on the copies to myself, but others on Windows machines don't have them show up. Since I don't generally read email on other people's accounts I haven't tried to troubleshoot this. For some perverse reason LDAP for Mail is set up through the Address Book application. Comment on this tip below

TIP: Binding OS X 10.4 to AD when it fails at Step 5

Wednesday, October 17, 2007 Rich Hinds sent in two suggestions for binding Mac OS X to

Active Directory. The failure occurred at Step 5 in our tutorial How to use Active Directory and Macintosh Clients without Schema Changes. Hinds describes the problem and the fixes: I recently had an issue whereby all OS X 10.4 clients/servers I tried to bind to a customer's Active directory would fail with "unknown error" at Step 5. The ADPlugin log would show the binding failing while trying to set the computer password. I found your very useful pages through googling the issue, and thought I would let you know what eventually fixed my issue. I believe I had two issues causing this binding problem, both DNS related. The first was that some SRV records for one of their domain controllers were missing from DNS (in particular _ldap and _kpasswd). Running "nltest /dsregdns" on the missing server should sort this, but they should also be added in automatically when the Netlogon service starts on the server, so if they are missing there could be some wider domain controller issue to investigate. The second problem (once the SRV records were sorted), and the one that was causing the step 5 failure, was that the domain controllers were multi-homed: they each had more than one IP address, and these addresses were all registered in DNS. For some reason, the AD bind process would retrieve the correct IP from DNS for each step until step 5 when it would try and talk to the servers second IP for the kpasswd (464 UDP) part of the bind. This would fail. To fix this, if possible remove the second IP address from the server. If you can't do this, remove the server A record in DNS that points to the second IP address (you might have to go in to the TCP/IP properties on the server and tell it "not to register this

connection in DNS" if you leave more than one IP address on the server, else it will re-register it in DNS). This fixed the issue for me. If you've tried these procedures please let us know.