The Administrator Accounts Security Planning Guide

M

The information in this document and any document referenced herein is provided for informational purposes only, is provided AS IS AND WITH ALL FAULTS and cannot be understood as substituting for customized service and information that might be developed by Microsoft Corporation for a particular user based upon that user’s particular environment. RELIANCE UPON THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN IS AT THE USER’S OWN RISK. MICROSOFT CORPORATION PROVIDES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION CONTAINED IN THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN. Microsoft Corporation provides no warranty and makes no representation that the information provided is in this document or any document referenced herein is suitable or appropriate for any situation, and Microsoft Corporation cannot be held liable for any claim or damage of any kind that users of this document or any document referenced herein may suffer. Your retention of and/or use of this document and/or any document referenced herein constitutes your acceptance of these terms and conditions. If you do not accept these terms and conditions, Microsoft Corporation does not provide you with any right to use any part of this document or any document referenced herein. Complying with the applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter within this document. Except as provided in any separate written license agreement from Microsoft, the furnishing of this document does not give you, the user, any license to these patents, trademarks, copyrights or other intellectual property. © 2005 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Outlook, Windows, Windows Media, Exchange Server, SQL Server, Systems Management Server, Visual Studio, and Visual Basic are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Table of Contents Chapter 1: Introduction................................................................................................................. 1

Executive Summary ..................................................................................................................... 1 Overview................................................................................................................................... 1 Who Should Read This Guide.................................................................................................. 2 Planning Guide Overview......................................................................................................... 2

Chapter 2: The Approach to Making Administrator Accounts More Secure........................... 5

Why Making Administrator Accounts More Secure Is Important ................................................. 5 Why You Should Not Log On To Your Computer as an Administrator .................................... 6

Administrative Accounts and Groups Overview........................................................................... 6 Administrator Account Types ................................................................................................... 7

The Principles for Making Administrator Accounts More Secure ................................................ 8 Principle of Least Privilege ....................................................................................................... 8 Best Practices for Making Administrative Accounts More Secure........................................... 8

Chapter 3: Guidelines for Making Administrator Accounts More Secure ............................. 11

Overview of Guidelines for Making Administrator Accounts More Secure ................................ 11 Separate Domain Administrator and Enterprise Administrator Roles .................................... 11 Separate User and Administrator Accounts ........................................................................... 12 Use the Secondary Logon Service......................................................................................... 12 Run a Separate Terminal Services Session for Administration ............................................. 14 Rename the Default Administrator Account ........................................................................... 14 Create a Decoy Administrator Account .................................................................................. 15 Create a Secondary Administrator Account and Disable the Built-in Account....................... 16 Enable Account Lockout for Remote Administrator Logons .................................................. 17 Create a Strong Administrator Password............................................................................... 17 Automate Scanning for Weak Passwords.............................................................................. 19 Use Administrative Credentials on Trusted Computers Only................................................. 20 Audit Accounts and Passwords on a Regular Basis .............................................................. 20 Prohibit Account Delegation ................................................................................................... 21 Control the Administrative Logon Process ............................................................................. 21

Chapter 4: Summary ................................................................................................................... 25

Next Steps.............................................................................................................................. 25 Further Reading ..................................................................................................................... 25

1 Introduction

Executive Summary Because of their inherent permissions and power, the administrator accounts on computers that run the Microsoft® Windows Server™ 2003 operating system are both the most useful and potentially the most dangerous accounts on your computer. Any other accounts to which you grant the equivalent of administrator privileges present the same high risks.

This guide will be an indispensable resource when you plan strategies to secure administrator-level accounts in Microsoft Windows NT®–based operating systems such as Windows Server 2003 and Windows® XP. It addresses the problem of intruders who acquire administrator account credentials and then use them to compromise the network. The main goal of this guide is to provide prescriptive guidance in terms of the steps you can take to secure your local and domain-based administrator-level accounts and groups. This guidance is based on Microsoft Security Center of Excellence (SCoE) experience in customer environments and represents Microsoft best practices.

