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.
April 23, 2008 at 7:36 pm
I am having the exact same issue, however I can not find the bugs referenced in your post. It’s pretty annoying too, when in 10.4.x it worked perfectly.
April 24, 2008 at 1:21 am
You can’t see others’ bugs (unless you are Apple), but you can list others’ bugs in your own bug report to help let Apple know that you are having the same problem.
May 29, 2008 at 3:13 am
[...] isn’t fixed is the slow logins on AD environments with an R2 schema that hasn’t been extended with Mac [...]
June 13, 2008 at 7:34 pm
[...] June 13, 2008 — Kyle Crawford I’ve been hassling Apple about this issue for quite a [...]
October 30, 2008 at 11:07 am
is there an index for the macAddress attribute in AD. You should get alot more quicker queries if you index that attribute
September 25, 2009 at 10:22 pm
Another work-around, given that the “macAddress” attribute is not actually being used: use ADSIEDIT to change the “lDapDisplayName” for the “macAddress” attribute to something like “macAddress-CHANGED” or “macAddress-workaround” or whatever.
If an ldap query references a non-existent attribute, it will just ignore it immediately, so no delay for lookups. We have the Mac issue, as well as the exact same issue with another application, and since neither is actually using the attribute in question (and no other app is referencing the attributes, either), renaming solves our issues.
The one caveat being that you have to remember/document that this change was made, or you will have to track it down at a later date (if ever) if the macAddress attribute is ever actually needed at some point.
USE WITH CAUTION!
Use ADSIEDIT.MSC to edit “macAddress” in the “Schema” container, changing the “lDapDisplayName” in the properties for “macAddress” to something different.
You have to be in Schema Admins, and you have to do this on the domain controller with the Schema Master role, and changes have to be enabled.
Here’s a nice, succinct reference to changing the AD schema:
http://www.setup32.com/network-administration/active-directory/modifying-active-directorys-schema.php
– Rob “I” –