Troubleshooting Domain Join Issues

Have you ever had one of those situations where you could not get a workstation or server to join the domain?  I had this happen recently and wanted to detail a few of the steps I used to troubleshoot and resolve the issue.  Let’s take a look in general at troubleshooting domain join issues.

Troubleshooting Domain Join Issues

The particular error that I received when troubleshooting domain join Issues was the following:  “No mapping between account names and security IDs was done”.  A really good breakdown of the various errors that you can get when joining a domain are found here.

The issue I was having was in a lab environment.  I had another copy of the domain controllers inside the lab.  So, machines that I copied over to the lab environment have to be “rejoined” to the domain due to computer passwords changing between the domain iterations.

The specific error that I received when joining a particular server to the lab domain environment was:

No mapping between account names and security IDs was done.

The weird thing was that I had just joined other servers to this same domain, same subnet, etc.  Just a brief aside here on the lab setup – I have a VM serving as a router that simulates various subnets for branch offices.

Troubleshooting Steps Taken

The following shortlist is one I used as a sanity check:

• DNS
• netsetup.log
• Subnets/network connectivity

DNS

Anytime you have an issue joining a domain, one of the first things to check is DNS.  DNS is the heart of Active Directory and making things work correctly and this includes domain joins.

Make sure of the following:

• DNS server addresses are correct
• DNS suffix search order is correct if multiple DNS domains are in play
• There are no stale or duplicate DNS records referencing the same computer account
• Make sure reverse DNS doesn’t point to a different name as the A record

After going through this short list of checks, I didn’t find anything that was keeping resolution from working properly.  I could ping the domain name, ping DCs, ping DNS servers, etc.  Also, there were no weird DNS record conflicts for the server in particular.

Netsetup.log

The Netsetup.log is a valuable resource when you are trying to figure out what is going on with a domain join issue.  The netsetup.log file is located here:

C:WindowsDebugnetsetup.log

A typical netsetup.log entry for domain join operation when it already sees the computer account as existing:

07/29/2015 05:40:56:658 NetpChangeMachineName: from 'WIN10TEST' to 'WIN10TEST' using 'test.localadministrator' [0x1000]
07/29/2015 05:40:56:658 NetpChangeMachineName: using DnsHostnameToComputerNameEx
07/29/2015 05:40:56:658 NetpChangeMachineName: generated netbios name: 'WIN10TEST'
07/29/2015 05:40:56:658 NetpDsGetDcName: trying to find DC in domain 'test.local', flags: 0x1010
07/29/2015 05:40:57:878 NetpDsGetDcName: found DC '\dc01.test.local' in the specified domain
07/29/2015 05:40:57:878 NetpGetDnsHostName: Read NV Domain: test.local
07/29/2015 05:40:58:049 NetpGetComputerObjectDn: Cracking DNS domain name test.local/ into Netbios on \dc01.test.local
07/29/2015 05:40:58:049 NetpGetComputerObjectDn: Crack results:     name = TEST
07/29/2015 05:40:58:049 NetpGetComputerObjectDn: Cracking account name TESTWIN10TEST$ on \dc01.test.local
07/29/2015 05:40:58:049 NetpGetComputerObjectDn: Crack results:     (Account already exists) DN = CN=WIN10TEST,CN=Computers,DC=TEST,DC=com
07/29/2015 05:40:58:049 NetpModifyComputerObjectInDs: Initial attribute values:
07/29/2015 05:40:58:049         DnsHostName  =  WIN10TEST.test.local
07/29/2015 05:40:58:049         ServicePrincipalName  =  HOST/WIN10TEST.test.local  RestrictedKrbHost/WIN10TEST.test.local  HOST/WIN10TEST  RestrictedKrbHost/WIN10TEST
07/29/2015 05:40:58:049 NetpModifyComputerObjectInDs: Computer Object already exists in OU:
07/29/2015 05:40:58:049         DnsHostName  =  WIN10TEST.test.local
07/29/2015 05:40:58:049         ServicePrincipalName  =  RestrictedKrbHost/WIN10TEST  HOST/WIN10TEST  RestrictedKrbHost/WIN10TEST.test.local  HOST/WIN10TEST.test.local
07/29/2015 05:40:58:049 NetpModifyComputerObjectInDs: There are _NO_ modifications to do
07/29/2015 05:40:58:049 ldap_unbind status: 0x0
07/29/2015 05:40:58:049 NetpChangeMachineName: status of setting DnsHostName and SPN: 0x0
07/29/2015 05:40:58:064 NetpChangeMachineName: SetComputerNameEx() returned 0x1

There is a wealth of information that can be gathered from the netsetup.log file.  In great detail it will show all the steps completed and tried with the domain join operation.

Again in my case, I didn’t see any concrete errors in the logs that really pointed to an issue with DNS, or DCs in particular.

Subnets/network connectivity

The last thing that I had on my list to check yielded the most fruit in this case – network connectivity.  While I could ping and map drives between boxes, for whatever reason (maybe an issue with traffic flowing between my simulated interfaces, the issue turned out to be network related.

After changing the IP on the problematic server to another subnet range, the domain join operation completed without error.  After I joined the domain on the main subnet, I changed the IP back to the subnet in question which looks to still be working with domain connectivity.  I am going to dig into this a bit deeper and see if I can figure out exactly what is going on.

A good place to start for any who may wonder which ports are needed is found here:  https://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx

Final Thoughts

There is no doubt about it, Troubleshooting Domain Join Issues can be frustrating and challenging in certain cases where the issue is not obvious.  However, using a quick shortlist of items and troubleshooting – DNS, netsetup.log, and network troubleshooting are the best places to start.