Some computers loosing AD binding

We just setup new computer labs with iMacs running OS X 10.6.8 (Snow Leopard). This is setup on a network with AD authenticating users and Xserve managing the client rules. After setting up the Lion clients we noticed the users intermittently cannot log in, the correct password is entered and the screen just shakes. The only way to get them to log back in was to log in a local admin, unbind then rebind them to our AD server.

This happens quite often, sometimes twice a day, and the laborious task of going computer to computer to do this is unacceptable. I cannot say for sure but I believe the problem only, again intermittently, happens after rebooting the computer. We saw some things online, including on apples website, about this issue and apples fix was to increase the mdns timeout option to 5 instead of 2 to allow the computer more time to authenticate to AD. This proved completely ineffective. I wrote a startup script that will unbind then rebind the machine every time the computer boots. This seems to work, obviously since it is doing exactly what I am doing, once the computer is on, every time it boots.

We then, just yesterday, got 2 more machines that did this same thing, only these 2 machines were Mac OS X 10.5.8 (Leopard) clients. So it now seems as if it may not be isolated to Snow Leopard. But we do not have any issues with our Windows clients on the network, not yet anyway.

Now after talking to an apple engineer he told us that our problem was we were binding to "our" and "", when checking the hosts, points to """ """ and something like "" (which i am not really sure what that is, i think it is some data management, backup company or something? I will investigate that further). He said we need to bind specifically to "" AND "". When binding  to just "our" he said it could at any point look at the old AD hosts or the other host that is in there and fail to bind. This made perfect sense, or at least it seemed to.

Anyway, dc1old and dc2old are, yes you guessed it, our old DC controllers that we don't use anymore and dc1new/dc2new are out current DC controllers running AD. So I removed the bind for "our" and tried to bind to "", this failed, it could not resolve the host name, then I tried doing the same for "", this failed, could not resolve host name.

So, my question is, is the apple engineer correct in saying that we need to be more specific with our bind, and bind to both AD servers? If so, why do our windows machines work perfectly fine when joining just simply ""?

Should I create more specific lookup zones for these domain controllers so I can get the Apples to be able to resolve those server names? Or should I just remove the old domain controllers, and the weird site that I am not familiar with, so that the Apple computers, and all windows computers can still join to just simply "" and now it only has 2 (correct) choices to choose from when using that host name?

Also, if modifying the lookup zones to reflect the change to allow 2 binds for the apple computers to the specific domain controllers, as apposed to "" is this going to make the windows machines not function properly?

I know it is a lot of information. Thank you in advance!
Who is Participating?

Improve company productivity with a Business Account.Sign Up

bbayachekConnect With a Mentor Author Commented:
Thank you for your response.

I was not sure until yesterday why the old DCs were still being used. It turns out we have a ton of computers already deployed that use the old DC for the time server and the new DCs have a slightly different name. I think there is a way to change the time server through GP tho?

Anyway, the DCs resolve fine, new/old, no problem. When I run netstat on the good computers I see them connected to anyone of the DCs (new/old), and we have our new DCs replicating to our old DCs as well. Only difference between the new and old DCs is WS2k3 instead of WS2k8.

I removed the extra pointers we had in our Lookup zones. Definitely did not fix the problem.

I saw that our xServe server was listed first in the directory utility instead of our AD server. I tried switching the order, in hopes that it would search AD first and maybe that is why it was failing. Turns out this didn't effect it. If it try to log in from an AD account or OD account in either order it will log in on a computer that is working properly. If the computer is not working properly, despite the search priority order, it will onlly authenticate OD users. I only used an OD user for testing purposes, none of our actual users authenticate their account to OD.

Which brings me to my newest finding, and what i now believe to be the probable cause:

All of out computers are managed by DeepFreeze. This makes prevents all computers from being modified, in ANY way (files, settings, etc. essentially "reimaging" them) by forcing them to revert back to its "frozen" state on every restart.

This is causing a problem because the apple computers by default have their AD computer account password set to expire every 14 days. Because these computers retain this image on every reboot this is causing an old password to be used, eventually, in order to authenticate the computer to the domain. This is because this password is stored locally in the ActiveDirectory.plist file in an encrypted form. Therefore always reverting back to the expired password. The way to fix this is to tell OS X Directory utility to never let that passsword expire. This is done with the terminal command:

dsconfigad -passinterval 0

Open in new window

This needs to be done with the computers "thawed" then they can get refrozen.

I can't say for sure if this is the fix for these computers because I just came up with this solution this morning. BUT it definitely IS an issue of some kind. I will be pushing out this fix this afternoon as soon as the classrooms clear out. Only time will tell if this fixes the issue.

I will post back and let you know how that goes.

Thanks again!
It is a normal issue with some computer so do not worry about it.
Here are a couple of things to check/be aware of when binding os x to ad.
Login as local admin, open network utility and see if your ad servers resolve. If not, then the problem lies within dns somewhere. If they resolve ok, then we can look elsewhere.
If have bound to both 2003 server and 2008 and on both there seems to be a delay of 25-30 seconds after the login screen appears before logins will succeed. I can live with that. I set computer accounts to show directory status on the login screens and instruct users to wait for the "green light"
The time needs to be synced with the ad server for both the clients and the OD server. A difference in several seconds can mean login failure.
Make sure your od server is bound to the ad server and kerberos is not running on the od server.
Are your clients bound to the od server also - if not, they should be with the ad server listed first in the Directory Utility Search Policy.
I have also had similar problems when the client has multiple dns servers listed where one is an external source and one internal. Point the clients to internal dns only with forwaders set on the internal dns server.
I only have one dc so I am not sure how multiple would work, but I bind to the dc specifically and not just the domain. With one lab, I would think binding to one server would be enough.
If you are no longer using the old controllers, then yes i would remove them.
I am just throwing out some things I have run across to think about and check while trying not to assume anything on your end.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Please do post back. I am interested to see if this is the solution. I don't use DeepFreeze so I can't offer any perspective, although it seems very possible this could affect logins.
bbayachekAuthor Commented:

We have 2 labs that use the iMacs (identical setups) the one lab had all computers frozen and most were affected. The other lab, for whatever reason, only had 2 computers frozen, the rest were not frozen. It seems as tho the only 2 computers that were having issues were the 2 frozen computers, but cannot be 100% confirmed.

I will definitely let you know how it goes. I am planning on testing this by setting a few computers to time out in 1, 2, and 3 days, then the rest 0 (never expire) to hopefully prove my theory.
We had similar issues - we started using Centrify and life is much easier now :)
bbayachekAuthor Commented:
Just FYI, it was definitely the issue with DeepFreeze reverting back to a stale computer account password. Setting the Pass interval to never expire worked like a charm.

Also just a little side note, spoke to apple reps in the store, they use deep freeze on their machines as well so apparently it is the "right thing" to use haha. Thanks for all the help

Shefam, that looks very interesting. I am going to look into that, thank you.
bbayachekAuthor Commented:
This was the correct solution. Computers could not authenticate to AD due to computer account password expiring. The computer account password was being reverted to stale password due to special software on the computer. Having the apple computers never expire their password worked like a charm.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.