The Administrator Accounts Security Planning Guide

This chapter describes some general best practice guidelines to make administrative accounts more secure. These guidelines follow the principles that Chapter 2, "The Approach to Making Administrator Accounts More Secure," introduced.

Overview of Guidelines for Making Administrator Accounts More Secure

Every new installation of the Active Directory® directory service creates an Administrator account for each domain. By default this account cannot be deleted or locked out. In Microsoft® Windows Server™ 2003, the Administrator account can be disabled, but it is automatically re-enabled when you start the computer in Safe Mode.

A malicious user who attempts to hack into a computer typically starts by finding a valid account and then tries to escalate the privileges on that account. He might also use password-guessing techniques to obtain the password for the Administrator account. He targets this account because it is powerful and cannot be locked out. He might also attempt to lure the administrator into executing some malicious code that will grant the attacker access.

Separate Domain Administrator and Enterprise Administrator Roles

Because the Enterprise Administrator role has ultimate power in a forest environment, you must take one of two actions to ensure that its use is well controlled. You can create and select a single well-protected account to be a member of Enterprise Admins, or choose not to set up an account with those credentials and instead create such an account only when an authorized task that requires those privileges demands it. After the account completes the task, you should immediately delete the temporary Enterprise Admins account.

Separate User and Administrator Accounts

For each user who fills an administrator role, you should create two accounts: one regular user account for typical everyday tasks such as e-mail and other programs, and one administrative account for administrative tasks only. You should not e-mail-enable these administrative accounts, use them to run standard programs, or to browse the Internet. Each account must possess a unique password. These simple precautions significantly reduce the exposure of the accounts to the outside world, and reduce the amount of time that administrative accounts remain logged on to a computer or domain.

Use the Secondary Logon Service

In Microsoft Windows® 2000, Windows XP Professional, and Windows Server 2003, you can run programs as a different user from the user that is currently logged on. In Windows 2000, the Run as service provides this capability, whereas in Windows XP and Windows Server 2003, it is called the Secondary Logon service. The Run as and Secondary Logon services are the same service with different names.  

Secondary logon allows administrators to log on to the computer with a non-administrative account and, without logging off, perform administrative tasks by running trusted administrative programs in administrative contexts.

A secondary logon service addresses the security risks presented by administrators who run programs that might be susceptible to malicious code; for example, a user who accesses a non-trusted Web site while logged on with administrative privileges.

Secondary logon is primarily for system administrators; however, any user who has multiple accounts, and who needs to start programs under different account contexts without logging off, can use it.

The Secondary Logon service is set to start automatically, uses the Run as tool as its user interface, and uses runas.exe as its command-line interface. With Run as, you can run programs (*.exe), saved Microsoft Management Console (MMC) consoles (*.msc), shortcuts to programs, and Control Panel items. You can run these programs as an administrator even though you logged on to your computer with a standard user account that has no administrative privileges, as long as you provide the appropriate administrative user account and password credentials when prompted for them.

Run as allows you to administer a server in another domain or forest if you have credentials for the other domain's administrator account.

Note: Some items such as the Printers folder, My Computer, and My Network Places on the desktop cannot be started with Run as.

Using Run as

Run as can be used in several ways:

To use Run as to start a command shell using domain administrator account credentials

To use Run as to run an item in Control Panel

To use Run as to open a Start menu program such as Active Directory Users and Computers

You can also use the runas.exe executable command-line utility to run programs and start management consoles from the command line.

To start an instance of the command prompt as an administrator on the local computer

To start an instance of the Computer Management snap-in with a domain administrator account called domainadmin in the corpdomain domain

You can also use runas.exe to run programs and start management consoles from the command line with smart card credentials.

To start an instance of the command prompt as an administrator on the local computer with smart card credentials

Note: It is not possible to input the password as a command-line parameter to runas.exe, because it would not be secure to do so.

Run a Separate Terminal Services Session for Administration

