Security Watch-Why You Should Disable the Administrator Account

Jesper Johansson

I’ve fielded a lot of questions  recently about how to manage the built-in administrator account. I am referring specifically to BUILTIN\Administrator, also known as NT AUTHORITY\Administrator, the account with relative identifier (RID) 500. This account exists by default on all Microsoft^®Windows (Windows NT^®-based) systems as well as Active Directory^®domains.

Many organizations have standard build scripts that set a particular password for this account. All systems in the environment, therefore, commonly have the same Administrator password. This leads to significant problems should one of those systems get compromised, as the attacker would have access to the password hash. Using that hash, the attacker could then authenticate to any of the other systems that use the same password. Plus, if the password used on the built-in Administrator account on the domain is the same as the one used on all the domain members, the problem can get truly disastrous.

Back when I did attack and penetration testing for a living I actually used this type of configuration management problem to attack networks several times. Based on that experience, I put together a list of my best practices for managing the built-in Administrator account. They may or may not work in your environment, but if they force you to think differently about how you manage the built-in Administrator account, I’ve done my job.

1 Disable It  The built-in Administrator is basically a setup and disaster recovery account. You should use it during setup and to join the machine to the domain. After that you should never use it again, so disable it. Should you need to use the recovery console or boot into safe mode, the account will be magically re-enabled for use only in those troubleshooting tools. Once you boot the system again normally, it is disabled.

The built-in Administrator account should never be used during normal operations. Therefore, each person who administers the system needs their own administrative account in addition to the ordinary user account they should be using to read e-mail, surf the Web, play Age Of Empires III, and so on. Yes, I am aware that the Microsoft Baseline Security Analyzer (MBSA) warns you if you have multiple administrators on a system. But as long as you know about all of them and you meant to give them administrative privileges, you can safely ignore this advice.

If you allow people to use the built-in Administrator account you lose all ability to audit what anyone is doing. There is no accountability. Not too worried about that? Well, imagine you’re in court and you have to prove who got access to all the company secrets, and the best answer you have is that it was somebody who was logged on as Administrator.

2Set a Unique Password  If the account is disabled, what does it matter what the password is? Well, it matters if the account is not disabled on every system. How many unique passwords are used on the built-in administrator accounts across all systems in your environment? If the answer is less than the number of systems in your environment, you have a problem. If only one of those systems is compromised, the bad guy can dump out the password hashes and he’ll then have all he needs to authenticate to all the other systems. (Note that it does not matter how strong the password is here; if the bad guy has hashes, password strength is irrelevant.)

To avoid this you need to ensure that every system has a unique local Administrator password. Should you ever want to actually use the account, you need to be able to recover the password. That means either writing it down or using a tool that can recover it for you. One such tool is passgen, which comes with the book by Steve Riley and myself, Protect Your Windows Network: From Perimeter To Data (Addison Wesley Professional, 2005). Passgen is designed to set a pseudo-random password on regular accounts and service accounts across the network. The password can be either fully random or based on two pieces of known input: a unique identifier for the system or account and a common pass phrase. The common pass phrase is the global secret, but it is not stored on any of the systems that are protected by the secret. For this reason, the common pass phrase is much easier to protect on thousands of machines than the administrator password.

3 Set a Very Long Password, or None at All  Obviously a really long password is a good idea, but in certain situations, a blank one may be even better. In an environment where you can guarantee physical security, you do not need to use the account across the network, and you are using Windows XP or Windows Server™ 2003, a blank password is better than a weak password. By default, blank passwords can only be used locally in Windows XP and Windows Server 2003. If the account password is blank, the account is not valid as a network credential. Of course, if you have more than one administrator, it leaves you open to abuse and accountability issues, so you need to carefully consider this approach. If you need to be concerned with those problems, set a very long password—127 characters or so. That way the account is as good as disabled.

4 Don’t Use It  Seriously. You should never log on with the built-in administrator account. Use your own administrative account instead. If things get so bad that you need the built-in administrator account, flatten the system and rebuild it. It’s generally quicker and less painful than ensuring nothing was compromised. If you need to get data off of it first, stick the hard drive in another system and get it that way, or use that carefully thought-out disaster recovery plan you have in place.

5 Don’t Share It  As I mentioned, sharing the built-in Administrator account is a really bad idea. You may think you never need to be worried about accountability, but then neither did any of those aforementioned people who ended up in court unable to explain why they had failed to provide accountability for user action.

6 Don’t Rename It  You will find many resources that recommend renaming the account and then creating a honey-pot account called Administrator to lure attackers. No attacker worth his salt will be fooled by those tactics. The RID for the account is always 500. There are abundant tools that can find the real account. Besides, don’t you have enough to do securing your network without building things that people should be breaking into? Your time will be better spent on network security.

True, there are worms that go after the account named Administrator, but if you have followed the advice here, they will not be a threat. Some people argue that renaming the account has intrusion detection value in that if you see people go after the real Administrator account in your intrusion detection logs you know you are after an attacker who knows something. However, it is just as likely that you are after an attacker who merely knows how to download and run automated attack tools off the Internet.

This list needs to be considered in every environment. For instance, if you run Microsoft Small Business Server (SBS), you need the built-in Administrator account. That account is used by the OS after installation. SBS 2003 Service Pack 1 also will only apply properly if you run it as the built-in Administrator.