This has been a fun problem that I've seen come up on and off for quite a while. After encountering it once again today. I thought I would share the fix.
So first, the errors. When attempting to log into the domain with a domain account you will recieve a message similiar to the following:
"Windows cannot determine the user or computer name. (The specified domain either does not exist or could not be contacted) Group Policy processing aborted."
This will be your first indication that something is wrong and you'll need to log into the system with a local administrator account. Once you're logged in you should probably first check your Windows error logs. These logs may give further clues as to what has gone wrong. In my case, I was seeing messages like this:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1053
Time: 7:01:21 AM
User: NT AUTHORITY\SYSTEM
Windows cannot determine the user or computer name. (The specified domain either does not exist or could not be contacted. ). Group Policy processing aborted.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Great… Definitely not good news all around. It sounds like it's lost the computer account by this error message. However, don't jump the gun on this, remember, it said that it can't talk to the domain so if you attempt to unjoin and rejoin the domain you're liable to end up with a whole new problem on your hands.
In the situation that I am dealing with my problem was the system has 2 network controllers. Why is this a problem? Because, each NIC connects to a different segment of the network which doesn't necessarily talk between one another. However, before we get to the solution there are a few critical troubleshooting steps you should take to validate the problem further. Remember, you're dealing with Windows and Active Directory, sometimes your symptoms will be similiar but this solution will not work for you. So at this point here's a few preliminary things you'll want to do:
- Reboot the system. While this is not essential, it's typically a good first step just in case something has gone funky.
- Validate that the domain controller/domain is available.
- Validate that the time on both your system and the domain controller is the same (2 minutes off might be a problem).
- Validate that you indeed can log into the domain controller, just in case this is a bigger problem.
- Ping your domain controllers/DNS servers, if you can't ping them (unless firewalled) then you probably can't talk to them.
Now, since you've completed all of these steps (or ignored me and skipped them at your own risk… well this whole post is at your own risk but still), we can dive into things a bit deeper.
In my troubleshooting, to validate my hypothesis, I disabled the network adapter that was not associated with my Active Directory network. Logged out of the system and then logged into the domain. This worked great! This means that the domain is available and that my system is talking to it. It is some other reason that it can't authenticate to it.
Each of the network cards on the system has it's own IP/DNS/Gateway and the like. That's perfectly fine and acceptable. What both of them have by default as well is Client for Microsoft Networks and Windows File and Printer Sharing. While this might not seem like a problem at first, this is where the problem originates.
Several servers have been running with this setup without issue for months, if not years. However, once in a while, either Windows reprioritizes the NICs or something else happens which causes it to start using the alternate network card for authentication. As a result, the server fails to authenticate users to Active Directory because it cannot communicate with the domain via the alternate controller.
So now, to fix this mess of a problem. Since everyone's setups may vary you should definitely think about this solution and what else it may impact before you make these changes.
- Go to Start -> Control Pannel (switch to classice view if you haven't) -> Network Connections.
- Right-click on the Network Connection that DOES NOT handle your authentication and choose Properties.
- Now, uncheck both Client for Microsoft Networking and File and Printer Sharing for Microsoft Networks.
- Click OK and close out your folders and logoff.
At this point, you should be able to choose your domain and successfully authenticate to it.
There is a possible alternate solution to this which I have not validated. If you only need DNS server entries on 'one' side of your dual homed NICs, you may be able to remove the DNS entries from the alternate NIC and achieve the same goal without disabling this functionality.
Hopefully this will help a few people from getting bogged down in this type of authentication mess!