Run as is the most common approach that administrators use when they make changes to their local computers and possibly to execute some line-of-business programs. For your IT-based administrative tasks, you can use Terminal Services to connect to the servers that you need to manage. It is much easier to manage several remote servers without having to physically visit each one, and this approach alleviates the need for interactive logon rights on the servers. To use this method, log on with your regular user account credentials and then run a Terminal Services session as a domain administrator. You should perform domain administration tasks only within that session window.

Rename the Default Administrator Account

When you rename the default Administrator account, it removes the obvious indication that this account has elevated privileges. Although an attacker still needs the password to use the default Administrator account, a renamed default Administrator account adds an additional layer of protection against elevation of privilege attacks. One option would be to use a fictitious first and last name, in the same format as your other user names.

Note: Renaming the default administrator account hinders only certain types of attack. It remains relatively easy for an attacker to determine which account is the default Administrator account, because the security ID for this account is always the same. Additionally, tools are available that enumerate group members, and these always list the original administrator account first. For the best protection against attacks on your built-in administrator account, create a new administration account and then disable the built-in account.

To rename the default Administrator account in a domain

To rename the default local Administrator account

Note: There is also a Group Policy object (GPO) setting that you can use to rename the default Administrator account on large numbers of computers. However, this setting does not allow you to modify the default description. For more information, see the HOW TO: Rename the Administrator and Guest Account in Windows Server 2003 Knowledge Base article at http://support.microsoft.com/default.aspx?scid=kb;en-us;816109.

Create a Decoy Administrator Account

The creation of a decoy Administrator account adds an additional layer of protection. It can fool an attacker who plans a password attack on the Administrator account into an attack on an account that has no special privileges, so the attacker is less likely to discover your renamed Administrator account. It is also good practice to slow down an attacker by ensuring this decoy account does not get locked out and by setting a strong password on it. After you create the decoy account you should ensure it is not a member of any privileged security groups and then monitor the account's usage for unexpected activity such as logon failures. For more information, see Securing Active Directory Administrative Groups and Accounts at www.microsoft.com/technet/security/guidance/networksecurity/sec_ad_admin_groups.mspx.

To create a decoy Administrator account in a domain

To create a decoy local Administrator account

Create a Secondary Administrator Account and Disable the Built-in Account

Even if you do not use Terminal Services for administration or allow non-administrative users to access your servers, it is a best practice to create an additional user as a secondary administrator account to administer your servers. You should make this user a member of the Administrators group. After you create the secondary account, you can disable the built-in Administrator account.

To create a secondary administrator account

To disable the built-in Administrator account

Warning: You must be certain that there is another account that has the appropriate administrator privileges when you disable the built-in Administrator account. If you disable the account without ensuring there is another account available, you could lose administrative control of the domain, which might require a system restore or reinstall operation.

Enable Account Lockout for Remote Administrator Logons

One way to prevent attackers from using the built-in administrator account and password credentials is to allow the administrator account to be locked out of the network by an account policy, after a specified number of logon failures occur. By default, the built-in administrator account cannot be locked out; however, you can use passprop.exe, a command-line program in the Microsoft Windows 2000 Server Resource Kit, to enable account lockout for remote logons that use the administrator account. When you run the passprop utility with the /ADMINLOCKOUT switch, you make the administrator account subject to account lockout policies. In Windows 2000 Server, this only applies to remote logons, and because the built-in administrator account can never be locked out from the local computer, this program allows you to protect the administrator account from attack over the network but still allows interactive access.

Warning: In Windows Server 2003, passprop will allow the built-in administrator account to get locked out from interactive logons as well as remote logons.

You can use the following account lockout switches with passprop:

passprop [/adminlockout] [/noadminlockout]

The /adminlockout switch keeps the administrator locked out.

The /noadminlockout switch removes the administrator lock out.

Note: When you enable this setting, and the account becomes locked out, no one can do any remote administration with the administrator account.

