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% 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% 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% 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! :)
Hi this script comes back with an error 'Expected end of line, etc. but found unknown token.'
can you help?
I know the script works as it's been copied and pasted directly and success has been reported from other users in this thread:
Please check to ensure you have entered the code 100% accurately.
Some of this has been posted in the thread buy figured I'd share my findings on this since I did a fair bit of research on this last year. I had it posted on my blog here TwistedMac - Fix/Solution for using Mac OS X with AD authentication
Fix/Solution for using Mac OS X with AD (Active Directory) authentication
For sometime now we have had an issue with the Macs keeping bound to AD (Active Directory). For some reason they lose the ability to authenticate which would usually happens after a couple weeks of a Mac being bound to AD.
This has been pretty consistent for over a year now, which has prevented us from using AD for user authentication. In turn we had to go to using a local “Student” user on the Macs but with a local user we lose the ability to track printing with PCounter and the tracking of users login info.
You should only be having this issue if you are using the following together:
• Mac OS X 10.5+
• AD (Active Directory) for Authentication
• Faronics Deep Freeze
What I found online is that there is a 14 day password renewal period that is a standard 'recommended' by Microsoft in order to keep a good level of trust between client computers and Active Directory server(s).
For everyday use this is not something to worry about but in a lab setting that uses Faronics Deep Freeze the 14 day password renewal will cause issues. When a Mac is bound to an AD server a private unique key is created between the two. Due to the default 14 day password renewal the Mac looks to the AD server to renew this key but if frozen this key does not get changed and in turn, though the status of AD still shows green and functional users will not be able to authenticate with an AD account.
If you do not run Deep Freeze you will not experience this issue.
To solve this issue there are three solutions:
1. Disable or uninstall Deep Freeze.
2. With an individual client/image install, you can run the following Terminal command that will change the password expiration time. dsconfigad -passinterval 0
Setting the system to a password renewal period of “0” ignores the need to check the authenticated account that binds the client Mac to AD and requesting a new private key.
3. If you are using Deploy Studio for lab imaging you just need to set the “Password Change Interval” by using the ‘Active Directory binding task” found in the Deploy Studio Workflow options as seen in the following image.
For my test I imaged 12 Macs in our common area. Prior to this test I was un-binding & re-binding all of these Macs to AD aprox. every 2 weeks so that students could continue to print from their credited account. Since I reimaged these computers with the “Password Change Interval” set to “0” I have not had one computer drop from AD and lose the ability to have users login with AD credentials. ** In short, if you are running Mac, AD & Deep Freeze you need to set the password expiration time to “0” to prevent AD authentication from breaking.
This is a very helpful solution, but unfortunately it's for a different issue. In our case, the Macs are losing their connection to AD on most, if not all, restarts. You've clearly done a lot of work on this though.
What's Deep Freeze then?