Overview An important aspect of your network security is the management of users and groups that have administrative access to the local account database on stand-alone computers and domain member computers, and to the Active Directory® directory service on your domain controllers. There are primarily two kinds of attackers that you should guard against: ● Malicious individuals who obtain administrative-level access to member servers or

domain controllers, could breach the security of your entire network. These individuals might be unauthorized users who have obtained administrative passwords, or legitimate administrators who are coerced or disgruntled.

● Users who are granted administrative access. These individuals might inadvertently cause problems because they fail to understand the ramifications of configuration changes.

Unauthorized or unknowledgeable people who have administrator privileges can maliciously or accidentally damage your organization if they copy or delete confidential data, spread viruses, or disable your network. It is vitally important to properly manage the users and groups that have administrative control over the servers and domain controllers in your network.

The default Windows Server 2003 security settings are sufficient to secure local and Active Directory accounts against many types of threats. However, you must strengthen

2 The Administrator Accounts Security Planning Guide

some of the default settings for administrative accounts to enhance the level of security of your network, and this guide will help you with that task.

Adherence to the principles and best practices in this guide can help reduce the risk of unauthorized users who gain administrative access to domain controllers, member servers, and Active Directory. The security of administrator accounts is an important initiative for organizations that seek to fully secure their network assets.

Who Should Read This Guide The intended primary audience for this guide is consultants, security specialists, systems architects, and IT professionals who are responsible for the planning stages of application or infrastructure development and the deployment of Windows Server 2003. These roles include some common job descriptions: ● Architects and planners who drive the architecture efforts for the clients in their

organizations ● IT security specialists who provide security across the platforms within their

organizations ● Enterprise architects who manage the entire enterprise rather than any one

specific network ● IT managers whose responsibility it is to determine what technology should be

used to solve certain business problems ● Business analysts and business decision makers (BDMs) who have critical

business objectives and requirements that depend on client support ● Consultants from both Microsoft Services and partners who need detailed

resources of relevant and useful information for enterprise customers and partners

Although written primarily for these roles, the Administrator Accounts Security Planning Guide can also be helpful to IT generalists in medium and large organizations, and the Infrastructure, Operations, and Security team roles identified in the Microsoft Operations Framework (MOF) Team Model. For more information about MOF, see the Microsoft Operations Framework home page at www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Planning Guide Overview This guide includes:

Chapter 1: Introduction This chapter provides an executive summary and overview and suggests the recommended audience for the guide. It also provides an overview of the chapters in this guide.

Chapter 2: The Approach to Making Administrator Accounts More Secure This chapter provides an overview of the administrative user accounts and groups that you can use to log on to a computer or domain and describes the principles to apply when planning to secure administrator accounts.

Chapter 3: Guidelines for Making Administrator Accounts More Secure This chapter describes some best practice guidelines to follow when securing administrative accounts. These guidelines follow the principles that the previous chapter discussed.

Chapter 1: Introduction 3

Chapter 4: Summary This chapter summarizes the guidance provided and addresses the problems that can occur when you apply this guidance. It also provides links to further reading materials that you might find useful.

2 The Approach to Making Administrator Accounts More Secure

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.

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

6 The Administrator Accounts Security Planning Guide

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.

Chapter 2: The Approach to Making Administrator Accounts More Secure 7

● 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.

8 The Administrator Accounts Security Planning Guide

● 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.

Chapter 2: The Approach to Making Administrator Accounts More Secure 9

● 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.

3 Guidelines for Making Administrator Accounts More Secure

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.

12 The Administrator Accounts Security Planning Guide

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 1. Click Start, and then click Run. 2. In the Run dialog box, type runas /user:<domain_name>\administrator cmd

(where <domain_name> is the name of your domain), and then click OK. 3. When prompted to enter a password for the domain_name\administrator account,

type the password for the administrator account, and then press ENTER. 4. A new console window opens, running in the administrative context. The console

title identifies itself as Running as domain_name\administrator.

Chapter 3: Guidelines for Making Administrator Accounts More Secure 13

To use Run as to run an item in Control Panel 1. In Windows XP or Windows Server 2003, click Start, and then click Control Panel. 2. While you hold down the SHIFT key, right-click the tool or program that you want to

