Securing Active Directory Administrative Groups and Accounts

55 out of 66 rated this helpful - Rate this topic

On This Page

Introduction Before You Begin Creating a New User Account with Domain Admins Credentials Protecting the Administrator Account Securing the Guest Account Strengthening Security on Service Administration Accounts and Groups Establishing Best Practices for Use of Administrative Accounts and Groups Related Information

Introduction
An important part of securing your network is managing the users and groups that have administrative access to the Active Directory directory service. Malicious individuals who obtain administrative access to Active Directory domain controllers can breach the security of your network. These individuals might be unauthorized users who have obtained administrative passwords, or they might be legitimate administrators who are coerced or disgruntled. Furthermore, not all problems are caused with malicious intent. A user who is granted administrative access might also inadvertently cause problems by failing to understand the ramifications of configuration changes. For these reasons, it is important to carefully manage the users and groups that have administrative control over domain controllers. The default Microsoft Windows Server 2003 security settings are sufficient to secure Active Directory accounts against many types of threats. However, some default settings for administrative accounts can be strengthened to enhance the level of security of your network. This guide contains step-by-step instructions that show you how to:

Create a new user account with Domain Admins credentials Protect the default Administrator account Secure the Guest account Strengthen security on service administration accounts and groups Establish best practices for use of administrative accounts and groups.

Use the best practices described in this guide as you manage your network. This will help reduce the risk of unauthorized users gaining administrative access to Active Directory, and maliciously or accidentally damaging your organization by copying or deleting confidential data or by disabling your network.

IMPORTANT: All the step-by-step instructions included in this document were developed by using the Start menu that appears by default when you install your operating system. If you have modified your Start menu, the steps might differ slightly. Top Of Page

Before You Begin

Before using this guide to secure your administrative groups and accounts, first complete the tasks in "Securing Windows Server 2003 Domain Controllers" in the Security Guidance Kit. In order to complete the procedures provided in this guide, you must know the name and password of the built-in administrator account, or the name and password of an account that is a member of the built-in Administrators group on your domain controllers. Determine which server (or servers) on your network are running as domain controllers. A domain controller is a server running Windows Server 2003 on which Active Directory is installed. Before you begin, you must understand these administrative accounts and groups and how administrative responsibility is shared by service administrators and data administrators. To view and manage Active Directory accounts and groups, click Start, then select Administrative Tools, and then click Active Directory Users and Computers. Understanding Administrative Accounts and Groups Administrative accounts in an Active Directory domain include:

The Administrator account, which is created when Active Directory is installed 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. Any accounts that you later create and either place in a group that has administrative privileges or directly assign administrative privileges.

Administrative groups in an Active Directory domain vary depending on the services that you have installed in your domain. Those used specifically for administering Active Directory include:

Administrative groups that are automatically created in the Builtin container. Administrative groups that are automatically created in the Users container. Any groups that you later create and either place in another group that has administrative privileges or directly assign administrative privileges.

Understanding Service Administrators and Data Administrators For Active Directory in Windows Server 2003, there are two types of administrative responsibility. Service administrators are responsible for maintaining and delivering the directory

service, including domain controller management and directory service configuration. Data administrators are responsible for maintaining the data that is stored in the directory service and on domain member servers and workstations. In a small organization, these two roles might be performed by the same person, but it is important to understand which default accounts and groups are service administrators. Service administration accounts and groups have the most widespread power in your network environment and require the most protection. They are responsible for directory-wide settings, installation and maintenance of software, and application of operating system service packs and updates on domain controllers. The following table lists the default groups and accounts that are used for service administration, their default locations, and a brief description of each. Groups in the Builtin container cannot be moved to another location. Default Service Administrator Groups and Accounts Group or Account Name Enterprise Admins Schema Admins Default Location Users container Users container Builtin container Description This group is automatically added to the Administrators group in every domain in the forest, providing complete access to the configuration of all domain controllers. This group has full administrative access to the Active Directory schema. This group has complete control over all domain controllers and all directory content stored in the domain, and it can change the membership of all administrative groups in the domain. It is the most powerful service administrative group. This group is automatically added to the corresponding Administrators group in every domain in the forest. It has complete control over all domain controllers and all directory content stored in the domain and it can modify the membership of all administrative accounts in the domain. By default, this built-in group has no members. It can perform maintenance tasks, such as backup and restore, on domain controllers. By default, this built-in group has no members. It can create and manage users and groups in the domain, but it cannot manage service administrator accounts. As a best practice, do not add members to this group, and do not use it for any delegated administration. By default, this built-in group has no members. It can perform backup and restore operations on domain controllers. This special account is created during the Active Directory

