Last Updated on November 27, 2010 by Dave Farquhar
So maybe you’re like me and you’re administering a system that fell off its Windows domain, and the system was built by your predecessor’s predecessor, the local administrator account was renamed, and nobody has any clue what the account name or password is.
And you try ERD Commander because it worked in the past, but not this time…Usually the Locksmith works. But in this case, it didn’t, and of course everyone wanted the server back online an hour ago. We tried everything else we could think of for about three days, including downloading some things that I was sure would get me a visit from a security officer. Nothing worked. At least when I got the visit from the security officer, he just wanted to know why there were repeated attempts to log in with certain accounts.
“I was trying to hack into my own server and it seems I’m not a very good hacker,” I said. Duh.
So I found myself standing at the server with another sysadmin, having used my last idea. “I don’t suppose you have any ideas?” I asked. “I figured if you did, you would have said so by now, but…”
He shook his head.
Finally, I had one last idea. I asked him what he set the password to when he used ERD Commander.
“Password,” he said. “To make it easy to remember.”
Aha! A light went off. This system was hardened to require stronger passwords than just an 8-character alphabetic password. I had a hunch that was what was keeping us from being able to log in using our hacked account.
So we booted off the ERD Commander CD yet again, connected to the Windows installation, located what we were pretty sure was the renamed local adminstrator account, and I reset it to the standard mixed-case special character password we use for the local admin accounts.
We held our breath, rebooted, and tried to log in.
Success. Finally.
So if ERD Commander isn’t working for you, try using a stronger password to satisfy your local system policy.
And just in case you’re wondering why a computer falls off a domain, computers have usernames and passwords just like users do. Occasionally the passwords get reset. If for some reason the domain controller thinks a member computer’s password is one thing, and the member computer thinks it’s something else, you end up with a computer that says it’s on the domain, but can’t authenticate against it. The solution is to log in with a local administrator account, then either run NTDOM.EXE from the Windows Support Tools, or remove the computer from the domain and add it back in. You can just put the computer in a workgroup, ignore the dialog box that says you have to reboot, then add it to the domain, and then reboot.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.