Patrick Timms shared a DNS fix for an Active Directory authentication problem with .local domains. His article describes what is happening and provides a StartupItem shell script:
This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active Directory authentication issue on Snow Leopard, i.e. where at least 50 percent of the time the Macs will fail to authenticate AD users following a reboot and display "This domain is not responding" in Accounts -> Login Options. I haven't seen any other definitive fixes for this problem yet, so I thought I'd post something that works 100 percent for us.
The problem, as I understand it, comes down to Apple's buggy Multicast DNS Responder implementation (the processes "mDNSResponder" and "mDNSResponderHelper"), whereby .local domains conflict with the Bonjour service and the KDC(s) for the Windows domain can't be resolved, causing authentication to fail. None of the multitude of "fixes" I've seen posted so far have had much success at my workplace, e.g. adding .local to the DNS domain search path, increasing the mdns_timeout value, adding the nameservers / domain controllers to /etc/hosts or setting the AD preferred server to the IP address of a domain controller.
As the problem only rears its ugly head when a machine is rebooted (for us), the logical choice for a guaranteed automated fix is to create a StartupItem. Unbinding and rebinding to the domain will fix the problem, but apart from being messy, laborious and causing problems with managed computer preferences mapped to AD computer accounts, which then change, this sometimes fails when automated from the CLI over a period of time, with computer accounts not being successfully recreated and etc. So that's out.
Killing the mDNSResponder process is also known to work well, but occasionally fails. Changing any form of DNS setting (to a different value and then back to the old one) will fix it sometimes as well, but neither of these methods work 100 percent of the time. It therefore seems logical to have our StartupItem shell script use a While Loop to keep repeating the action until the domain is recognised as available again, testing for connectivity in between. Restarting the responder is the most effective option of the two, but killing its process too often (as the Launch Daemon will automatically respawn it) sometimes goes wrong and the process is somehow "permakilled" until reboot - at that point, all DNS resolution goes down the drain and a number of other critical system functions will also begin to fail.
This leaves changing a DNS setting. The one I've picked (setting the domain search path to the .local domain in question, which is probably the right setting for most deployments anyway) can be done as many times as you like without causing problems, and while it may typically take over 100 attempts to fix the problem, this normally doesn't last more than about 30 seconds for us. I've just told our users to give the machine around 30 seconds from when it displays the login window before trying it, and they're fine with that. All our Macs now work first time, every time with no problems.
To create this StartupItem, create the following directory as root:
Then chown it to root:wheel and chmod it to 755. These must also be the owner/permissions on the two files it will contain, below:
Contents of our /Library/StartupItems/FixADAuth/FixADAuth:
date > /var/log/FixADAuth.log
while [ $AuthSuccess != 1 ]
id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local; n=$(($n+1))
echo Authentication successful: $AuthSuccess >> /var/log/FixADAuth.log echo Operation count: $n >> /var/log/FixADAuth.log
date >> /var/log/FixADAuth.log
Contents of our /Library/StartupItems/FixADAuth/StartupParameters.plist:
Description = "Fixes Active Directory authentication issue";
Uses = ("Disks");
Obviously you'll need to change "middlewich.local" to your own domain name (and the network interface name if your connection is wireless). The script checks to see if it can see the user "Administrator" on the domain, as he's a fairly common bloke, but if you've renamed yours for security reasons then pick another one. I've also included some logging functionality for debug purposes, so you can verify how well the script is working if you need to and time it in your environment before telling the users how long to wait. The /var/log/FixADAuth.log file will contain the date/time the process started, the success variable set to 1 (just to verify), how many DNS operations were required to fix the problem, and the date/time it ended. For us the time difference is normally about +30-40 seconds with around 120-180 operations taking place. Once you're happy with the script, you can strip it down to its bare functionality if you like, like so for us:
while [ $AuthSuccess != 1 ]
id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local
I hope this helps someone!
A number of readers report that a fix for Mac authentication in .local domains works for them. There were also questions and a further suggestion. Alan Silcott reports:
Just wanted to say that the article: "TIP: Fix for Mac AD authentication failure after reboot on .local domains" fixed my problems with Snow Leopard losing the AD connection with our .local domain. This article was incredibly helpful.
It also worked for Clint Baxter, but he had a question about notebooks:
Your fix located here worked great for a client of mine with an iMac bound to a Win2003 server AD. My question is, what about a laptop user? I have a MacBook Pro I use at work, and have / had it bound to our AD. Of course it doesn't reconnect after a reboot. I would implement your fix, except, what if I'm off site and need to reboot? Will the script keep running non-stop and never connect because I'm not here on our network?
If you know the answer
Todd Higgins provided us a link to an Apple article, which we've reported as the fix to another problem, "TIP: Fix for Snow Leopard AD clients getting stuck in screen saver in .local Domains." We suspect this is actually the same problem. Higgins reports:
This is a known issue and Apple has a kbase article that describes how to resolve the problem by lengthening the timeout .local name lookups.
If you've tried Apple's approach for Mac AD authentication failures with Snow Leopard