Mac Thread, Snow Leopard AD Integration woes in Technical; Quick back story - we've been running an AD & OD integrated mac network for well over a year now, ...
29th October 2009, 12:53 AM #1
Snow Leopard AD Integration woes
Quick back story - we've been running an AD & OD integrated mac network for well over a year now, only about 30 clients for Art, running 10.5. Not perfect, but overall it all works without any major problems and it was painless to set up.
Autumn term this year, we get 50 new iMacs running 10.6. Considering we already had experiance of integrating the macs with AD we assumed it would be painless. Very wrong.
Essentially, when we bind a machine to AD, all is well. No problems adding, it appears in AD, you can log out and straight away log in as a domain user. However, shut down or restart that machine (or as I found out today, even let it go to sleep) and at least 50% of the time (probably far higher) it cannot connect to AD again - no users can log in, and directory utility reports 'Domain not responding'.
remove AD domain and re-add - it works fine
change any DNS settings - it works fine
Until next reboot.
Now we certainly arnt the only people experiancing this. A quick search reveals plenty of people suffering the same fate, with no obvious solution yet. But I assume it isnt happening to EVERYONE.
It's certainly network related - whatever it is, 10.6 obviously deals with it differently to 10.5. And its quite possibly DNS related, in that if you add the same servers manually on the client (or even remove them again afterwards) it can connect to AD (until a reboot)
One site suggested it could be something to do with the TTL value on the DC's DNS records - well its set at 3600 seconds I think, which isnt abnormally high. Doing any test on network utility brings back nothing abnormal at all, everything resolves and looks ok.
The only thing that isnt quite right, and never has been with our macs (yet has never caused a problem on 10.5) is that the PTR records dont seem to update properly - so whatever name you give a client, in ARD it appears as another computer name, and if you start terminal it appears as the wrong name. Is there something I need to set for this to work the same as a windows client would?
Of course this may well have nothing to do with it at all.
Long post sorry, but has anyone experianced the same problems, and less likely, found a solution? I'm kind of resigned to the fact we're a bit screwed unless we wait for 10.6.2 or downgrade to 10.5, but Im also hopeful someone has found a solution...
IDG Tech News
30th October 2009, 11:08 AM #2
"the PTR records dont seem to update properly - so whatever name you give a client, in ARD it appears as another computer name, and if you start terminal it appears as the wrong name"
This is because there are stale reverse pointer records hanging around that should be scavenged. In the Reverse Zones you should set the Ageing amount to 1 day or so. The default is 7 days. This aspect of Windows DNS/DHCP Services is also 'tied' in with WINS/NetBios support. When was the last time you had to support NetBios clients? Just because it's always been there and switched on does not mean it has to be used. I can't see how disabling the feature (DHCP > Advanced > disable NetBios over IP) can interfere with what client OS you currently have? - Assuming XP and above?
I don't think the above has anything to do with your problem though? Are mac clients in the same sub-net as the main servers? You could test one mac client by assigning an IP address within the server subnet to see if that makes a difference? You could also add the PDC's IP address and hostname in /etc/hosts (use a terminal editor such as nano or pico etc - don't use the Finder) to see if that helps also. Again test with one client mac.
Have you tried defining the TTL value to half the default amount yet?
Hopefully this might help?
Antonio Rocco (ACSA)
31st October 2009, 03:27 PM #3
- Rep Power
I have been having the same problem, just got our new imacs with 10.6.1. I have found that if i go in to bind to ad & od via "Preference/Accounts/Login Options/Network Account Server" i get the same as you, restart and all is screwed. But if i bind using terminal it doesn't seem to happen. I have no idea why, but it seems to have solved our woes. Hope this helps.
2nd November 2009, 09:21 AM #4
Antonio - Yeah I dont think it has anything to do with it either, but I have disabled Netbios now, as you're right - it isnt needed, and have also changed the ageing time to 1 day.
All one subnet so no problem there. And no havent tried the TTL, since it was so low to start with. Is it the default TTL in the SOA tab I need to set?
Stodge - Thanks for that. How do you bind via terminal?
2nd November 2009, 10:01 AM #5
- Rep Power
Sidewinder - Mac OS X Manual Page For dsconfigad(8) this page is how i found out about it, shows you a couple of examples at the bottom too!
2nd November 2009, 11:35 AM #6
Well, I've tried editing the hosts fille - still doesnt work
And I've tried binding with terminal - does the same thing
Oh and the macs still dont update the PTR records. Every windows client on site does, not a single mac does. On DHCP I've set to update for clients who dont suipport synamic updates but even this doesnt make a difference
2nd November 2009, 08:46 PM #7
That's because Macs are DDNS aware on the forward pointer only. It's not their fault because that's how the OS works. What you see in Terminal is the reverse pointer record associated with the IP address. You have to manually clear these out as making the Ageing setting to 1 day does not necessarily do this. Renew the DHCP Lease afterwards by clicking the appropriate button in the Network Preferences Pane or simply Restart.
On a client Mac look at the assigned IP address launch terminal and issue:
It will probably return at least one (if not more) reverse pointers that have been associated with that IP address previously.
"macs still dont update the PTR records. Every windows client on site does, not a single mac does"
This is not meant as a criticism but expecting macs to 'behave' like PCs makes no sense? Apple have implemented DNS & BIND fully since the beginning. AFAIK Microsoft have their own take on this which is not strictly the same?
It's a shame the suggestions have not worked. What is interesting is at stodge1000's site binding using the command line worked. Yet at your site nothing. Clearly each Active Directory is unique. As such macs will find every flaw and weakness in that environment like nothing else. The trick is finding out what the weaknesses are? Of course this could all be rubbish and it might all get fixed in the next Software Update - 10.6.2 anyone?
Yours is not a CC3/CC4 build is it by any chance?
Antonio Rocco (ACSA)
Last edited by AntonioRocco; 2nd November 2009 at 08:51 PM.
2nd November 2009, 09:21 PM #8
I don't think the reverse pointers is having much affect. When you dual-boot between OS X and windows IIRC you end up with pointers that are wrong anyway throughout the day since windows updates the pointers and OS X doesn't. You could try reserved IP with a manually configured DNS entry for each client.
This can be scripted, both to build the DHCP Scope, DNS entries and set the configuration for each client from Deploy Studio. I'm not 100% on the Deploy Studio bit though as i have not done that bit myself.
But this is my experience of 10.5 I have not tried 10.6 mass deployment although i have got one machine installed and seems to be fine. Also check your forward DNS record in your AD DNS settings. I found this to cause major grief with OS X logging in but this may not be your issue.
Also try just kicking the Directory Service to see if this resolves the issue without re-binding.
It maybe without the S on the end. I can never remember
sudo Killall DirectoryServices
Also have you bound to both the AD and OD? If bound to the OD, try just adding the server instead. I do this now with my current install of 10.5 and seems to work a bit better than previous efforts. You can still manage them through OD as well.
I have found though on the new NVidia machines that the networking is a lot slower to react than it's Intel counterparts. The process i have seen is that the time "could" be incorrect until the network kicks in, then it picks up it's IP address (eventually), the time then re-syncs and then the Directories start working. This could be the cause of the problem. I had major problems with OS X and XP over the last few months due to the Daylight saving time messing up my clocks causing all sorts of problems. Check the logs for time skew errors as well.
Just my 2p worth. May be non-related entirely but you never know
This flushes the DNS cache on the client in case it is holding stale records.
Last edited by HodgeHi; 2nd November 2009 at 09:23 PM.
3rd November 2009, 08:54 AM #9
Apologies, I assumed that it was a modern DNS client feature rather than MS's per se.
Originally Posted by AntonioRocco
Yeah it is frustrating that didnt work. The command line way does the exact same thing as the GUI so its odd that it could work, but I was hoping it would.
Originally Posted by AntonioRocco
Not ruling out a flaw with our AD, nor saying we're perfect because I doubt we are, but every test I do comes back fine, all DNS tests come back fine, and we never have any major AD problems, its essentially set up to MS's best practices.
And we're vanilla, no CC3/4.
For now we're going to try going back to 10.5 because as much as I wanted to fix this, we're not getting anywhere fast and people are understandably getting a bit peeved that their new IT suite cant be used...
Hi, yeah I think that may work, but again only till it is rebooted
Originally Posted by HodgeHi
Bound to AD and OD. No problems at all with OD, that stays bound through thick and thin. Have been adding using the server name yeah.
Originally Posted by HodgeHi
And I've tried it with just AD binding to cover the small possibility that the OD bind was causing problems, but it was the same.
Thats interesting, maybe we're just not waiting long enough! lol. On occasion waiting 30 seconds before logging in produces a better result but not often. Suppose if we encounter the same problems with 10.5 on these macs (hope not!) it could be somewhat down to hardware..
Originally Posted by HodgeHi
3rd November 2009, 09:02 AM #10
Im my experience the NVidia machines can range from anywhere between 30 seconds right upto about a minute. I found out that on a cold reboot it does usually take longer than on a restart. I found that after the break my only snow leopard machine did take a while longer than usual.
This probably being down to DHCP lease times though more than anything since these chipsets tend to have a problem with obtaining a lease. One thing you could try to remove this possibility is do something that someone else suggested to me. Use the airport connection if possible to see if that removes the issue.
I removed some of the problems i was having with these nforce chipsets on the Windows side by updating the drivers to v 22.214.171.124. Unfortunately you can't do the same for OS X.
Hope this helps a little. I know all too well just how annoying this can be
Also don't forget if the time is out by more than 1 seconds over 5 minutes this connection will stop responding as well IIRC.
Check the logs to see what happens.
Last edited by HodgeHi; 3rd November 2009 at 09:04 AM.
4th November 2009, 12:43 PM #11
Well I've imaged almost the entire room with 10.5.8 and its all working fine - even got a class working in there already. We'll keep an eye on 10.6, maybe keep testing it (if we ever get time) but for now this seems to work for us.
Thanks for your help though everyone.
23rd June 2010, 01:08 PM #12
- Rep Power
That's kind of disappointing you rolled back. I was hoping for a solution.
Been having the same issues, although not as often with my 10.6.x (now 4) clients. They remain bound for X amount of days, but at random (usually 2 machines a week or so) will just report that the AD domain is no longer responding.
29th June 2010, 12:39 PM #13
We did roll back at that point, but since then we have upgraded the Art department too and with the newer iMacs there was no way to use 10.5 so 10.6 it was. Since 10.6.3 it seems to be more stable, very rarely does one come unattached from the domain. What I did do was to add .local to the DNS search domains, as well as our domain (ourschool.local). Was recommended to me by someone, no idea why it works, but it seems to.
Since then we have also bougth upgrades for our macbooks, and that has worked ok as well. More cases of 'domain not responding' there, but that could be something to do with wireless connections not being ready in time, not sure yet.
All in all I think in future when a new revision os OS X comes out, I will make sure we wait till at least the .2 version just to avoid any problems like we've had (and in the case of 10.6, some software compatibility too)
29th July 2010, 10:50 PM #14
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!
(Yes, I've posted this in two places :P )
3 Thanks to Ephelyon:
dezt (3rd August 2010), GrumbleDook (2nd September 2010), Zoom7000 (11th September 2010)
10th August 2010, 02:48 PM #15
- Rep Power
Thanks Ephelyon for this fix! I had been dreading this summer break as I needed to solve this problem on our trolley of wireless macbooks. The fix seems to be working fine so far.
I had an initial problem with trying to use the 'Administrator' account to 'see'. The script showed an immediate authentication without any failed attempts. I checked for connectivity in Accounts -> Login Options and the domain was still not responding. I changed the account and it worked properly, as explained in your post. I can only presume the problem was to do with the local admin account I have created on the macbook. It is also called Administrator.
I am new at Mac administration and struggled a bit with your instructions. I didn't know how to create or edit the script files or how to use the chown and chmod commands. I got there in the end with the help of google. Could you post a more detailed set of instructions? I would do it myself but I am unsure if the methods I have used are the best/easiest.
Last Post: 29th September 2009, 06:35 PM
By Chuckster in forum General Chat
Last Post: 24th September 2009, 12:57 PM
Last Post: 2nd September 2009, 08:26 AM
Last Post: 15th August 2009, 06:39 PM
Last Post: 28th July 2009, 09:01 PM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)