Administrators

Domain Admins

Users container

Server Operators

Builtin container

Account Operators Backup Operators DS Restore

Builtin container Builtin container Not stored

Mode Administrator

in Active Directory

installation process, and it is not the same as the Administrator account in the Active Directory database. This account is only used to start the domain controller in Directory Services Restore Mode. In Directory Services Restore Mode, this account has full access to the system and all files on the domain controller.

The accounts and groups listed in this table and all members of these groups are protected by a background process that periodically checks and applies a specific security descriptor, which is a data structure that contains security information associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the administrative accounts or groups will be overwritten with the protected settings. This security descriptor is present on the AdminSDHolder object. This means that if you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object so that it will be applied consistently. Be careful when making these modifications because you are also changing the default settings that will be applied to all of your protected administrative accounts. For more information about modifying permissions on service administrator accounts, see "Best Practice Guide for Securing Active Directory Installations" (Windows Server 2003) on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22342. Top Of Page

Creating a New User Account with Domain Admins Credentials

If you do not already have a user account that is a member of the Domain Admins group, other than the default Administrator account, create one that you will use to perform the tasks in this guide. As the administrator of your network, you will use this new account only when you need to perform tasks that require Domain Admin credentials. Do not remain logged on with this account after you finish performing these tasks. If the computer contracts a virus while a domain administrator is logged on, the virus runs in the context of that domain administrator. In this way, the virus could use the administrator's privileges to infect the workstation and the rest of the network. Create another user account for data management and day-to-day use such as running Microsoft Office and sending and receiving e-mail, but do not add that user account to the Domain Admins group. Secure practices for creation and use of administrative accounts are described later in this paper. Requirements

Credentials: Domain Admins (if this is the first administrative account you have created, log on by using the default Administrator account) Tools: Active Directory Users and Computers To create a new user account with Domain Admins credentials 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers.

Note: Screenshots in this document reflect a test environment and the information might differ from the information displayed on your computer. 2. Right-click the Users container, click New, and then click User.

3. Type the First name, Last name, and User logon name, and then click Next. As shown in the example, you might want to follow a naming convention for naming your administrative accounts. For example, you might decide to append "?ALT" to the name of the administrative user to arrive at the logon name for the administrative account.

4. Type and confirm the user password, clear the User must change password at next logon check box, and then click Next.

5. Review the account information and then click Finish. 6. With the Users container selected, in the details pane (right pane), double-click the Domain Admins group.

7. Click the Members tab.

8. Click Add and then, in the Select Users, Contacts, or Computers dialog box, type the user logon name of the administrative account you just created, and then click OK.

9. Verify that your new account appears as a member of the Domain Admins group.

Top Of Page

Protecting the Administrator Account

Every installation of Active Directory has an account named Administrator in each domain. This account cannot be deleted or locked out. In 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 attempting to break into a system would typically start by attempting to try to obtain the password for the all-powerful Administrator account. For this reason, rename it and change the text in the Description to eliminate anything that indicates that this is the Administrator account. In addition, create a decoy user account called Administrator that has no special permissions or user rights. Always give the Administrator account a long, complex password. Use different passwords for the Administrator and DS Restore Mode Administrator accounts. For more information about creating complex passwords, see "Selecting Secure Passwords" in the Security Guidance Kit. Renaming the Default Administrator Account This procedure removes any obvious information that can alert attackers that this account has elevated privileges. Although an attacker that discovered the default Administrator account would still need the password to use it, renaming the default Administrator account adds an additional layer of protection against elevation of privilege attacks. Use a fictitious first and last name, in the same format as your other user names. Do not use the fictitious name shown in the example below.

Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To rename the default Administrator account 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Users. 3. In the details pane (right pane), right-click Administrator, and then click Rename.

4. Type the fictitious first and last name and 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 pane), right-click the new name, and then click Properties. 7. On the General tab, delete the Description "Built-in account for administering the computer/domain" and type in a description to resemble other user accounts (for many organizations, this will be blank).

8. On the Account tab, verify that the logon names are correct. Note: This procedure changes only the default Administrator account's logon name and account details, which someone can see if they manage to enumerate a list of accounts on your system. This procedure does not affect the ability to use

