Snow Leopard AD Integration woes

[sidewinder]

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'.

 

From here:

 

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...

[AntonioRocco]

Hi

 

"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)

[stodge1000]

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.

[sidewinder]

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?

[stodge1000]

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!

[sidewinder]

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

[AntonioRocco]

Hi

 

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:

 

host IPaddressofMac

 

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)

Edited November 2, 2009 by AntonioRocco

[HodgeHi]

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.

 

Type:

sudo Killall DirectoryServices

 

It maybe without the S on the end. I can never remember

 

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

 

Also try:

dscacheutil -flushcache

 

This flushes the DNS cache on the client in case it is holding stale records.

Edited November 2, 2009 by HodgeHi

[sidewinder]

Hi

 

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.

 

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?

 

Apologies, I assumed that it was a modern DNS client feature rather than MS's per se.

 

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?

 

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.

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...

 

 

 

Also try just kicking the Directory Service to see if this resolves the issue without re-binding.

 

Type:

sudo Killall DirectoryServices

 

It maybe without the S on the end. I can never remember

 

Hi, yeah I think that may work, but again only till it is rebooted

 

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.

 

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.

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.

 

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.

 

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..

[HodgeHi]

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 73.1.0.0. 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.

Edited November 3, 2009 by HodgeHi

[sidewinder]

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.

[CAJensen]

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.

[sidewinder]

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)

[Ephelyon]

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:

 

/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!

 

(Yes, I've posted this in two places )

[markcromwell]

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.

 

Thanks again!!!!

[Ephelyon]

Certainly markcromwell!

 

You are correct; if you had a local account called Administrator, then the id command would always succeed. I didn't anticipate there being a local account with the same name...

 

I have since come up with an improved method of detecting when the system is ready to accept network logins, rather than just waiting 30 seconds. It seems the Mac OS login window has the ability to display the status of its connection to network login servers, showing either a red or a green light (or orange if you have multiple connections and not all are available yet). If your Mac clients are bound to an Open Directory server (i.e. a Mac server) as well as Active Directory, you can set this option using Workgroup Manager in Preferences > Login Window for individual computer accounts or a group of them. If you don't use Open Directory, you can specify this manually on each client using a command (the last one below). Then you can just tell your users to wait until the light goes green before trying to log in.

 

Now for more detailed instructions for creating the StartupItem, including the modification to the login window:

 

sudo su

mkdir /Library/StartupItems/FixADAuth

nano /Library/StartupItems/FixADAuth/FixADAuth (enter script from above)

nano /Library/StartupItems/FixADAuth/StartupParameters.plist (enter PList from above)

chmod 755 /Library/StartupItems/FixADAuth/FixADAuth

defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo DSStatus (not needed if you can set this via OD)

 

Turns out if you're running as root the owner/group permissions will be correct on creation so you don't need to use chown, and only the script itself will need to be chmodded to allow execution.

[TomH]

Hi Guys,

 

These .local issues are generally resolved in 10.6.4 where we have them installed, be careful with mDNSResponder as its now rolled in with DNS.

 

Tom

[Ephelyon]

First thing I tried was installing the latest updates, including 10.6.4. Didn't help very much... :/

[CAJensen]

Thanks, Eph. We experience a similar issue, but have an actual domain. Logging in generally works fine for most of our users, but maybe twice a week I get a user who cannot login. Upon logging in under a locadmin account, the domain status reports as 'not responding'. I then have to simply rebind.

 

Would pointing your script at our domain and setting it to run at login likely resolve this issue?

 

If I don't see a response, I'll certainly be testing it. Thanks again for the work.

[Ephelyon]

That's the idea of it, so yeah, I'd should work in that scenario =]

[mbrunt]

Hi Eph, your script looks good, shame snow leopard didnt get it right! Anyway, Im a little confused about the nano bit, i can make a directory and chmod it etc but im confused whats next?

 

Thanks

[Ephelyon]

nano is a text editor. You can use it to create the two files (FixADAuthand StartupParameters.plist) using the contents given above.

[jubbi]

Mac OS X v10.6: Active Directory binding lost on network transition (.local domain)

This has sorted it out for me. I increased the value to 10 as a couple of systems are hanging off very poor desktop switches. The fix has to be re-applied after every service pack as the file this refers to is replaced by 10.6.4 back to 2!

[Ephelyon]

Didn't work for us, that's why I wrote the script :/

[mbrunt]

Hi Eph, your script doesnt work for me, any more suggestions from anyone? I was thinking of forcing a unbind and then bind at logon?