Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Some computers loosing AD binding

Posted on 2011-09-17
Medium Priority
Last Modified: 2012-05-12
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 company.org" and "ourcompany.org", when checking the hosts, points to "dc1New.ourcompany.org" dc2New.ourcompany.org" "dc1Old.ourcompany.org" dc2Old.ourcompany.org" and something like "nodeXXXXX.accessdc.com" (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 "dc1New.ourcompany.org" AND "dc2New.Ourcompany.org". When binding  to just "our company.org" 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 company.org" and tried to bind to "dc1new.ourcompany.org", this failed, it could not resolve the host name, then I tried doing the same for "dc2new.ourcompany.org", 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 "ourcompany.org"?

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 "ourcompany.org" 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 "ourcompany.org" is this going to make the windows machines not function properly?

I know it is a lot of information. Thank you in advance!
Question by:bbayachek
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 36555905
It is a normal issue with some computer so do not worry about it.
LVL 10

Expert Comment

ID: 36903679
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.

Accepted Solution

bbayachek earned 0 total points
ID: 36911422
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!
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

LVL 10

Expert Comment

ID: 36911532
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.

Author Comment

ID: 36912327

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.

Expert Comment

ID: 37074038
We had similar issues - we started using Centrify and life is much easier now :)


Author Comment

ID: 37133765
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.

Author Closing Comment

ID: 37163675
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.

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Wouldn't it be nice if objects in Active Directory automatically moved into the correct Organizational Units? This is what AutoAD aims to do and as a plus, it automatically creates Sites, Subnets, and Organizational Units.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

604 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question