the DS Restore Mode Administrator account to start Directory Services Restore Mode, as they are two different accounts. Creating a Decoy Administrator Account This procedure adds an additional layer of protection when you hide the default Administrator account. An attacker planning a password attack on the Administrator account can be fooled into attacking an account with no special privileges.
Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To create a decoy Administrator account 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, click New, and then click User. 3. In First name and User logon name, type Administrator and then click Next.

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

6. Verify that the decoy account is created and click Finish.

7. In the details pane (right pane), right-click Administrator, and then click Properties. 8. On the General tab, in the Description box, type Built-in account for administering the computer/domain, and then click OK. Top Of Page

Securing the Guest Account

The Guest account allows users who do not have an account in your domain to log on to the domain as a guest. This account is disabled by default, and should remain disabled, but hiding

the account adds an additional layer of protection against unauthorized access. Use a fictitious first and last name, in the same format as your other user names. Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To rename the Guest account 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Users. 3. In the details pane (right pane), right-click Guest, and then click Rename. 4. Type the fictitious first and last name and press Enter. 5. Right-click the new name, and then click Properties. 6. On the General tab, delete the Description "Built-in account for guest access to the computer/domain" and type in a description to resemble other user accounts (for many organizations, this will be blank). 7. In the First name and Last name boxes, type the fictitious names. 8. On the Account tab, type a new User logon name, using the same format you use for your other user accounts, for example, first initial and last name. 9. Type this same new logon name in the User logon name (pre-Windows 2000) box, and then click OK. 10. Verify that the account is disabled. The icon should appear with a red X over it. If it is enabled, right-click the new name, and then click Disable Account.

Top Of Page

Strengthening Security on Service Administration Accounts and Groups

Creating a controlled organizational unit (OU) subtree in Active Directory and configuring it with its recommended security settings can help provide a more secure environment for service administrator accounts and workstations. OUs are containers within domains that can contain other OUs, users, groups, computers, and other objects. These OUs and sub-OUs form a hierarchical structure within a domain, and are primarily used to group objects for management purposes. By creating a subtree containing all service administrator accounts and the administrative workstations that they use, you can apply specific security and policy settings to maximize their protection. To create the controlled subtree, perform the following tasks: 1. Create the OU structure for the controlled subtree. 2. Set the permissions on the controlled subtree OUs.

3. 4. 5. 6.

Move service administrator groups to the controlled subtree. Move service administrator user accounts to the controlled subtree. Move service administrator workstation accounts to the controlled subtree. Enable auditing on the controlled subtree OUs.

Creating the OU Structure for the Controlled Subtree To create the subtree, create three OUs:

Service Admins, under the domain root, to hold the following two sub-OUs o Users and Groups, to hold administrative user and group accounts. o Admin Workstations, to hold administrative workstations.

Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To create the OU structure for the controlled subtree 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), right-click the domain name, point to New, and then click Organizational Unit. 3. In the Name box, type Service Admins and click OK. 4. In the console tree (left pane), right-click Service Admins, point to New, and then click Organizational Unit. 5. In the Name box, type Users and Groups and click OK. 6. In the console tree (left pane), right-click Service Admins, point to New, and then click Organizational Unit. 7. In the Name box, type Admin Workstations and click OK. 8. Verify that your OU hierarchy resembles the following structure, with Service Admins at the level under the domain name, and Users and Groups and Admin Workstations at the level under Service Admins.

Setting the Permissions on the Controlled Subtree OUs Doing the following can help limit access to the controlled subtree so that only service administrators can administer the membership of service administrator groups and workstations:

Block inheritance of permissions on the Service Admins OU so that inheritable permission changes that are made higher up in the domain tree are not inherited down, altering the locked-down settings. Set the permissions on the Service Admins OU.

Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To set permissions on the Service Admins OU 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. On the View menu, select Advanced Features. 3. Right-click the Service Admins OU, and then click Properties.

4. On the Security tab, click Advanced to view all of the permission entries that exist for the OU.

5. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box.

6. In the Security dialog box, click Remove. This removes the permissions that were inherited from the domain.

7. Remove the remaining permissions. Select all the remaining permission entries and then click Remove. 8. For each group listed in the Name column of the table below, add a permission entry to agree with the Access and the Applies to columns as shown in the table. To add an entry, click Add, then in the Select User, Computer, or Group dialog box, click Advanced. In the expanded dialog box, click Find Now. In the search results box, select the group name and click OK twice. This brings up the Permission Entry dialog box, where you can select the Access and Applies To items to agree with the table. Permission Settings for the Service Admins OU Type Allow SYSTEM Allow Enterprise Admins Allow Domain Admins Allow Administrators Name Access Full Control Full Control Full Control Full Control Applies To This object and all child objects This object and all child objects This object and all child objects This object and all child objects