Create a Strong Administrator Password

Use a strong password for the built-in Administrator account. A strong password minimizes the threat of an attacker who guesses the password and acquires the credentials of the Administrator account. A strong administrator account password should:

Table 3.1 Character Types for a Strong Administrator Password

Use Pass Phrases Instead of Passwords

The simplest way to create a strong password that you will not have to write down is to come up with a pass phrase. A pass phrase is essentially a sentence that you can remember, like "My son Aiden is three years older than my daughter Anna." You can make a reasonably strong password with the first letter of each word of the sentence. For example, "msaityotmda". However, you can make this password even stronger with a combination of upper and lowercase letters, numbers, and special characters that look like letters. For example, if you use the same memorable sentence and a few tricks, your password is now M$"8ni3y0tmd@.

Although pass phrases are vulnerable to dictionary attacks, most commercial password-cracking software does not check passwords of more than 14 characters. If users have long pass phrases, their passwords are less likely to be cracked and are easier for them to remember than traditional strong passwords. Users are also less likely to write passwords down if they are easy to remember. Good examples of a strong pass phrase are:

These examples contain more than 20 characters, are very long pass phrases, and include characters from four of the five possible groups. They are not well-known phrases, but they are far easier to remember than a 15-character password comprised of an alphanumeric mixture of unrelated characters, symbols, and punctuation marks that have no intrinsic meaning.

Do Not Use Blank or Weak Administrator Passwords

Although it presents a significant security risk, some organizations have weak or blank passwords on administrator accounts. Blank or weak passwords represent one of the most common vulnerabilities on a network and one of the easiest access points for intruders.

When you set blank or weak passwords on the administrator account, malicious users can gain access by the use of basic combinations, such as “Administrator” for the user name and either a blank value or “administrator” for the password. Blank and weak passwords quickly acquiesce to password-cracking attempts and are vulnerable to dictionary attacks that methodically try one word after another and brute force attacks that use a list of common characters such as A-Z and 0-9 in linear combinations.

Although a good password cannot guarantee that an intruder does not gain access to your network, it provides an excellent first-line defense.

Enforce Strong Passwords

You should ensure that your organization's network administrators use strong passwords. In Windows 2000 Server and Windows Server 2003, you can use Group Policy to enforce the use of strong passwords.

For more information about strong and secure passwords, see the Enforcing Strong Password Usage Throughout Your Organization white paper at www.microsoft.com/smallbusiness/gtm/securityguidance/articles/enforce_strong_passwords.mspx and the Selecting Secure Passwords white paper at www.microsoft.com/smallbusiness/gtm/securityguidance/articles/select_sec_passwords.mspx.

Change Administrator Passwords Periodically

You should change your privileged accounts passwords on a regular basis. The interval between each change should be determined according to the impact that the compromise of the account brings to your organization. For guidelines on how this impact can be determined, refer to The Security Risk Management Guide at http://www.microsoft.com/technet/security/guidance/complianceandpolicies/secrisk/default.mspx.

You should regularly change the passwords of your local administrator accounts. You can automate this process for your servers and workstations with the cusrmgr.exe tool included in the Microsoft Windows 2000 Server Resource Kit. For more information about how to use cusrmgr.exe, see the How to Use the Cusrmgr.exe Tool to Change Administrator Account Password on Multiple Computers Knowledge Base article at http://support.microsoft.com/kb/272530.

You should also change the Directory Services Restore Mode (DSRM) administrator password on domain controllers on a regular basis. Windows 2000 uses the setpwd utility to reset the DSRM password. In Windows Server 2003, the Ntdsutil tool provides that functionality. You can use both these tools remotely.

Automate Scanning for Weak Passwords

Weak and blank passwords significantly compromise the overall security of an organization’s network. Organizations should create or purchase software that automatically scans or tests for blank and weak passwords.