run in administrative context (for example, Add Hardware). 3. On the shortcut menu, click Run as. 4. In the Run As dialog box, click The following user, and then type the appropriate

domain name, administrator account name, and password; for example: CORPDOMAIN\Administrator P@ssw0rd

5. Click OK. The program executes in the administrative context.

To use Run as to open a Start menu program such as Active Directory Users and Computers 1. In Windows Server 2003, click Start, point to Administrative Tools, and then

right-click Active Directory Users and Computers. 2. On the shortcut menu, click Run as.

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 1. Click Start, and then click Run. 2. In the Run dialog box, type runas /user:<localcomputername>\administrator

cmd 3. Click OK. 4. When prompted, type the administrator password in the command prompt window

and then press ENTER.

To start an instance of the Computer Management snap-in with a domain administrator account called domainadmin in the corpdomain domain 1. Click Start, and then click Run. 2. In the Run dialog box, type runas /user:<corpdomain>\<domainadmin> "mmc

%windir%\system32\compmgmt.msc" 3. Click OK. 4. When prompted, type the account password in the command prompt window and

then press ENTER.

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 1. Click Start, and then click Run. 2. In the Run dialog box, type runas /smartcard

/user:<localcomputername>\administrator cmd 3. Click OK. 4. When prompted, type the PIN number for the smart card in the command prompt

window and then press ENTER.

14 The Administrator Accounts Security Planning Guide

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 1. Log on as a member of the Domain Admins group (but not the built-in

Administrator account), and then open Active Directory Users and Computers. 2. In the console tree, click Users. 3. In the details pane, right-click Administrator, and then click Rename. 4. Type the fictitious first and last name, and then press ENTER. 5. In the Rename User dialog box, change the Full name, First name, Last name,

Display name, User logon name, and User logon name (pre-Windows 2000) values to match your fictitious account name, and then click OK.

6. In the details pane, right-click the new name, and then click Properties. 7. Click the General tab. In the Description box, delete Built-in account for

administering the computer/domain, and then type in a description to resemble other user accounts (for many organizations, this value is blank).

8. Click OK.

Chapter 3: Guidelines for Making Administrator Accounts More Secure 15

To rename the default local Administrator account 1. Log on as a member of the local Administrators group (but not the built-in

Administrator account), and open the Local Users and Groups snap-in tool in the Computer Management console.

2. In the console tree, expand Local Users and Groups, and then click Users. 3. In the details pane, right-click Administrator, and then click Rename. 4. Type the fictitious first and last name, and then press ENTER. 5. In the details pane, right-click the new name, and then click Properties. 6. Click the General tab. In the Full name box, type the new full name. In the

Description box, delete Built-in account for administering the computer/domain, and then type a description to resemble other user accounts (for many organizations, this value is blank).

7. Click OK.

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/topics/networksecurity/sec_ad_admin_groups.mspx.

To create a decoy Administrator account in a domain 1. Log on as a member of the Domain Admins group and then open Active Directory

Users and Computers. 2. Right-click the Users container, point to New, and then click User. 3. In First name and User logon name boxes, type Administrator and then click

Next. 4. Type and confirm a password. 5. Clear the User must change password at next logon check box, and then click

Next. 6. Verify that the decoy account information is correct, and then click Finish. 7. In the details pane, right-click Administrator, and then click Properties. 8. Click the General tab. In the Description box, type Built-in account for

administering the computer/domain and then click OK.

16 The Administrator Accounts Security Planning Guide

To create a decoy local Administrator account 1. Log on as a member of the local Administrators group, and open the Local Users

and Groups snap-in tool in the Computer Management console. 2. In the console tree, expand Local Users and Groups. 3. Right-click the Users container, and then click New User. 4. In the User name box, type Administrator. In the Description box, type Built-in

account for administering the computer/domain. 5. Type and confirm a password. 6. Clear the User must change password at next logon check box. 7. Click Create.

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 1. Log on as Administrator and then open Active Directory Users and Computers. 2. Right-click the Users container, point to New, and then click User. 3. In First name, and User logon name, type <user name> and then click Next. 4. Type and confirm a strong password. 5. Clear the User must change password at next logon check box, and then click