List Contents Read All Pre-Windows 2000 Allow Properties Compatible Access Read Permissions List Contents Read All Pre-Windows 2000 Allow Properties Compatible Access Read Permissions Allow Enterprise Domain Controllers List Contents

User objects

InetOrgPerson objects

This object and all child

Allow Authenticated Users

Read All Properties Read Permissions List Contents Read All Properties Read Permissions

objects

This object and all child objects

Moving Service Administrator Groups into the Users and Groups OU Move the following service administrator groups from their current location in the directory into the Users and Groups OU in your controlled subtree:

Domain Admins and any nested subgroups. Enterprise Admins and any nested subgroups. Schema Admins and any nested subgroups. Any groups that are nested in the domain's Administrators, Server Operators, Backup Operators, or Account Operators groups. Any group that has delegated rights that effectively grant its users service administrator rights.

The built-in groups (Administrators, Server Operators, Account Operators, and Backup Operators) cannot be moved from their default container to the controlled subtree. However, built-in groups are protected by default in Windows Server 2003 by AdminSDHolder. If your organization has not created any nested subgroups or delegated service administration rights to any group, you will need to move only Domain Admins, Enterprise Admins, and Schema Admins.
Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To move service administrator groups into the Users and Groups OU 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Users. 3. In the details pane (right pane), right-click Domain Admins, and then click Move. 4. In the Move box, double-click Service Admins, click Users and Groups, and then click OK. 5. Verify that the Domain Admins group is now in the Users and Groups OU.

6. Repeat the procedure for all service administrator groups listed above. Note that if you have nested groups under builtin groups such as Administrators, or groups you previously created and assigned administrative privileges, their original location might not be the Users container. Moving Service Administrator User Accounts into the Users and Groups OU Move the following user accounts from their current locations in the directory into the Users and Groups OU in your controlled subtree:

All administrative user accounts that are members of any of the service administrator groups listed in the Default Service Administrator Groups and Accounts table. This includes the domain Administrator account (which you previously renamed.) The decoy administrator account that you created in an earlier procedure in this guide.

As recommended, each service administrator should have two accounts: one for service administration duties and one for data administration and typical user access. Place the administrative user accounts in the Users and Groups OU in your controlled subtree. If these accounts already exist elsewhere in the directory, move them into the subtree now. The regular user accounts for those administrators should not be placed in this controlled subtree. Regular user accounts will remain in their original location: in the Users container, or in an OU used by your organization to hold user accounts.
Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To move service administrator accounts into the Users and Groups OU

1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Users. 3. In the details pane (right pane), right-click the name of your renamed administrator account, and then click Move. 4. In the Move box, double-click Service Admins, click Users and Groups, and then click OK. 5. Verify that the account is now in the Users and Groups OU. 6. Repeat the procedure for all service administrator accounts listed above. Note that if you have previously created administrative accounts or other OUs, their original location might not be the Users container. Moving Administrative Workstation Accounts into the Admin Workstations OU Move the computer accounts for workstations used by administrators into the Admin Workstations OU in your controlled subtree. IMPORTANT: Do not move any domain controller accounts out of the default Domain Controllers OU, even if some administrators log on to them to perform administrative tasks. Moving these accounts will disrupt the consistent application of domain controller policies to all domains.
Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To move service administrative workstation accounts into the Admin Workstations OU 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Computers. 3. In the details pane (right pane), right-click the name of a workstation used by an administrator, and then click Move. 4. In the Move box, double-click Service Admins, click Admin Workstations, and then click OK. 5. Verify that the computer account is now in the Admin Workstations OU. 6. Repeat the procedure for all administrative workstations.

Enable Auditing on the Controlled Subtree Auditing and tracking additions, deletions, and changes to the service administrator accounts, workstations, and policies can help identify improper or unauthorized changes that are frequent indicators of unauthorized actions or attempts to gain unauthorized access to your system. Assuming that you have enabled auditing on your domain controllers in accordance with the recommendations in "Securing Windows Server 2003 Domain Controllers" in the Security Guidance Kit, enabling auditing on the Service Admins OU creates a security audit log that

