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):

1. Right-click My Computer and choose Manage to open the Microsoft Management Console (MMC) Computer Management snap-in.
2. Expand the Local Users and Groups object in the console pane.
3. Select the Users folder in the console pane.
4. Double-click the new (decoy) Administrator account in the details pane to open its Properties dialog box.
5. Go to the Member Of tab, select the Users group, and click Remove.
6. Close the snap-in.

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:

1. Choose Start, Run and enter secpol.msc to open the MMC Local Security Settings snap-in.
2. In the console pane, expand the Local Policies object, then select the Security Options object.
3. For Win2K workstations and member servers, in the details pane, double-click Additional restrictions for anonymous connections. From the Local policy setting field's drop-down list, select Do not allow enumeration of SAM accounts and shares. For Windows 2003 member servers and XP computers, in the details pane, select Network access: Allow anonymous SID/Name translation and make sure the policy is disabled.
4. Click OK and close the snap-in.

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

1. Open the MMC Active Directory Users and Computers snap-in.
2. Right-click the domain in the console pane, and choose Properties to open the Properties dialog box.
3. Go to the Group Policy tab.
4. Select Default Domain Policy, and click Edit.
5. In the console pane, move to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
6. In a Win2K domain, double-click Additional restrictions for anonymous connections. Select the Define this policy option and select Do not allow enumeration of SAM accounts and shares from the drop-down list. In a Windows 2003 domain, double-click Network access: Allow anonymous SID/Name translation and make sure the policy is disabled.
7. Click OK and close the snap-in.

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 Policies\Audit Policy. For domains, the policy is available at Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit 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:

1. Open the Active Directory Users and Computers snap-in.
2. In the console pane, right-click the domain and choose Properties.
3. Select the Group Policy tab. (If you've installed the Group Policy Management Console—GPMC—in Windows 2003, when you select the Group Policy tab, you receive a message that the tab is no longer used and an option to open the snap-in.)
4. Select Default Domain Policy and click Properties.
5. Select the Security tab, which Figure 1 shows.
6. If the group or user you want to exempt from the policy isn't listed, click Add and select the appropriate object.
7. Select the group you want to exclude from the default domain policy (in my case, the Administrators group), and select the Deny option for the Apply Group Policy permission, as Figure 1 shows. Repeat these steps for other groups you want to exclude from the default domain policy.

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.

End of Article