Active Directory is not trusting
August 18, 2008 9:58 AM Subscribe
I'm working with an Active Directory domain that has had a rash of PCs losing trust with the domain. Whenever users log on to the domain and try to access shares on the server, they are denied access. I've found a way to fix this, but would like to know the root problem.
Everything was running normally until this happened, nothing was really a catalyst for this to occur. It happened once on Friday and twice today. The users called and said that whenever they tried to access network apps or files on the server, they were given access denied errors (don't have the exact error with me, but I searched it and didn't come up with anything related to this issue). I attempted logging in as the domain Admin on the computer and it gives the exact same errors, so I know that it is the workstation having problems, not the server or account. I also tried system restore on the PC and it did not help (as usual). I have come across this before and I had to perform the following steps:
Take PC off domain, join to workgroup, restart
Rename PC (appended a 1 after the current name), restart
Delete old PC name out of Active Directory
Join PC to domain again, restart.
Upon restarting, we are able to choose the domain, log in with the user and it uses the same profile they had used before taking off the domain. The only difference is that they now have file server access. What could be causing this issue? Should I be looking for indications in the PC or server event log? Is there a way to prevent this from happening on the other PCs in the network?
Everything was running normally until this happened, nothing was really a catalyst for this to occur. It happened once on Friday and twice today. The users called and said that whenever they tried to access network apps or files on the server, they were given access denied errors (don't have the exact error with me, but I searched it and didn't come up with anything related to this issue). I attempted logging in as the domain Admin on the computer and it gives the exact same errors, so I know that it is the workstation having problems, not the server or account. I also tried system restore on the PC and it did not help (as usual). I have come across this before and I had to perform the following steps:
Take PC off domain, join to workgroup, restart
Rename PC (appended a 1 after the current name), restart
Delete old PC name out of Active Directory
Join PC to domain again, restart.
Upon restarting, we are able to choose the domain, log in with the user and it uses the same profile they had used before taking off the domain. The only difference is that they now have file server access. What could be causing this issue? Should I be looking for indications in the PC or server event log? Is there a way to prevent this from happening on the other PCs in the network?
Bad timekeeping on the client, or if it's widespread, the AD controller? Losing clock sync between the controller and the client causes merry havok with authentication.
posted by ArkhanJG at 10:24 AM on August 18, 2008
posted by ArkhanJG at 10:24 AM on August 18, 2008
Agree with the time issue. (Also check for various viruses and updates that might have changed something.)
Had an issue way back when, when someone did something to a timeserver on a Novell network and the master clock was a year off. In the future. Not so bad- people dutifully changed their "expired" passwords and continued rocking. Until someone corrected the problem and now everyone had weird password expiration problems- something to do with a negative number password expiration date. Good times.
posted by gjc at 3:26 PM on August 18, 2008
Had an issue way back when, when someone did something to a timeserver on a Novell network and the master clock was a year off. In the future. Not so bad- people dutifully changed their "expired" passwords and continued rocking. Until someone corrected the problem and now everyone had weird password expiration problems- something to do with a negative number password expiration date. Good times.
posted by gjc at 3:26 PM on August 18, 2008
Response by poster: Another machine is doing this again this morning. Checked time/date on both the server and the workstation and they're both correct and current. Is there possibly a service on the server that I should be investigating?
posted by ijoyner at 5:46 AM on August 19, 2008
posted by ijoyner at 5:46 AM on August 19, 2008
This thread is closed to new comments.
posted by TravellingDen at 10:21 AM on August 18, 2008