bbayachek
asked on
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 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!
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!
hassanwarraich
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
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 :)
http://www.centrify.com/solutions/overview.asp
http://www.centrify.com/solutions/overview.asp
ASKER
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.
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.
ASKER
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.