TechNet Home > TechNet Security > Library > Server Security

The Administrator Accounts Security Planning Guide

Chapter 2 - The Approach to Making Administrator Accounts More Secure

Updated: June 30, 2005

This chapter describes why it is important to make administrator accounts as secure as possible and provides an overview of the administrative user accounts and groups that you can use to log on to a computer or domain. It also describes the basic principles to consider when you plan to secure administrator accounts.

On This Page
Why Making Administrator Accounts More Secure Is ImportantWhy Making Administrator Accounts More Secure Is Important
Administrative Accounts and Groups OverviewAdministrative Accounts and Groups Overview
The Principles for Making Administrator Accounts More SecureThe Principles for Making Administrator Accounts More Secure

Why Making Administrator Accounts More Secure Is Important

Making administrator accounts as secure as possible is essential to provide comprehensive protection for an organization’s network assets. You need to protect every computer that an administrator might use, which includes domain controllers, servers, and any workstations that they use. Your organization's IT group should maintain your domain controllers and certificate authority servers as securely as possible, because they are considered highly trusted assets. You must also protect administrators' desktop and mobile computers as trusted assets, because administrators use them to remotely manage the forest, domain, and infrastructure.

Member servers that connect to domain controllers frequently require elevated privileges to connect and provide services. Because this usually requires the server to hold elevated credentials—typically domain-level administrative rights—the compromise of any of these servers can immediately lead to the compromise of the entire domain. For example, an attacker might take control of a single member server and use it as a point from which to attack the entire domain.

Making domain administrator accounts as secure as possible is even more critical when you use secure environment trusts across forests or domains. Organizations must be able to assume that they can use domain accounts in all trusting domains and that the same high standards of protection of administrator accounts are applied across all domains. For example, consider that you have a situation with a root domain called Test.com and two sub domains, called TestA.com and TestB.com. If the administrators for TestB.com are explicitly granted administrative privileges in TestA.com, or are members of the forest-wide Enterprise Admins group, it would be futile to protect the administrator accounts on TestA.com. This is because, if administrator accounts from TestB.com are not secure, intruders in the TestB.com unsecured domain could gain administrative access to the secured TestA.com domain.

Why You Should Not Log On To Your Computer as an Administrator

If you regularly log on to your computer as an administrator to perform common application-based tasks, you make the computer vulnerable to malicious software and other security risks because malicious software will run with the same privileges you used to log on. If you visit an Internet site or open an e-mail attachment, you can damage the computer because malicious code could be deployed that will download and execute on your computer.

If you log on as an administrator of a local computer, malicious code can, among other things, reformat your hard disk drive, delete your files, and create a new user account that has administrative privileges. If you log on as a member of the Domain Admins group, Enterprise Admins group, or Schema Admins group in the Active Directory® directory service, malicious code can create a new domain user account that has administrative access or put schema, configuration, or domain data at risk.

On a local computer, you should add your domain user account to the Users group only (and not to the Administrators group) to perform such routine tasks as running programs or visiting Internet sites. When it is necessary to perform administrative tasks on the local computer or in Active Directory, use the Run as command to start a program with administrative credentials.

The Run as command allows you to accomplish administrative tasks while you expose your computer or Active Directory data to fewer risks. For more information about how to use the Run as command, see the Use the Secondary Logon Service section in Chapter 3, "Guidelines for Making Administrator Accounts More Secure," of this guide.

Note: For more information about using Run as in Microsoft® Windows® 2000, Windows XP, and Windows Server™ 2003, see Knowledge Base articles 294676, 305780, 325859, and 325362. You can locate these articles by number at the Search the Support Knowledge Base (KB) Web site at http://support.microsoft.com/default.aspx?scid=fh;en-us;KBHOWTO  

Administrative Accounts and Groups Overview

There are several administrative user accounts and groups whose credentials can be used to log on to a computer or domain. Administrative accounts in an Active Directory domain include:

•

The Administrator account, which is created when you install Active Directory on the first domain controller in the domain. This is the most powerful account in the domain. The person who installs Active Directory on the computer creates the password for this account during installation. If the domain is the first domain created in a forest, it is automatically the forest root domain and therefore contains the Enterprise Admins group. The Administrator account for this forest root domain is a member of the Enterprise Admins group by default and as such has administrative privileges throughout the forest. By default, the first administrator account created in each domain is also the Data Recovery Agent (DRA) for the Encrypting File System (EFS) in each domain.

•

Accounts that you later create and to which you either directly assign administrative privileges or place into a group that has administrative privileges.

•

Accounts that use EFS Data Recovery Agent certificates, Enrollment Agent certificates, or Key Recovery Agent certificates. Accounts that use these agent certificates are very powerful accounts and should also be secured. For example, after someone has an Enrollment Agent certificate, they can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capabilities of these agent certificate accounts, it is recommended that organizations maintain a strong security policy over who has them.

