Fixing a Windows PC that fell off the domain with netdom resetpwd

Recently I had a problem with a Windows 7 desktop serving as my HTPC.  It stopped automatically connecting to my PEAP-secured Wi-Fi network at boot time, and would only connect if someone with Wi-Fi permissions logged on to it.  The reason turned out to be that the desktop “fell” off the domain, so the machine account couldn’t be authenticated to connect to the network.  Instead of the quick fix of removing the machine from the domain and rejoining it, I decided take the time to perform a deeper analysis, and to try a more elegant approach to resolving the issue.If you’ve worked with large numbers of Windows desktops, especially in a help desk or desktop support role, you’ve probably seen Windows desktops fall off the domain.  When I was working in desktop support, it was fairly common occurrence, though I didn’t see it much after moving to systems administrator positions. The typical symptom a desktop exhibits when having this issue is that domain users can’t log on.  To work around this, you might log on as a local administrator, remove the machine from the domain, and subsequently rejoin it.

Before I go further, let’s review some background about this problem.  Windows machines joined to an Active Directory domain have their own account in the domain, and just like normal user accounts, machine accounts have a password.  So a more correct description of the “falling off the domain” issue is “machine account password mismatch” according to the informative Windows machine account passwords and VM snapshots MSDN article.  This issue occurs when the password for the machine account stored on the machine itself does not match the one stored for the account in Active Directory by the domain controller.  Windows actually has a mechanism to help prevent this failure: it maintains the previous machine account password and will try to use it if the current one fails.  If both the current and previous passwords don’t work, the machine can’t authenticate itself.  This explains why you can’t you use a domain account to log on… the desktop fails to authenticate with a domain controller to check the credentials you input.  But there is a loophole: if the desktop cannot reach a domain controller to attempt authentication of your credentials, it will check against a local authentication cache.  This is needed for laptop users who might be away from and with no access to the corporate network for extended periods of time.

The above explains why my HTPC didn’t exhibit the typical symptoms of machine account password mismatch.  I was able to log on to the machine with a domain account because the machine only connected to the network via Wi-Fi, but it couldn’t connect to the Wi-Fi network using its machine account to verify the credentials with a domain controller.  Due to this, plus the fact that I haven’t seen the issue in a few years, I didn’t immediately determine the cause of the PEAP authentication problem.  I first opted to check the Security log in the Event Viewer for the Server 2008 machine with the Network Policy Server role which handles PEAP authentication over RADIUS.  Interestingly, there was no failure logged under the NPS category like a typical PEAP authentication failure, but there was one in the Logon category: event 4625.

The failure reason of “Unknown user name or bad password” for the machine account shed more light on the issue.  To look into it further I turned to the nltest command.  First was the /SC_RESET option, which forces the machine to attempt to re-authenticate a secure channel with the domain controller.

This failed with “ERROR_ACCESS_DENIED”, which confirms what the NPS server log indicated: the machine cannot authenticate with a domain controller.  So it is not surprising that attempting to manually change the machine account password with /SC_CHANGE_PWD also failed.

The previously mentioned MSDN article suggests fixing this with the “classic” solution using netdom remove followed by netdom join.  However, I decided to try another option: netdom resetpwd.  This is a single command and seems perfectly suited to resolve this issue.

That is what I like to see!  After a quick reboot, but before logging on, I confirmed that I could ping the machine, and I verified that the Security log on the NPS had event 6278 showing that the machine could successfully authenticate via PEAP to connect to my Wi-Fi network.

Hopefully I won’t see this probably again any time soon, but if I do, I will consider using netdom resetpwd.  The one downside to this is that netdom is not actually installed by default on Windows desktops.  You can copy the executable from another machine, or install the Remote Server Administration Tools.