These sorts of tools employ two basic approaches:

After you identify an account with a blank or weak password, the incident response should follow your organization's established incident response protocol. Some examples of an incident response protocol are:

The latter response can prolong the period of server vulnerability.

Scan Passwords Using Microsoft Baseline Security Analyzer

You can use the Microsoft Baseline Security Analyzer (MBSA) tool, available at www.microsoft.com/technet/security/tools/mbsahome.mspx, to scan every computer on the network and search for weak passwords.

Among other security tests, MBSA can enumerate all user accounts and check for the following password weaknesses:

As a result of this scan, this check also notifies you of any disabled or currently locked out accounts.

To accomplish this test, MBSA tries to change the password on the target computer by using each of these passwords. MBSA does not reset or permanently change the password, but it alerts you if your password is not strong enough and, therefore, represents a security risk.

Use Administrative Credentials on Trusted Computers Only

Ensure that your organization's administrators never use their administrative credentials to log on to a computer for which they lack full control. A keystroke logger or screen scraper could run on the computer and capture the administrator's password credentials.

A keystroke logger is a silent spyware program that runs in the background of a user's computer. Spyware programmers design their keystroke loggers to remain in stealth mode while they record all keystrokes without the user's consent or knowledge. This information is then stored for future retrieval or transmitted back to the author of the keystroke logger for examination. Keystroke loggers can record all keystrokes including personal information such as passwords or credit card numbers. They can also record all composed e-mail or online chat sessions.

A screen scraper captures character-based data from a computer or program by examining the contents of a display that is not actually intended for data transport or inspection by programs, and then presenting it in an easier to understand graphical user interface (GUI) format. Newer screen scrapers present the information in HTML, so that the information is accessible with a browser.

Audit Accounts and Passwords on a Regular Basis

Regular audits help to ensure the integrity of domain security and protect against privilege escalation. Privilege escalation can provide user accounts with unauthorized administrative privileges. Unless you protect administrative capabilities, attackers can induce vulnerabilities and bypass security measures. For example, attackers that have administrative privileges can create bogus user accounts, add accounts to membership groups without permission, elevate the privileges of accounts that already exist, add or modify policies, and disable security settings.

You should audit all domain-level administrative users and groups, and all local administrative users and groups on sensitive servers on a regular basis. Because administrators can have the ability, but not the authority, to make modifications on their own administrative accounts, organizations must guarantee that the accounts comply with security policy for domain-level administrative users. It is important to audit the use of these privileged credentials and to realize that the audit is not merely to check password strength. The audit is also a useful tool to find out what tasks have been performed by the administrative accounts. Use Event Viewer to view the Security logs created after you configure and enable auditing. Regular audits can also detect unused domain-level administrative accounts. Inactive domain-level administrative accounts present a vulnerability to the network environment, especially if an attacker compromises them without you noticing. You should remove any unused domain-level administrator accounts and groups.

Prohibit Account Delegation

You should designate all domain-level administrator user accounts as Account is sensitive and cannot be delegated. This action helps protect the credentials from impersonation through a server that is marked as trusted for delegation.

Delegated authentication occurs when a network service accepts a request from a user and assumes that user’s identity to initiate a new connection to a second network service. Delegated authentication is useful for multi-tier applications that use single sign-on capabilities across multiple computers. For example, domain controllers are automatically trusted for delegation. If you enable Encrypting File System (EFS) on a file server, the server must be trusted for delegation to store encrypted files on behalf of users. Delegated authentication is also useful for programs where Internet Information Services (IIS) supports a Web interface to a database that runs on another computer, such as Microsoft Outlook® Web Access (OWA) in Microsoft Exchange Server or for Web Enrollment Support pages for an enterprise certification authority if a separate Web server hosts the pages.