The number of administrative groups in an Active Directory domain varies, depending on the installed services. Groups used specifically for the administration of Active Directory include:

•

Administrative groups that already exist in the Builtin container; for example, Account Operators and Server Operators. Note that groups in the Builtin container cannot be moved to another location.

•

Administrative groups that already exist in the Users container; for example, Domain Admins and Group Policy Creator Owners.

•

Groups that you later create and either place into a group that has administrative privileges or to which you directly assign administrative privileges.

The default administrative groups and accounts in a domain environment are:

•

Enterprise Admins (exists in forest root domains only)

•

Domain Admins (exists in all domains)

•

Schema Admins (exists in forest root domains only)

•

Group Policy Creator Owners (exists in forest root domains only)

•

Administrators group

•

Administrator account

•

DS Restore Mode Administrator (available in Directory Services Restore Mode only. This account is local to the domain controller and is not a domain-wide account. The password for this account is set when you install Active Directory on the computer.)

For a full description of each of these administrative accounts and groups, see the "Default Groups: Active Directory" and "User and Computer Accounts" topics in the Windows Server 2003 Help and Support Center.

Administrator Account Types

Essentially three categories of administrator accounts exist to log on to a computer or domain. Each category has unique capabilities and privileges.

•

Local Administrator Accounts. This category includes the built-in Administrator account, which Windows Server 2003 creates and uses when you first install it on a computer. This category also includes any other user accounts that you subsequently create and add to the built-in local Administrators group. Members of this group have complete and unrestricted access to the local computer.

•

Domain Administrator Accounts. This category includes the built-in domain Administrator account, which Active Directory creates and uses when you first install it. This category also includes any other user accounts that you subsequently create and add to the built-in local Administrators group or to the Domain Admins group. Members of these groups have complete and unrestricted access to the domain, and, if not secured correctly, to the entire forest.

•

Forest Administrator Accounts. This category includes the built-in domain Administrator account from the first domain you create in your forest, which is known as the forest root domain, because the Administrator account in the forest root domain is automatically added to the Enterprise Admins group when you install Active Directory. This category also includes any other user accounts that you subsequently create and add to the Enterprise Admins group. Members of the Enterprise Admins group have complete and unrestricted access to the entire forest. Enterprise Admins can also install Certification Authorities, which can then be used to impersonate any user in the forest.

The Principles for Making Administrator Accounts More Secure

When planning how to make administrative accounts more secure, you should:

•

Apply the principle of least privilege

•

Follow best practice guidelines for making administrator accounts more secure

Principle of Least Privilege

Most security-related training courses and documentation discuss the implementation of a principle of least privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it correctly greatly increases your security and reduces your risk. The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more. Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers.

One reason this principle works so well is that it forces you to do some internal research. For example, you must determine the access privileges that a computer or user really needs, and then implement them. For many organizations, this task might initially seem like a great deal of work; however, it is an essential step to successfully secure your network environment.

You should grant all domain administrator users their domain privileges under the concept of least privilege. For example, if an administrator logs on with a privileged account and inadvertently executes a virus program, the virus has administrative access to the local computer and to the entire domain. If the administrator had instead logged on with a non-privileged (non-administrative) account, the virus's scope of damage would only be the local computer because it runs as a local computer user.

In another example, accounts to which you grant domain-level administrator rights must not have elevated rights in another forest, even if there is a trust relationship between the forests. This tactic helps prevent widespread damage if an attacker manages to compromise one managed forest. Organizations should regularly audit their network to protect against unauthorized escalation of privilege.

Best Practices for Making Administrative Accounts More Secure

The best practice guidelines you should follow to make the use of administrative accounts more secure in Windows Server 2003 include to:

•

Separate domain administrator and enterprise administrator roles.

•

Separate user and administrator accounts.

•

Use the Secondary Logon service.

•

Run a separate Terminal Services session for administration.

•

Rename the default Administrator account.

•

Create a decoy Administrator account.

•

Create a secondary Administrator account and disable the built-in Administrator account.

•

Enable Account Lockout for Remote Administrator Logons.

•

Create a strong Administrator password.

•

Automate scanning for weak passwords.

•

Use administrative credentials on trusted computers only.

•

Audit accounts and passwords on a regular basis.

•

Prohibit account delegation.

•

Control the administrative logon process.

For more information about these best practice guidelines, see Chapter 3, "Guidelines for Making Administrator Accounts More Secure," of this guide.


**
In This Article
•Overview
•Chapter 1 -Introduction
•Chapter 2 - The Approach to Making Administrator Accounts More Secure
•Chapter 3 - Guidelines for Making Administrator Accounts More Secure
•Chapter 4 - Summary
•Acknowledgements
**

Download

Get the Administrator Accounts Security Planning Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions