Duplicate computer name prevents Active Directory domain logon

Posted on By Mark Wilson

I came across an interesting problem a few nights back… I locked myself out of a Windows XP computer. Here’s how it happened, along with how I got back in.

First, I built a new Windows Server and inadvertently used the same name as an existing Windows XP computer. Then I joined the server to an Active Directory domain (from this point on, the machine that was originally using the computer name is unable to authenticate with the domain as its password will have been overwritten when the duplicate machine joined the domain).

I then turned on the Windows XP computer. Because this machine is a notebook PC and wasn’t connected to the network at the time, I logged in using cached credentials; however after installing a wireless network card and restarting the computer, I was presented with a message that indicated I could not log on to the domain. Unfortunately I didn’t make a note of the exact message at the time, but looking back, I can see the NetLogon event 3210 in the system event log, the description for which which tells me exactly the problem:

This computer could not authenticate with \\domaincontroller.domainname.tld, a Windows domain controller for domain domainname, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Realising my mistake, I logged on using a local account and tried to rejoin the domain. Except that I couldn’t, because, as per Microsoft’s advice, I had disabled the local administrator account when I joined the domain and all I had available to me were standard user accounts.

Luckily Daniel Petri has published an article with a workaround for when a Windows computer cannot log on to a Windows Server 2003 domain due to errors connecting to the domain. By removing the network cable and restarting, I could log on as a domain administrator using cached credentials. Then, I enabled the local administrator account and changed the computer name before moving the computer out of the domain and into a workgroup. I then rebooted (with the network cable connected), logged in using the re-enabled administrator account and rejoined the domain (with the new computer name), before disabling the administrator account again.

Phew!

SSH addendum

Posted on By Mark Wilson

Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

  • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
  • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).