Parallels Desktop 7.0 for Mac Run all the applications you need without switching between Windows and Mac OS X! Better integration of Mac and Windows. Supports Windows 7 Aero, with graphics peformance up to 7 times greater than before. Supports Apple trackpad gestures, new Crystal mode, speech recognition, good notebook battery life, and more.

"Parallels is the clear winner running each group of tests."
--MacTech Magazine

Updated August 18, 2010
 

Deals from Amazon

Windows 7
Windows XP for your Mac, for running with Boot Camp, Parallels or VMware

MacDrive 8
Access your Mac OS X partition from
Boot Camp

The New Kindle
Smaller, lighter, faster
$139



Snow Leopard Tips and Reports

iPhone and Exchange Server Tips and Reports

Windows Servers and Macs


Windows on Mac

- Virtual PC 7.x
(PowerPC Macs




GoToMeeting - Online Meetings Made Easy

TIP: Fix for Mac AD authentication failure after reboot on .local domains

Wednesday, August 4, 2010

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:

/Library/StartupItems/FixADAuth

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:

#!/bin/bash
. /etc/rc.common
date > /var/log/FixADAuth.log
n=0
AuthSuccess=0
while [ $AuthSuccess != 1 ]
do
id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local; n=$(($n+1))
done
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:

#!/bin/bash
. /etc/rc.common
AuthSuccess=0
while [ $AuthSuccess != 1 ]
do
id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local
done

I hope this helps someone!

If you've tried this approach

Readers say fix for Mac AD in .local domains works, and some info from Apple

Wednesday, August 18, 2010

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

Current news on the MacWindows home page

CrossOver 10 runs Windows apps on a Mac--without Windows
Improved Outlook support, Quicken 2009, more Windows apps. Give your Mac ActiveX in Internet Explorer, launched directly from the Finder.
CrossOver Games runs Left4Dead, Warcraft, Steam, Spore, and others on your Mac.

Starts at only $40 (and no need to buy Windows!) Free trial from CodeWeavers.
Click here for more.


Other MacWindows Departments

| Product Solutions | Reports and Tips | News Archives | Site Map |
|
MacWindows Home |

| Top of Page |

This site created and maintained by
Copyright 2010 John Rizzo. All rights reserved.