You should deny the right to participate in delegated authentication for the computer accounts in Active Directory, for computers that are not physically secure, and to domain administrator accounts. Domain administrator accounts have access to sensitive resources and, if compromised, pose a high risk to your organization. For more information see the Enabling Delegated Authentication topicin the Windows Server 2003 Deployment Kit at www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dsscc_aut_vwcs.asp.

Control the Administrative Logon Process

Members of the Administrators, Enterprise Admins, and Domain Admins groups represent the most powerful accounts in your forest and in each individual domain. To minimize security risks, take the steps described in the subsequent sections of this guide to enforce strong administrative credentials.

Require Smart Cards for Administrative Logon

Domain administrators should be required to use two-factor authentication for all of their administrative functions. Two-factor authentication requires two parts:

The requirement of both factors mitigates the risks of unauthorized access by means of shared, stolen, or duplicated single-factor credentials such as user names and passwords.

Two-factor authentication is an important element when you secure domain administrator accounts because conventional user names and passwords are free-text credentials that are generally formed with natural language character sets. As such, a malicious user could steal, share, or duplicate them if:

If you require your administrators to use smart cards for their interactive logons, it forces the administrative users to have physical possession of the cards to log on and ensures the use of randomly generated, cryptographically strong passwords on the user accounts. These strong passwords help protect against the theft of weak passwords to gain administrative access.

You can enforce the use of smart cards if you enable the Smart card is required for interactive logon account option for each administrative user account.

The smart card PIN is an encrypted code that the individual card owner sets and stores on the card. This PIN is a string that the user must provide when they authenticate with the smart card to make the private key available for use. Each private key on a smart card is unique, which guarantees the singularity of the authentication.

Smart card authentication is especially important when a domain administrator uses interactive logon. Smart cards can make life easier for domain administrators who are responsible for multiple servers, each of which requires authentication. Rather than require an administrator to have a separate password for each server to which he must authenticate, you can protect the servers with unique smart cards that share a common PIN.

Note: Windows 2000 Server supports the use of smart cards for remote access; however, Windows Server 2003 is required to support the use of smart cards for domain-level accounts. Windows Server 2003 is also required to use smart card credentials with the Secondary Logon service runas command.

The deployment of smart cards for domain administrators and the adoption of the principles and practices that this guide describes, can help organizations significantly enhance the security of their network assets.

For more information about the use of smart cards for authentication, see the following resources:

Share Logon Credentials for Sensitive Administrative Accounts

For each account that you regard as sensitive, for example, one that is a member of the Enterprise Admins or Domain Admins groups in the forest root domain, assign two users to share that account so that both users must be present to successfully log on with it. When you share these accounts, it provides inherent visual auditing: One user observes the actions that the other user performs. It also prevents a single user from privately logging on to access the computer as an administrator to compromise its security as either a rogue administrator or under coerced circumstances.

You can implement shared administrative accounts that use split passwords or smart cards plus PINs. If you use password-based credentials for administrative accounts, split the password between the two users who share that account so that each user knows only half of the password. Each user is responsible for the maintenance of their half of the password. For example, you can create an administrative account called Admin1 and assign two trusted users, Jane and Bob, to share this account. Each user maintains half of the password. For one of them to log on and use the account, the other must be present to enter the other half of the password.

The disadvantage of the shared administrative account option is that there is an inherent lack of accountability through auditing. Organizations will need to have some other control in place, such as camera surveillance, to ensure that users do not abuse these shared privileges.

If you use smart-card – based credentials for administrative accounts, split ownership of the smart card and its PIN between the two users who share the account so that one user retains physical ownership of the smart card, and the other user maintains the PIN. This way, both users must be present to log on to the account.

Restrict How and Where Domain Administrators Can Log On

Organizations should restrict how and where a domain-level administrator can log on. If required by their task or role, administrators can log on interactively to domain controllers to which they have privileges — but you should still require two-factor authentication.

You should prohibit domain administrators from logging on to any computer that is not specifically approved for domain administrator usage in the following cases:

Top of page

4 of 6