Next. 6. Verify that the account information is correct, and then click Finish. 7. In the details pane, right-click user name, and then click Properties. 8. Click on the Member Of tab, click Add, type administrators click Check Names,

and then click OK. 9. Click OK again to close the Properties page.

To disable the built-in Administrator account 1. Log on as the secondary administrator account you just created and open Active

Directory Users and Computers. 2. Click the Users container, right-click the name of the built-in Administrator account,

and then click Properties. 3. Click the Account tab. 4. Under Account options, scroll down and then select the Account is disabled

check box. 5. Click OK.

Chapter 3: Guidelines for Making Administrator Accounts More Secure 17

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: ● Contain at least 15 characters. ● Not contain an account name, real name, or company name. ● Not contain a complete dictionary word, even slang or jargon, in any language. ● Be significantly different from previous passwords. Passwords that increment

(Password1, Password2, Password3 ...) are not strong. ● Contain characters from at least three out of the five groups listed in the following

table.

18 The Administrator Accounts Security Planning Guide

Table 3.1 Character Types for a Strong Administrator Password

Character Types Example Uppercase letters A, B, C … Lowercase letters a, b, c … Numerals 0, 1, 2, 3 … Non-alphanumeric keyboard symbols ` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < >

? , . / Unicode characters €, Γ, ƒ, λ

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: ● I @te 4 tacos for lunch tod@y! ● I re@lly want to buy 11 Dogs!

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.

Chapter 3: Guidelines for Making Administrator Accounts More Secure 19

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 www.microsoft.com/technet/security/guidance/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: ● Online multiple log on attempts over the network using common weak

passwords. The Microsoft Baseline Security Analyzer (MBSA) is an example of this type of tool. This is not the recommended method because the online methodology can lead to denial of service if you enable account lockouts.

● Offline password scanning. Some good third-party offline scanning tools are available, which can help reduce an organization's security risk by enabling administrators to identify and remediate security vulnerabilities that result from weak or easily guessed passwords. Typically, these tools scan for weak passwords and then provide password quality scoring, reporting, and remediation capabilities. This is the recommended method to test for weak passwords.

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 automated system resets the password on the account to a strong password. ● The automated system sends e-mail to the server's owner to request a password

reset.

20 The Administrator Accounts Security Planning Guide

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: ● Password is blank ● Password is the same as the user account name ● Password is the same as the computer name ● Password uses the word "password" ● Password uses the word "admin" or "administrator"

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

Chapter 3: Guidelines for Making Administrator Accounts More Secure 21

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 topic in 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: ● Something that the user has, such as a smart card ● Something that the user knows, such as a personal identification number (PIN)

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.

22 The Administrator Accounts Security Planning Guide

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: ● A trusted user shares his password with an unauthorized user or records the

password in an unsafe manner (for example, a post-it note stuck to the monitor). ● The password is transmitted in clear-text format. ● A hardware or software device is used to capture input from the keyboard during

logon.

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: ● The Smart Card Deployment Cookbook, on the Microsoft TechNet Web site at

www.microsoft.com/technet/security/topics/smrtcard/smrtcdcb/default.mspx. ● Planning a Smart Card Deployment, at

www.microsoft.com/technet/prodtechnol/windowsserver2003/library/DepKit/f65c054e-4cb3-4a6e-84f6-8a9787819df5.mspx.

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

Chapter 3: Guidelines for Making Administrator Accounts More Secure 23

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: ● When using interactive logons ● When using Remote Desktop ● When logging on as a service ● When logging on as a batch job

4 Summary

Because of their inherent permissions and power, the administrative accounts on computers are both the most useful and the most dangerous accounts that exist on them.

Organizations must be especially vigilant when they secure domain-level administrator accounts because an intruder who is able to compromise a domain administrator’s account can gain extensive access to every computer in your domains and forests. Microsoft has established steps to secure domain administrator accounts on its corporate network and urges other organizations to do the same.

You should use the best practices that this guide describes as you manage your network and adhere to its principles to reduce the risk of unauthorized users who can gain administrative access to your sensitive network assets and Active Directory® directory service data.

Making administrator accounts as secure as possible is an important initiative for organizations that want to secure their network assets.

Next Steps If an organization has not yet deployed a program for the security of administrator accounts, this planning guide provides a foundation for them to plan such a program.

The main steps that organizations should take when they plan to secure administrator accounts are: ● Define a process to reduce the risk of administrator account compromise. ● Identify strategies to increase the security of administrative accounts in Active

Directory. ● Use the principle of least privilege. ● Separate domain administrator and enterprise administrator roles. ● Use the Secondary Logon service to separate user and administrator accounts. ● Follow best practice guidelines to secure administrator accounts.

Further Reading The integrity of a program to secure administrator-level accounts is dependent on its long-term maintenance. For more information about operational best practices, see the Microsoft® Operations Framework (MOF) Web site at www.microsoft.com/technet/itsolutions/techguide/mof/default.mspx .

26 The Administrator Accounts Security Planning Guide

This guide for making administrator accounts more secure is essentially a compilation of Microsoft best practices. For additional best practice considerations to secure your Active Directory infrastructure, see the following resources: ● For more information about making domain controllers more secure, see

Hardening Windows Server 2003 Domain Controllers in the Windows Server™ 2003 Security Guide at www.microsoft.com/technet/security/guidance/secmod120.mspx.

● For more information about making Windows Server 2003 more secure, download the Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?linkid=14846.

● For more information about account passwords and policies in Windows Server 2003, see the "Account Passwords and Policies" white paper at www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx.

● For more information about how to plan, build, and maintain a successful security risk management program, see The Security Risk Management Guide at www.microsoft.com/technet/security/guidance/secrisk/default.mspx.

● For more information about more secure and strong password usage, see the following Security Guidance Center papers: ● "Enforcing Strong Password Usage Throughout Your Organization" at www.microsoft.com/smallbusiness/gtm/securityguidance/articles/enforce_strong_passwords.mspx. ● "Selecting Secure Passwords" at www.microsoft.com/smallbusiness/gtm/securityguidance/articles/select_sec_passwords.mspx.

● For more information about making Active Directory more secure, see: ● Best Practice Guide for Securing Windows Server Active Directory Installations

(Windows Server 2003), on the Microsoft Web site at www.microsoft.com/windowsserver2003/techinfo/overview/adsecurity.mspx.

● Best Practices for Delegating Active Directory Administration at www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/actdid1.mspx.

Acknowledgements The Microsoft Solutions for Security group (MSS) and the Security Center of Excellence (SCoE) would like to acknowledge and thank the team that produced the Administrator Accounts Security Planning guide. The following people were either directly responsible or made a substantial contribution to the writing, development, and testing of this solution.

Authors Steve Ryan, Content Master Lee Walker

Editors Deborah Jay, Content Master Jennifer Kerns, Content Master Frank Manning, Volt

Reviewers Bill Canning Chase Carpenter Fernando Cima David Cross Mike Danseglio Kurt Dillard Jesper Johansson Matt Kestian Claudio Vacalebre Shain Wray

Program Managers Neil Bufton, Content Master Chase Carpenter Alison Woolford, Content Master

Testers Ashish Java, Infosys Technologies Mehul Mediwala, Infosys Technologies Gaurav Singh Bora, Infosys Technologies

Release Manager Flicka Crandell

Contributors Tony Bailey Krishna Bhardwaj, Vidyatech Solutions Prabish Chandran, Vidyatech Solutions Christine Duell, Valente Solutions Amy Frampton Michael Glass, Volt Karl Grunwald Joanne Kennedy Karina Larson, Volt Chrissy Lewis, Siemens Don McGowan Bivin Pachatt Vidyatech Solutions Tessa Porterfield Vivek Manohar Prabhu, Vidyatech Solutions Stacey Tsurusaki, Volt David Visintainer, Volt Vikas Walia, Vidyatech Solutions