Notes on Leopard AD Plugin 10.5.2

The Active Directory plugin is finally usable in 10.5.2, but some environments require workarounds.

1.) Your domain must resolve to the ip address of a domain controller. This was not a requirement in previous versions, but Apple is apparently making it a requirement as they closed my bug stating that it was a configuration issue with Active Directory since creation of a domain sets up this dns info by default. If your domain does not resolve to an ip, you need to fix it, or as a workaround, edit your /etc/hosts file to point the ip of one of your domain controllers.

for example if you know you have a domain controller at and your fully qualified domain is, you’d add this line to /etc/hosts

2.) Allow Authentication from any domain in forest does not work. Uncheck this box in Directory Utility or using the corresponding flag in dsconfigad. If you don’t do this, the join may succeed, but you won’t be able to lookup or authenticate users or even use dscl on Active Directory. When you uncheck this option, just be sure to add the correct domains to your authentication search path in Search Policy of Directory Utiltity.

3.) Allow Administration by Active Directory Groups does not seem to work. In 10.4, this option seems to nest the AD group you want to allow for administration into the local admin group, so the workaround is to do the same in 10.5 manually using dseditgroup.

sudo dseditgroup -o edit -a “DOMAIN\group name” -t group admin

replacing DOMAIN\group name with your domain and group that you want to give admin access.

This group nesting method gives members of your AD group admin access for both Apple’s Authorization APIs and sudo.

These workarounds got me working, logins are painfully slow, but that may be due to the hosts hack.

Update: Under 10.5.3, most of these problems are resolved. If you are still having slow logins/joins, there are possible workarounds.

9 thoughts on “Notes on Leopard AD Plugin 10.5.2

  1. I am not sure about #1 in that this is a “new” requirement. AD has always worked that way. AD provides DNS, and when you set it up, it creates a record for itself. Doing a lookup on that record should come back with a list of domain controllers IPs for that domain. This is how the AD plugin has always found domain controllers. It has never used the older NetBIOS compatibility mode… And this is why you need to use the AD domain controller IP as your DNS server in OSX if you are going to use the AD plugin. You shouldn’t be adding it to /etc hosts because the list of DCs is subject to change.

  2. asus: Thanks for the comments. I understand that the dns record is created by default, but the AD plugin uses SVR records to locate domain controllers using something like “dig any” at least it did in 10.4. So why not use the SVR records for domain controller discovery in 10.5. Tiger’s AD plugin joins just fine to a domain that does not resolve to a DC, so in that sense it is a ‘new’ requirement.

  3. asus: I agree that it shouldn’t be in the hosts file. It is a hack, but I am holding out a bit longer for Apple to fix the issue before modifying dns.

  4. We’re still having slow login issues with AD even with all these supplied fixes. We’re getting a 2-3 minute login time for domain accounts and even local administrator. Root has immediate login like it should be. Do you know what might be causing this?

  5. I manage a large number of Macs in an AD environment. I’ve seen the slow login issue with the 10.5.x machines as well.

    I have found a workaround, though. It appears that this can be an issue with AD domains using .local . It seems to conflict with something in the Bonjour broadcasting. If you disable the Bonjour daemon, your login times should drop down to 5-10 seconds.

    I prefer to use this utility :

    Hopefully, this will help you out.

  6. Pingback: Notes on Leopard AD Plugin 10.5.3 « Pattern Buffer:

  7. Doesnt work for me. Im trying to add the AD group named “Mac Power Users” from my AD domain named “SIMR01” to the local admin group on my Leopard Mac which is bound to AD and sees the group as expected. It hates the syntax. What am I doing wrong? See below:

    m006cafvux:~ root# dseditgroup -o edit -a “SIMR01\Mac Power Users” -t group admin
    record ““SIMR01Mac” of type “dsRecTypeStandard:Users” not found.
    ERROR: A Directory Service error occured.
    -14136: eDSRecordNotFound

  8. 3 Observations:

    1) Double quotes do NOT work. You must use single quotes:

    BAD: sudo dseditgroup -o edit -a “DOMAIN\group name” -t group admin

    GOOD: sudo dseditgroup -o edit -a ‘DOMAIN\group name’ -t group admin

    2) In my observations (running both 10.5.2 and 10.5.3), the process of nesting an AD group into a local admin group does NOT work when the Mac is out off the LAN/domain (i.e.; on a Mac laptop, for example). Thus, the behavior of nesting an AD group in a local group via the dseditgroup command is not any different than checking the “Allow Administration By” box in the Directory Utility (described in #3 above in the original article at the top of this page). I get the exact same results in my environment. I have Windows 2003 DCs. Plain vanilla schema, no AD forest. Single AD domain. 500 computers – mostly Windows XP and Leopard 10.5 desktops.

    3) I dont see any difference with 10.5.2 and 10.5.3 regarding any of the topics listed in this article. I guess Im waiting for 10.5.4

    4) Have you noticed that AD paswword expiration notices dont work in Leopard’s login window? They used to work in 10.4 Tiger. I think its a Kerberos problem. Here’s a handy app you can use as a workaround:

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s