Securing the Administrator Account

Your computers and domains have a built-in Administrator account by default, and you've probably created numerous accounts with Administrator rights for your IT staff. Because of its inherent permissions and power, the built-in Administrator account is at once the most useful and the most dangerous account on your system. The danger, of course, is that an intruder could use the Administrator account to compromise your network. Intruders try to access and use the Administrator account because doing so is easier than guessing the names of other accounts that have permissions equal to the Administrator account.

You can take several steps to make the Administrator account more secure. At the same time, you can ensure that your accounts with administrative rights have the necessary permissions to perform tasks.

Administrator Account Basics
Every Windows Server 2003, Windows XP, and Windows 2000 computer on your network, except for the domain controllers (DCs), has a local account named Administrator. Every domain also has an Administrator account. To make sure you don't lock yourself out of your computers or your domain, Microsoft set some limits on the built-in Administrator account: You can't delete it, disable it, or lock it out (even if you apply an account lockout policy, that policy doesn't apply to the Administrator account).

In all its documentation for administering computers, Microsoft recommends you avoid logging on with the Administrator account. However, your security efforts should include more than merely avoiding the use of this account. The limits that Microsoft sets on manipulating the Administrator account reduce your ability to easily secure the account. Intruders, knowing that you can't delete, disable, or lock out the account, can use password-guessing software without risking a lockout after numerous unsuccessful attempts.

Rename the Administrator Account
To help prevent intruders from accessing your computers and gaining administrative rights from the built-in Administrator account, you can rename the Administrator account, then create a new account named Administrator and deny that account all permissions. Don't forget to delete the description of the Administrator account when you rename it. For the newly created account named Administrator, perform the following steps to deny all permissions by removing the account from the Users group (new accounts are automatically made members of the Users group):

Before you count on this procedure as a way to keep intruders from using the real (renamed) administrator account, you need to be aware that at least one software program (RedButton) lets an intruder find the real account and use it. The software displays all account SIDs, and the built-in Administrator account's SID always ends in 500. Renaming an account doesn't change its SID; only deleting an account and recreating it accomplishes that, and you can't perform those actions on the Administrator account. However, Windows has a way to prevent the display of account SIDs.

Don't Enumerate Account SIDs
You can tell Windows not to display account SIDs by using a security policy on the local computer or across the domain. (The domain policy overrides the local computer policy.) To apply a policy to a computer, take the following steps:

To apply the policy to a domain, take these steps:

Audit Account Logon Events
If you think someone is using the real (renamed) administrator account to log on to a computer or domain, you should audit logon events for that computer or domain. To do so, use the Local Security Settings snap-in for a computer or the Default Domain Policy for a domain. The policy is named Audit account logon events. For computers, the policy is available at Local PoliciesAudit Policy. For domains, the policy is available at Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy.

Double-click the policy and choose to audit for success or for both success and failure. After you enable auditing, check the Security log in Event Viewer for logons that use the renamed administrator account. For more information about auditing logon events, see "Tracking Logon and Logoff Activity in Win2K," http://www.winnetmag.com, February 2001, InstantDoc ID 16430, and "Audit Account Logon Events," March 2001, InstantDoc ID 19677.

Excluding Administrators from Group Policies
If you set domainwide group policies to control the computers and users in your enterprise, make sure restrictive policies aren't applied to the members of your IT staff to whom you've given administrative permissions. Microsoft's documentation suggests that you create an organizational unit (OU) for users and computers that you want to exempt from the default domain policy and create a new policy that applies only to the new OU. I find it more efficient to use the ACL for the default domain policy to exclude members of the Administrators group (or any other user or group object that you choose). If you didn't know that the default domain policy has ACLs, you might welcome this function as an alternative to creating and managing OUs. Here's how to edit the ACL for the default domain policy in both Windows 2003 and Win2K domains:

The Administrator account and user accounts that are members of administrative groups are powerful and therefore dangerous in the wrong hands. In fact, the danger isn't only from intruders bent on destruction. I've seen the carnage that results from employees with elevated privileges and careless work habits (or insufficient knowledge). For that reason, be careful about whom you place in administrative groups. For real safety, institute a company policy that requires administrators who aren't performing administrative work to log on to the domain with accounts that have only regular permissions. This policy will help protect your system from the effects of inadvertent actions. When a task that requires elevated permissions arises, IT staff members can use the Run As feature.