tracks such changes. Monitoring the security audit log for changes to the controlled subtree and verifying that the changes are legitimate can help identify unauthorized use. To access the security audit log, click Start, point to Administrative Tools, click Event Viewer, and then click Security.
Requirements

Credentials: Domain Admins Tools: Active Directory Users and Computers To enable auditing on the controlled subtree 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. On the View menu, select Advanced Features. 3. Right-click the Service Admins OU, and then click Properties. 4. On the Security tab, click Advanced, and then select the Auditing tab to view the current auditing settings that exist for the OU. Note that in this example, the current settings are both inherited from the domain.

5. Click Add to create an auditing entry that will apply to the Service Admins OU and its child OUs. 6. In the Enter the object name to select box, type Everyone and click OK.

7. In the Access box, select both Successful and Failed for the Access items shown in the table below, and then click OK. Note that when you select some check boxes, other access items are selected automatically. These should not be changed.

Auditing Settings on the Service Admins OU Type Name Access All Everyone Write All Properties All Everyone Delete All Everyone Delete Subtree All Everyone Modify Permissions All Everyone Modify Owner All Everyone All Validated Writes Applies To This object and all child objects This object and all child objects This object and all child objects This object and all child objects This object and all child objects This object and all child objects

All All All Top Of Page

Everyone All Extended Rights This object and all child objects Everyone Create All Child Objects This object and all child objects Everyone Delete All Child Objects This object and all child objects

Establishing Best Practices for Use of Administrative Accounts and Groups

Establishing the following best practices for use of administrative accounts and groups can help reduce the likelihood that your computers and network will be affected by unauthorized users gaining access to an account with elevated access rights or legitimate users unintentionally disrupting your network through ill-informed use of their administrative rights:

Limit the number of service administrator accounts Separate administrative and user accounts for administrative users Assign trustworthy personnel Limit administrator rights to those rights that are actually required Control the administrative logon process Secure service administrator workstations Understand data delegation

Limiting the Number of Service Administrator Accounts Keeping the membership of service administrator accounts to the absolute minimum that is necessary to support your organization is a key way to limit unauthorized use. For small organizations, two accounts that are members of the Domain Admins group is typically sufficient. Limiting these memberships reduces the number of possible administrative accounts that can be compromised by malicious users. Tasks that are performed by service administrators should be limited to changing the Active Directory service configuration and reconfiguring domain controllers. Do not use service administrator accounts for day-to-day administrative tasks, such as account and member server management; instead, use your regular user account. To use your regular user account for account and member server management, you can place the objects to be managed in a separate OU, and then make your regular user account a member of a group with permissions to manage that OU. Domain Admins credentials are required to perform the following steps: 1. Create an OU under the domain root called Data. Use this OU to hold all objects that you want to be managed by data administrators, for example, regular users, their workstations, and member servers. Note: You might also want to create at least two OUs within the Data OU, one called Users and another called Computers, and move all user and computer accounts from the

Users and Computers containers into these respective OUs. Moving the objects to OUs allows you to apply Group Policy. You can also create your own OU model to meet your delegation and Group Policy application requirements. 2. Create another OU under the domain root called Data Admins. 3. In the Data Admins OU, create a Domain Local Security Group called domain_name Data Admins , for example, Contoso Data Admins. Members of this group are responsible for management of data in the Data OU. 4. Modify the existing permissions on the Data OU as follows: o Remove all permissions granted to Account Operators and Print Operators. o Add the following entry: Type Name Access Applies To Allow Data Admins Full Control This object and all child objects 5. Move the regular user account that you created for your domain administrator to the Data OU. 6. Add the account to the domain_name Data Admins security group. 7. If you later want to delegate data management to additional administrators, create their user accounts in the Data Admins OU and add their user accounts to the domain_name Data Admins security group. Separating Administrative and User Accounts for Administrative Users For each user who fills a service administrator role, create two accounts: one regular user account to be used for normal tasks and data administration, and one service administrative account to be used only for performing service administration tasks. The service administration account should not be mail enabled or used for running applications that are used every day, such as Microsoft Office, or for browsing the Internet. Always give the two accounts different passwords. These precautions reduce the exposure of the accounts to the outside world, and they reduce the amount of time that administrative accounts are logged on to the system. Assigning Trustworthy Personnel Service administrators control the configuration and functioning of the directory service. Therefore, this responsibility should be given only to reliable, trusted users who have demonstrated responsible ownership and who fully understand the operation of the directory. They should be completely familiar with your organization's policies regarding security and operations, and they should have demonstrated their willingness to enforce those policies. Limiting Administrator Rights to Those Rights That Are Actually Required Active Directory contains a Backup Operators built-in group. Members of this group are considered to be service administrators because members of the group have the privilege to log on locally and restore files, including the operating system files, on domain controllers.

