Case of the Domain Join Failure

An IT support person had a machine that had some issues with domain access, so had tried removing and re-joining machine to the domain. maually However on joining the domain Windows threw the following error:

The join operation was not successful. This could be because an existing computer account having name “<computer name” was previously created using a different set of credentials. Use a different computer name, or contact your administrator to remove any stale conflicting account. The error was:

Access is denied.

The process for joining the machine to domain was this:

1. Deleted computer account in Active Directory Users & Computers

2. Created the computer account in desired OU

3. Specified same user account as credentials when joining to domain via

System Properties

There was no obvious reason for the access denied, the account used had full control of computer objects in the relevant OU, both to read/write all properties and create/delete child objects.

So I went to use Windows 7 in-built network monitoring (Previously discussed here https://chentiangemalc.wordpress.com/2012/02/22/netsh-traceuse-it/)

I ran an elevated command prompt and ran command

netsh trace start capture=YES report=YES

I then reproduced issue, and finished with command

netsh trace stop

I then took the .ETL & CAB file generated onto my machine for analysis. To analyse the ETL file you’ll need Microsoft Network Monitor

http://www.microsoft.com/en-au/download/details.aspx?id=4865

and the latest version of Microsoft Network Monitor Parsers here

http://nmparsers.codeplex.com/

With all that installed we’re ready to open the .ETL file in Microsoft Network Monitor. Once opened you’ll need to ensure you set Tools | Options then Parser Profiles and select Windows. This will translate the ETL into friendly terminology, and make parsing the network trace much easier.

Now because this is a domain join we want to set a filter traffic to protocol SAMR. This refers to the Security Account Manager (SAM) Remote Protocol and you can read all the juicy details about it here in the protocol spec http://msdn.microsoft.com/en-us/library/cc245476(v=prot.10)

To filter we just type SAMR in the filter and click Apply

I then look for the SAMR: SamrCreateUser2InDomain Request field and expand the Frame Details. This allows me to see the specific request sent to the domain controller. What I found was the computer name being sent to the domain controller did not much the computer name as displayed in System Properties. In addition it didn’t match the computer name shown in “Source”

So where was this computer name coming from? It didn’t match the name in System Properties, from hostname command, or the Source in network monitor.

So this time I turned to ProcMon (http://live.sysinternals.com/ProcMon.exe ) and set a filter to include all items where Details contains MININT-40N8D and repeated the domain join process. Voila! We find the culprits

• HKLM\System\CurrentControlSet\Control\ComputerName\ComputerName
• HKLM\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\ComputerName

These registry values had the MININT- name:

Not a match!

Setting back both reg keys to match what was displayed by hostname command and then immediately domain join worked.

The interesting lesson here … if the reg keys mentioned above is the true source used for the domain join command. The computer name displayed in system properties, along with the computer name shown in the domain join error message may not be the computer name actually being used.

Thank for netsh + network monitor + ProcMon and it’s easy fix.