Probably one of the most difficult situations administrators face is not being able to log on locally to a system. After administrators use the local Administrator account to load a machine and join a domain, they typically never use the local Administrator account again because they use domain accounts for daily administration tasks. Over the years, I've often beaten the drum about the importance of maintaining an accurate, verified list of Administrator account names and passwords. This information can save the day in a variety of situations. However, if you don't have that information, you need to know about the tools you can use—and you need to know how to protect yourself from those same tools should they fall into the wrong hands. Here are some FAQs that represent actual situations I've encountered.
Just the FAQs
I use domain accounts to administer my servers, so why do I need the local Administrator account name and password?
You need this information because things go wrong. For example, suppose a server's NIC goes bad (yes, it happens) and your credentials aren't cached on the server. In this situation, you need the local Administrator account name and password to log on. Or let's say someone unintentionally removes the Domain Admins group from the Administrators group on your servers. You need the local Administrator account name and password to log on locally so that you can add the group back in.
If I need a break-in utility, which one would you recommend?
A number of utilities are available, including some free utilities (see the sidebar, "Free Break-In Tools"). However, I've found that Winternals Software's ERD Commander 2005 (http://www.winternals.com) is the best. Using this tool's intuitive interface, you can modify Administrator passwords, copy files over a network, view event logs, boot dead systems, and perform other important tasks. The cost of $299 for the server tool might sound a bit high, but you'll be glad you have it when you need it. You can easily spend many man-hours working through a problem if you don't have this tool.
I sat down at the console on one of my servers to log on, but the domain entry field was missing from the logon box. What's going on?
I have seen this happen before, but I'm not sure why the problem occurs. Typically, you just need to reboot the machine to solve the problem. However, depending on how you've set up your server, you might need administrative rights to access the shutdown or restart option, in which case you need an accurate Administrator account name and password to log on.
Another administrator told me that I could break into a server by installing a parallel installation of the server OS and changing the screensaver file around with the User Manager for Domains file. Does this really work?
Before break-in tools were available, I used this break-in technique successfully on Windows NT 3.51 and Windows NT Server 4.0 machines. When you perform the technique correctly, the server screensaver kicks in but instead of seeing the screensaver, User Manager for Domains appears and lets you change the Administrator account password. Unfortunately or fortunately (depending on your viewpoint), this potential security loophole was closed in Windows 2000 Server and later.
A number of users have turned in their laptops to me to fix because the laptops were no longer in the domain. When I asked them what happened, they replied that the domain just disappeared. Do you know what might be happening?
Most likely, the problem is that the users, who are local administrators on their laptops, removed their machines from the domain to resolve connectivity problems (e.g., printing, file sharing) on their home networks. When the users plugged back into the corporate network, they discovered they didn't have the rights to rejoin the domain. If the users don't know the Administrator account password (and they likely won't), you'll need to use a break-in tool to regain control of the laptop and fix the domain problem.
All this talk about break-in tools makes me a bit nervous because of the security implications. How can I secure my servers against an internal unauthorized user who has one of these tools?
The most important security measure you can take is to physically secure your servers. If a savvy data thief can sit down at a server console for a few minutes, you're in trouble. Restricting physical access and documenting those people who have physical access are important steps to decreasing this risk. Another security measure you can take is to disable removable media drives (e.g., floppy disk drive, CD-ROM drive) in the BIOS or physically disconnect these drives because most break-in tools use them. However, be aware that disabling or disconnecting these drives might limit or delay your own authorized recovery efforts.
In addition to physically securing your servers, I recommend that you monitor your servers with a ping script or GUI ping utility. Most break-in tools require a reboot. If data thieves want to cover their tracks, they'll reboot the server a second time to bring back the logon prompt. If the script or utility captures two ping interruptions within a short period of time, you might have a security violation. To see a sample script that pings servers, see the
Windows Scripting Solutions
article "Real-World Scripting: Creating the New ServerTesterV2.pl," May 2000, InstantDoc ID 8602.
I also recommend that you regularly check to see whether your Administrator account passwords have been changed outside the typical change cycle. An unscheduled password change can signal that a break-in has occurred. You can use a script to verify your servers' passwords and report any suspect passwords. For information about such a script, see the
Windows IT Pro
article "Programmatically Protect Your Passwords," April 2004, InstantDoc ID 43591.
Besides monitoring password changes, you should monitor the membership of your server administrative groups, such as Administrators or Domain Admins. Look for unfamiliar local or domain accounts. Based on its name, an account might appear to be a service account but in reality is an account being used for unauthorized access. One way to monitor group membership is to use a script. For an example of this type of script, see the
Windows Scripting Solutions
article "Enumerating Group Membership," November 2003, InstantDoc ID 40230.
You also might want to monitor logged-on users. If all your administrators use their own IDs to log on and perform administrative activities, you should never see the Administrator account being used. Just sitting down at the console and seeing that the last logged-on user was the Administrator account might be an indication that someone has used this account to perform unauthorized activities.
Maintaining a verified list of Administrator account names and passwords is the best way to avoid not being able to log on locally to a system when things go awry. When you run into a situation in which you need to log on to a machine locally but you don't have the correct logon information, you can use break-in tools. Although useful in such situations, break-in tools also pose security risks. Thus, you need to protect your system by physically securing and monitoring your servers.