Fix for slow AD logins/joins caused by macAddress query

I’ve been hassling Apple about this issue for quite a while.

Apple has two workarounds for this problem:

1.) Index the macAddress attribute in AD. Even though the macAddress is not part of the Computer class by default, the AD plugin queries on it for joins ( to ensure the the computer that you are adding doesn’t already exist ), and for MCX ( managed client information ). Normally I would frown on any changes to AD since the Enterprise doesn’t like making changes to their infrastructure just to support Macs. However, supposedly in Windows 2008 Server, the macAddress attribute is indexed by default, so at least their is some justification there.

2.) If you’d prefer to make changes on your client machines rather than bother your AD administrators with a Mac-specific fix, remove the ENetAddress mapping from /Library/Preferences/ActiveDirectory.plist. The lines to remove look like this:

<key>1.3.6.1.1.1.1.22</key>
<string>dsAttrTypeStandard:ENetAddress</string>


The key is the OID for the macAddress attribute in AD.
The string value is the mapping to a native Open Directory attribute, which Apple calls ENetAddress.

Update:
You’ll also need to remove /Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist as this file also contains the cached mappings.

Then killall -9 DirectoryService or reboot the machine.

Notes on Leopard AD Plugin 10.5.3

All of the bugs listed here are fixed in 10.5.3.

What isn’t fixed is the slow logins on AD environments with an R2 schema that hasn’t been extended with Mac attributes.

Again, please file bug reports if you are experiencing this issue.

10.5 AD plugin slow logins related to macAddress query

The slow login times in the Leopard AD plugin seem to be related to a search by macAddress.  If you killall -USR1 DirectoryService, and login on a Leopard machine bound to AD, you’ll notice a query on macAddress in the /Library/Logs/DirectoryService/DirectoryService.debug.log. I am not sure the purpose of this query, but our computer objects don’t even use the macAddress attribute, so the query always results in no records found.

I can manually execute the same query and the time almost perfectly matches the delay I see with logins; about 45 seconds.

time ldapsearch -v -w password -x -h domaincontroller.domain.forest.com -D username@domain.forest.com -b "DC=domain,DC=forest,DC=com" "(&(objectCategory=cn=computer,cn=schema,cn=configuration,dc=forest,dc=com)
(macAddress=00:1a:22:ee:31:ac))”

Just substitute your own domain, forest, domain controller, username, password, and mac address etc to test.

I’ve tried manually mapping macAddress to another attribute, but it didn’t make a difference, so I don’t have any workaround to offer. Adding the macAddress attribute to your computer objects in AD might speed things up, but I have not tested this.  I’ve notified Apple of the issue in radar 5752763, which is marked as a Duplicate of 5679705.  If you see this macAddress query taking a long time, please report this to Apple so it can get fixed sooner rather than later.  Actually, this same query is used during the join process, which may explain the long join times while it searches for an existing computer.

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 10.3.1.23 and your fully qualified domain is domain.forest.com, you’d add this line to /etc/hosts

10.3.1.23 domain.forest.com

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.

Finding your Active Directory Site and Domain Controllers

The AD Plugin uses information in Sites in your Active Directory Configuration to get a list of Domain Controllers to use for LDAP and Kerberos connections. Sites are a method of configuring Active Directory based on a physical or network based location. Clients connecting to Active Directory use this information to determine which domain controllers are nearby and therefore likely to respond the fastest. Plus if you have Domain Controllers in remote or distant locations, without using Sites, you are pushing traffic over a WAN unnecessarily.

This is one of the steps you’ll see when joining a machine to AD. Locating Domain Controllers… or something like that.

First it uses DNS to lookup SVR records to locate ANY domain controller. You can do the same using the dig command:

dig any _kerberos._tcp.yourdomain.yourforest.com

This will give you a list of domain controllers to choose from. Once you have one of your domain controllers to talk to, you can read the same information that the AD Plugin does to figure out your Site by querying AD with ldapsearch and your subnet:

ldapsearch -x -h "somedomaincontroller.yourforest.com" -b "CN=Subnets,CN=Sites,CN=Configuration,dc=yourforest,dc=com" -D "username@yourdomain.yourforest.com" -W "(cn=10.31.0.0/16)" siteObject

From this you will get your Site, which you can then use with ldapsearch again to get a list of domain controllers for your site:

ldapsearch -x -h "somedomaincontroller.yourforest.com" -b "CN=SERVERS,CN=YOURSITENAME,CN=Sites,CN=Configuration,dc=yourforest,dc=com" -D "username@yourdomain.yourforest.com" -W dNSHostName | grep dNSHostName

Pretty cool. Takes some more of the mystery out of the AD plugin.

Notes: Enter each command as a single line. Substitute ‘yourdomain’ with your own domain and ‘yourforest’ with your own forest and ‘username’ with a your username for your domain and ‘10.31.0.0/16′ with your own subnet and ‘YOURSITENAME’ with the site name you found in the previous step. Also, using ldapsearch in this way does a simple BIND authentication which sends your password in CLEAR TEXT. Change your password after using this command if you are in a secure environment.