I'm working on an FAQ for passwords right now. Look for it in the Security Newsletter next month (http://www.microsoft.com/technet/security/secnews/newsletter.htm). However, one thing that has come up more than a few times in the recent past is what to do with the built-in Administrator account. I'm not sure that it fits in the framework of passwords per se, but it may actually merit a blog post, so here are some do's and don'ts. Keep in mind, I am specifically referring only to BUILTIN\Administrator, also known as NT AUTHORITY\Administrator; the account with relative identifier 500.

Do's

• Disable it. The built-in Administrator is basically a setup and disaster recovery account. We use it during setup and to join the machine to the domain. After we are done with that we should never use it again and it can be disabled. It should never be used during normal operations. For that, each person who administers the system needs his or her own administrative account in addition to the ordinary user account they use to read e-mail, surf the web, play Age Of Empires III, etc. 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, try this: close your eyes and lean back. Now, imagine standing up in a packed court room. You are under cross-investigation by the defense attorney as a hostile witness. The question being asked is how sure you were that it was the defendant who shipped all the company secrets off to your competitor. Your best answer is "well, one of these ten people because it appears that the person logged on as 'Administrator' when he did it." OK. Open your eyes again, and open them real wide this time. Wide enough so that you can see through ease of use to see the CYA benefits of not using the built-in Administrator account.
• Set a unique password. If the account is disabled, what does it matter what the password is? Well, here is the problem, what if it is not disabled on all systems? Now, be honest with yourself. 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 gets compromised the bad guy can dump out the password hashes and he now has all that he needs to authenticate to all the other systems using the Administrator account (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. How do you do that? There are a couple of options. You can use a tool like User Manager Pro (http://www.liebsoft.com/index.cfm/products/ump), which I am told does this. (I have not used it myself. If you have, please let me know how it works.) You can also use a command line tool that can set the password. Should you wish to actually ever 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 Protect Your Windows Network (http://www.awprofessional.com/title/0321336437). Passgen is designed to set a pseudo-random password on regular accounts and service accounts, across the network. The password can either be 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 protected by the secret. Hence, it is much easier to protect than the administrator password on thousands of machines.
• Set a very long password, or none at all. Obviously a really long password is a good idea, but a blank one may be even better. In an environment where you can guarantee physical security, and you do not need to use the account across the network, leave the administrator account password blank. That way it can not be used across the network, and nobody needs to know what it is. 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.

Don'ts

• Use it. Seriously. You should never use 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. If you need to get data off of it first stick the hard drive in another system and get it off that way, or use that carefully tought out disaster recovery plan that's gathering dust on someone's shelf!
• Share it. As I mentioned above, sharing the built-in Administrator account is a really bad idea. You may think you never need to be worried about accountability, to which I have one thing to say: neither did any of the colleagues who ended up in court being unable to explain why they had failed to provide accountability for user action.