Membership in the Backup Operators group in Active Directory should be limited to those individuals who back up and restore domain controllers. All member servers also contain a Backup Operators built-in group that is local to each server. Individuals who are responsible for backing up applications on a member server (for example, Microsoft SQL Server) should be made members of the local Backup Operators group on that server. These users should not be members of the Backup Operators group in Active Directory. On a server that is dedicated to the domain controller role, you can reduce the number of members in the Backup Operators group. If possible, domain controllers should be dedicated, but in smaller organizations a domain controller might be used to run other applications. In this case, users who are responsible for backing up applications on the domain controller must also be trusted as service administrators because they have the privileges that enable them to restore files, including the system files, on domain controllers. Avoid using the Account Operators group for strictly delegating a "data administration" task, such as account management. The default directory permissions give this group the ability to modify the computer accounts of domain controllers, including deleting them. By default, there are no members of the Account Operators group, and its membership should be left empty. Controlling the Administrative Logon Process The members of the Administrators, Enterprise Admins, and Domain Admins groups represent the most powerful accounts in your domain. To minimize security risks, you may want to take additional steps to enforce strong administrative credentials, such as requiring smart cards for administrative logon, or requiring two forms of identification, with each form held by a different administrator. These additional precautions are covered in "Best Practice Guide for Securing Active Directory Installations" (Windows Server 2003) on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22342. Securing Service Administrator Workstations In addition to limiting access to resources that are stored on the domain controllers and access to information that is stored in the directory, you can also enhance security by strictly controlling the workstations that are used by service administrators for administrative functions. Service administrators should only log on to well-managed computers, meaning that all security updates are applied and up to date virus software is installed. If you use service administrator credentials on a computer that is not well-managed, you run the risk of compromising the credentials if that computer has been breached by a malicious individual. For more information about how to restrict administrators to specific workstations and additional precautions, see "Best Practice Guide for Securing Active Directory Installations" (Windows Server 2003) on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22342. Understanding Data Delegation

In a small organization, it is likely that there are only one or two administrative users, so data delegation may not be needed. However, as your organization grows, you might want to designate data administrators and delegate portions of data administration to them. Data administrators are responsible for managing data that is stored in the directory and on computers that are members of the domain. Data administrators have no control over the configuration and delivery of the directory service itself; they control subsets of objects in the directory. Using permissions on objects that are stored in the directory, it is possible to limit the control of a given administrator account to very specific areas of the directory. Data administrators also manage computers (other than domain controllers) that are members of their domain. They manage local resources, such as print and file shares on local servers, and they also manage the group and user accounts for their own part of the organization. Data administrators can perform all of their responsibilities from management workstations, and they do not need physical access to domain controllers. Delegation of data administration is accomplished by creating groups, granting the appropriate user rights and permissions to those groups, and applying Group Policy settings to the members of those groups. After these steps are complete, delegation is a matter of adding user accounts to the groups that are created. The critical part of this operation is granting proper access and applying the proper policies, based on the principle of least privilege, to maximize security, while still allowing administrators to perform their delegated functions. For more information about delegating data administration, see "Best Practices for Delegating Active Directory Administration" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22707. Top Of Page

Related Information

For more information about securing Active Directory, see the following: Securing Windows Server 2003 Domain Controllers" in the Security Guidance Kit. Best Practice Guide for Securing Active Directory Installations" (Windows Server 2003) on the Microsoft Web site at /downloads/details.aspx?FamilyID=4e734065-3f18-488abe1e-f03390ec5f91&DisplayLang=en. "Best Practices for Delegating Active Directory Administration" on the Microsoft Web site at /technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/actdid1. mspx.

For more general information about builtin accounts and migrating from Microsoft Windows NT 4.0 to Active Directory, see the following:

"Default Groups" on the TechNet Web site at technet2.microsoft.com/windowsserver/en/library/1631acad-ef34-4f77-9c2e94a62f8846cf1033.mspx?mfr=true.

"Migrating from Windows NT Server 4.0 to Windows Server 2003" on the Microsoft Web site at /downloads/details.aspx?FamilyID=e92cf6a0-76f0-4e25-8de019544062a6e6&DisplayLang=en.