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
Solved

Some computers loosing AD binding

Posted on 2011-09-17
10
2,407 Views
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!
0
Comment
Question by:bbayachek
10 Comments
 
LVL 4

Expert Comment

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

Expert Comment

by:EdTechy
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.
0
 
LVL 1

Accepted Solution

by:
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!
0
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

 
LVL 10

Expert Comment

by:EdTechy
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.
0
 
LVL 1

Author Comment

by:bbayachek
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.
0
 
LVL 4

Expert Comment

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

http://www.centrify.com/solutions/overview.asp
0
 
LVL 1

Author Comment

by:bbayachek
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.
0
 
LVL 1

Author Closing Comment

by:bbayachek
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.
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

David Varnum recently wrote up his impressions of PRTG, based on a presentation by my colleague Christian at Tech Field Day at VMworld in Barcelona. Thanks David, for your detailed and honest evaluation!
In this article, I am going to show you how to simulate a multi-site Lab environment on a single Hyper-V host. I use this method successfully in my own lab to simulate three fully routed global AD Sites on a Windows 10 Hyper-V host.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
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 …

840 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