Does that count as a one liner?
Does that count as a one liner?
Apple’s document on Extending and Troubleshooting Directory Services has a lot of good info.
One correction though is that the debug level must be an integer.
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 2
I’ve notified Apple, so this may be fixed by the time you read this.
Update: That link is dead. Here is an article that offers some similar information.
I was getting random AD plugin connection issues after joining to Active Directory. dsconfigad showed no errors, but sometimes I would not get a connection and I would have to rejoin. The problem turned out to be related to replication.
The AD plugin initially has no knowledge of which AD site and domain controllers are considered local to your subnet, so it discovers any domain controllers and contacts one to lookup the site information. During this process, and in general, the AD Plugin keeps an LDAP connection open to the domain controller. The AD plugin likes to reuse these LDAP connections, presumably for performance reasons. When it is time to actually add the computer to the domain, the AD Plugin reuses this existing connection. The problem is that this domain controller is not necessarily one within your AD site.
At this point, if the Mac is restarted or DirectoryService is killed, any new connections will be made to a DC in the subnet’s AD site, but if your computer was added to a non-local DC, the local DCs may have no knowledge of your computer because the computer account has not yet replicated to them.
This problem can appear to be quite random because sometimes you’ll get lucky and get a local DC for the join, or you might catch the replication at the right time. You might also see bad password errors in the DirectoryService debug logs. I have filed a bug report on this, and I don’t have a good workaround for now other than — don’t reboot or restart DirectoryService after a join. Of course if you know your replication schedules, you could just wait until you are sure replication is completed.
This same issue can present itself with unjoins and rejoins.
You can see what domain controllers you are connecting to during the join using the following shell command assuming your are joining using dsconfigad:
while [ 1 ]; do if netstat -a | grep ldap| grep ESTAB; then ps auxww | grep dsconfigad | grep -v grep; date;fi; done
If you have joined, unjoined, and rejoined and think you may be seeing replication issues, compare the whenCreated attribute of the computer account on different domain controllers using ldapsearch.
ldapsearch -LLL -v -W -x -h domaincontrollerfromsite1.subdomain.forest.com -D firstname.lastname@example.org -b "OU=Computers,DC=subdomain,DC=forest,DC=com" CN=machine-join-name | grep whenCreated:
If an older out of sync computer account exists, its whenCreated date will be different from the domain controller the computer was just added to until the last join has replicated to all the servers.
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 email@example.com -b "DC=domain,DC=forest,DC=com" "(&(objectCategory=cn=computer,cn=schema,cn=configuration,dc=forest,dc=com)
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.
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
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.