| Published: February 27, 2008 Organizations use Active Directory® Domain Services (AD DS) to manage domain users and resources, such as computers, printers, and applications on a network. AD DS in Windows Server® 2008 includes a number of new features that are not available in previous versions of Windows Server, and some of these features focus on deploying AD DS more securely. The role services available for the Active Directory Domain Services role, as displayed in the following figure, include: - AD DS Domain Controller. This role service installs by default with the AD DS role. It enables a server to store directory data and manages communication between users and domains, including user logon processes, authentication, and directory searches.
- Identity Management for UNIX. This role service integrates computers running Windows® in an existing UNIX environment. You can install the following optional sub-elements of this role service:
- Server for Network Information Services (NIS). This sub-element integrates Windows and NIS networks by exporting NIS domain maps to Directory Service entries. This allows an Active Directory domain controller to act as a master NIS server.
- Password Synchronization. This sub-element ensures that when a password changes in one environment (UNIX or Windows) it also changes in the other environment.
.gif)
Figure 3.1. Role services hierarchy for the AD DS role The Active Directory Domain Controller role service in Windows Server 2008 includes the following security-related enhancements that did not exist in previous versions of Windows Server: Note Although the Active Directory Domain Controller role service installs when you implement the AD DS role, the server is not considered to be a domain controller at this point. For this reason, many of the services associated with this role service are disabled. To use the Active Directory Domain Controller role service, you must promote the server to a domain controller using the Active Directory Domain Services Installation Wizard. The Active Directory Domain Controller role service is susceptible to the same security attacks as domain controllers running previous versions of Windows Server. To identify the attack surface for this role service, you need to identify the following: The details of the attack surface for the Active Directory Domain Controller role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this role service, on the AD DS tab of the workbook, view the sections that correspond to each of the items in the previous list. This section describes the security measures that you can incorporate into your Active Directory Domain Controller role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Active Directory Domain Controller role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included. The following table summarizes the recommended security configuration tasks for hardening servers performing the Active Directory Domain Controller role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations. Table 3.1. Configuration Checklist | | Configuration tasks | | | Deploy a Server Core installation of Windows Server 2008. | | | Deploy RODCs where physical security cannot be guaranteed. | | | Delegate local administration of RODCs. | | | Limit secure information stored on RODCs. | | | Combine the DNS role service and the Domain Controller role service. | | | Restrict administrator group members and administration scope. | | | Prevent service administrators from bypassing password policies. | | | Configure fine-grained password policies. | | | Require multifactor authentication for users with elevated privileges. | | | Manage service administrators in a controlled OU structure. | | | Manage group membership for service administrator accounts. | | | Encrypt data stored on local drives using BitLocker® Drive Encryption. | | | Backup BitLocker and TPM recovery information in Active Directory. | | | Protect the computer startup key using Syskey. | Deploy a Server Core Installation of Windows Server 2008 Deploying Windows Server 2008 using the Server Core installation option reduces the attack surface of the operating system by limiting the number of required files and services. The advantage of the Server Core option is that it does not install files and services required for the graphical user interface (GUI). When you use the Server Core installation option of Windows Server 2008 to deploy the operating system, you can only locally manage the server using command-line tools. To manage the server using GUI-based tools, you must install and run these tools on another computer with a Windows-based GUI. You can use the following command line management tools to install, uninstall, start, and stop the AD DS role: See the following resources for more information about the Server Core installation option and managing AD DS from a command line: Deploy RODCs Where Physical Security Cannot Be Guaranteed Because of their importance, Microsoft recommends to always store domain controllers in physically secure locations that are accessible only to qualified administrative staff. If your organization must store domain controllers in unsecured locations, such as branch offices, you can use read-only domain controllers (RODCs) in these situations. RODCs do not maintain copies of all account passwords locally, except for the RODC specific computer account and the RODC-specific Kerberos account. You can configure which account passwords are stored on an individual RODC by using the RODC-specific Password Replication Policy. Typically, most RODCs will cache a reduced set of account passwords locally, which result from the subset of those that are enabled for replication to a RODC and are accessed directly on that RODC. You can help ensure that other sensitive data does not replicate to them by using the RODC Filtered Attribute Set. RODCs do not allow externally initiated changes to be made to the AD DS database for the following reasons: - The AD DS database on the RODC is read-only.
- Only inbound replication is supported for all hosted partitions and the SYSVOL.
In this way, you can locate conventional domain controllers in secure data centers, and then establish a network communications path to the RODCs. However, it is also always important to bear in mind that any computer stored in a physically unsecured location represents a security risk to an organization. Note Although RODCs do not require the same security measures as writable domain controllers, implementing as many of the same security recommendations as you do for writable domain controllers will ensure the highest possible security. Delegate Local Administration of RODCs The Administrator Role Separation feature for an RODC allows any domain user or security group to be delegated as the local administrator of an RODC without granting that user or group any rights for the domain or other domain controllers. Accordingly, a delegated administrator can log on to a RODC to perform maintenance work on the server, such as upgrading a driver. However, the delegated administrator would not be able to log on to any other domain controller or perform any other administrative tasks in the domain. In this way, you can delegate a security group that comprises branch office users, rather than members of the Domain Admins group, the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain. Limit Secure Information Stored on RODCs Some applications that use AD DS as a data store may have credential-like data or attributes, such as passwords, credentials, or encryption keys, that you do not want to store on a RODC in case it is stolen or compromised. For this type of application, you can take the following steps to help prevent unnecessary exposure of such attributes: - Add each attribute to the RODC filtered attribute set to prevent them from replicating to RODCs in the forest.
- Mark each attribute as confidential, which removes the ability to read the data for members of the Authenticated Users group (including any RODCs).
For more information about how to limit the secure information stored on RODCs, see "RODC filtered attribute set" on the RODC Features page for Windows Server 2008. Combine the DNS Role Service and the Domain Controller Role Service Windows Server 2008 domain controllers require a stable, properly configured DNS service. You can integrate DNS zones into AD DS, which is the more secure option, because this option supports secure updates. For this reason, many organizations combine the Active Directory Domain Controller role service and the DNS role service on the same computer when the DNS role service is supporting Active Directory. However, Microsoft recommends to avoid combining the Active Directory Domain Controller role service with other server roles, except for the DNS role service that supports Active Directory. Running all other server roles on different servers minimizes the attack surface for the Active Directory Domain Controller role service. Restrict Administrator Group Members and Administration Scope Microsoft recommends limiting administrator access to the writable domain controllers in your organization to a restricted group of dedicated administrators, and separating administrative responsibilities to ensure that no one individual has too much control over Active Directory in your environment. Typically this involves subdividing administrative tasks and roles, and creating groups that correspond to those tasks and roles. Other administrative tasks that you can perform to increase the security of the Active Directory Domain Controller role service include the following: - Disable or delete unused user and computer accounts.
- Disable the Guest account.
- Rename the default administrator account, assign it a highly complex password, and then disable it by using a Group Policy object.
- Enforce password complexity rules.
- Disallow shared accounts.
Prevent Service Administrators from Bypassing Password Policies A user with elevated privileges who is able to create user objects or has the modify permission on the useraccountcontrol attribute can bypass password policies. For example, by default a member of the Domain Admins group can restore a password that has expired or can enable or disable the password not required extended right for user objects. You can help prevent this default behavior by configuring the following extended rights in Active Directory: - Enable-Per-User-Reversibly-Encrypted-Password. This extended control access right allows users to enable or disable the reversible encrypted password extended right for user and computer objects.
- Unexpire-Password. This extended control access right allows a user to restore an expired password for a user object.
- Update-Password-Not-Required-Bit. This extended control access right allows a user to enable or disable the password not required extended right for user objects.
For more information about configuring extended rights in Active Directory, see the following resources: Configure Fine-Grained Password Policies Windows Server 2008 allows you to specify multiple password policies within a single domain, which are also known as fine-grained password policies. This allows you to maintain a minimum level of password security throughout the domain, but also require more restrictive password policies for specific user and computer groups. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain. For example, you can apply more strict settings to privileged accounts and less strict settings to the accounts of other users. In other cases, you might want to apply a special password policy for accounts with passwords that synchronize with other data sources. Examples of this could include accounts used by UNIX computers that require less restrictive password policies. Specifically, configure more restrictive password policies for the following users: - Members of the Enterprise Admins security group.
- Members of the Domain Admins security group.
- Members of the Schema Admins security group.
- Members of the DHCP Admins security group.
- Members of the DNS Admins security group.
- Members of the Server Operators security group.
- Members of the Backup and Restore Operators security group.
- Members of the Administrators security group.
- Members of the Policy Administrators security group.
- Members of the Certificate Administrators security group.
- Members of the Cryptographic Administrators security group.
- Members of the Print Operators security group.
- Members of security groups with delegated administration permissions for AD DS, such as help desk personnel.
- Members of security groups with delegated administration permissions for applications that run on server computers, such as administrators of Microsoft Exchange Server or Microsoft SQL Server®.
Fine-grained password policies apply only to user objects, or inetOrgPerson objects if they are used instead of user objects, and global security groups. By default, only members of the Domain Admins group can create, configure and view fine-grained password policies. You can delegate the ability to create, configure, and view these policies to other users, but the domain functional level must be Windows Server 2008. However, Microsoft recommends that only members of the Domain Admins security group be able to create or configure fine-grained password policies. You can delegate the ability to view fine-grained password policies to users who require such delegation of administration, such as support or help desk staff. To grant these users the ability to view fine-grained password policies do the following: - Create a security group that contains the users who need to view the fine-grained password policies.
- Grant the security group created in Step 1 read access to the Password Settings Container (PSC).
The PSC is created by default under the System container in the domain. You can view it by using the Active Directory Users and Computers snap-in with Advanced features enabled. The PSC stores the Password Settings objects (PSOs) for the domain. There may be instances in which you want to delegate which fine-grained password policy is applied to a group of users, but not actually delegate the creation of the fine-grained password policies. To achieve this, Microsoft recommends to do the following: - Create a fine-grained password policy object with a very restrictive setting.
- Link the Domain Users security group to the fine-grained password policy object created in Step 1.
- For all other fine-grained password policy objects that you create, do the following:
- Create a fine-grained password policy object.
- Create a global security group.
- Link the global security group created in Step b to the fine-grained password policy object created in Step a.
- Delegate the administration of the global security group membership to users who will manage the users in the group, which subsequently delegates which fine-grained password policy is applied to the users who are members of the global security group.
You cannot apply a fine-grained password policy to an organizational unit (OU) directly. To apply a fine-grained password policy to the users in an OU, you can use a shadow group. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group, and then link the shadow group to the fine-grained password policy. You also can create additional shadow groups for other OUs. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups. Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional password restrictions. For more information about fine-grained password policies, see AD DS: Fine-Grained Password Policies. Require Multifactor Authentication for Users with Elevated Privileges Human authentication factors are generally classified into the following cases: - The user knows specific information, such as a password, pass phrase, or personal identification number (PIN).
- The user has a specific device, such as a smart card, security token, software token, phone, or cell phone.
- The user provides a human attribute through an action, such as a fingerprint or retinal pattern, DNA sequence, signature or voice recognition, unique bio-electric signals, or another biometric identifier.
Often organizations use a combination of these methods. For example, a debit card and a PIN, which is also known as two-factor authentication. You can use multifactor authentication to enhance the level of authentication in your organization, compared to only requiring users to provide a password. Multifactor authentication typically includes a physical device, such as a smart card reader, USB security token, or fingerprint reader. Selecting physical devices for multifactor authentication is based on nonsecurity related requirements. For example, your organization could require smart cards for users that include picture identification, as you can print a picture and a name on the smart card. However, a smart card requires a reader, which may introduce additional costs. A USB token can include flash memory for storing documents and files, and users can plug a USB token into existing USB ports on their computers. This form of security is recommended for accounts with elevated privileges. Specifically, Microsoft recommends requiring multifactor authentication for the following users: - Members of the Enterprise Admins security group.
- Members of the Domain Admins security group.
- Members of the Schema Admins security group.
- Members of the DHCP Admins security group.
- Members of the DNS Admins security group.
- Members of the Server Operators security group.
- Members of the Backup and Restore Operators security group.
- Members of the Administrators security group.
- Members of the Policy Administrators security group.
- Members of the Certificate Administrators security group.
- Members of the Cryptographic Administrators security group.
- Members of the Print Operators security group.
- Members of security groups with delegated administration permissions for AD DS, such as help desk personnel.
- Members of security groups with delegated administration permissions for applications that run on server computers, such as administrators of Exchange Server or SQL Server.
Note If possible, use multifactor authentication throughout the organization to ensure that the strongest possible passwords are required for user accounts. Using multifactor authentication causes the system to automatically generate cryptographically strong random passwords for accounts. Manage Service Administrators in a Controlled OU Structure Service administrators are responsible for the delivery of the directory service, directory-wide settings, installation and maintenance of software, and application of operating system service packs and fixes on domain controllers. To perform these functions, service administrators must have physical access to domain controllers. To help protect highly privileged service administrator accounts, allow only service administrators to manage service administrator accounts. Because such accounts have elevated privileges, data administrators should not be given the authority to modify these accounts. Doing so allows data administrators to elevate their privileges. Service administrator accounts should be accessed and managed in a highly-controlled subtree in each domain. To provide a more controlled environment that facilitates the management of service administrator accounts and workstations, create a controlled OU structure to manage service administrator accounts in Active Directory, as shown in the following figure. A member of the Domain Admins group should create a controlled OU structure for each domain, and configure each of the OUs with the recommended security settings. By creating an OU structure that contains all service administrator accounts and the administrative workstations that they use, you can apply controlled security and policy settings to the structure to maximize protection of the accounts and computers. The following figure displays an example of a controlled administrative OU structure and its access control settings. .gif)
Figure 3.2. Sample OU structure for managing service administrator accounts To create a controlled OU structure, perform the following steps: - Create the OU structure.
- Set the access control lists (ACLs) on the controlled OUs.
- Add service administrator groups to the controlled OU structure.
- Add service administrator user accounts to the controlled OU structure.
- Add the computer accounts for the administrator workstations to the controlled OU structure.
- Protect service administrator groups outside the controlled OU structure.
Step 1: Create the OU Structure Create a high-level OU to hold the groups and user accounts that constitute your service administrators and their workstations. Within this OU, create another OU to hold administrative user and group accounts, and another OU to hold administrative workstations. The previous figure depicts a recommended OU hierarchy for a controlled subtree to manage service administrator accounts and workstations. It consists of a controlled OU structure rooted at the Service Admins OU that contains two additional OUs: the Users and Groups OU, to hold the administrative user and group accounts, and the Administrative Workstations OU, to hold the computer accounts of the workstations that the service administrators use. Step 2: Set the ACLs on the Controlled OUs Depending on the rest of our OU structure, users with delegated administration permissions might inadvertently have permissions to administer the users in the controlled OUs. You need to change the ACLs on the controlled OUs so that only specific service administrators can administer the membership of service administrator users, groups, and workstations. This prevents the controlled OUs from inadvertently inheriting permission configuration changes in GPO settings that are higher in the OU structure. To limit access to the controlled OUs, do the following: - Block inheritance of permissions on the Service Admins OU so that changes made to GPO settings higher in the OU structure cannot be inherited in the lower structure to alter locked-down settings.
- Set the ACL on the Service Administrators OU, as indicated in the following table.
Table 3.2. ACL Settings for the Service Administrators OU | Type | Name | Access | Applies to | | Allow | Enterprise Admins | Full Control | This object and all child objects. | | Allow | Domain Admins | Full Control | This object and all child objects. | | Allow | Administrators | Full Control | This object and all child objects. | | Allow | Pre-Windows 2000 Compatible Access | List Contents Read All Properties Read Permissions | User objects. | Step 3: Add Service Administrator Groups to the Controlled OU Structure Move the following service administrator groups from their current location in the directory into the Users and Groups OU in your controlled OU structure: - Domain Admins
- Enterprise Admins (if this is the root domain of the forest)
- Schema Admins (if this is the root domain of the forest)
For complete protection of service administrator groups, it would be ideal to move the built-in groups, which include Administrators, Server Operators, Account Operators, and Backup Operators to the controlled OU structure. However, you cannot move built-in groups from their default container. Step 6 explains how to protect the accounts of members who belong to these groups. Step 4: Add Service Administrator User Accounts to the Controlled OU Structure Move all administrative user accounts that are members of any of the service administrator groups listed in step 3 from their current locations in the directory into the Users and Groups OU in your controlled OU structure. Be certain to move the built-in domain Administrator account as part of this process. Microsoft recommends providing each service administrator with two accounts: one for administrative duties, and one for their normal user access. Place the administrative user accounts in the Users and Groups OU in your controlled OU structure. If these accounts already exist elsewhere in the directory, move them into the OU structure as part of this step. Do not place the regular user accounts for these administrators in this controlled OU structure. Step 5: Add the Computer Accounts for the Administrator Workstations to the Controlled OU Structure Designate administrator computers as administrative workstations. Move the computer accounts for these workstations into the Administrative Workstations OU in your controlled OU structure. 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 domain controller accounts will disrupt the consistent application of domain controller policies to all domains in your environment. Step 6: Protect Service Administrator Groups Outside the Controlled OU Structure Some built-in service administrator accounts are protected by special default security descriptor settings that are applied when you install Active Directory. However, these settings do not protect the groups for Server Operators, Backup Operators, and Account Operators. Also, because these are built-in accounts, you cannot move them to the controlled OU structure to protect them. To protect these three groups, apply the same default ACL that you used to protect the other service administrator accounts, as listed in the previous table. Manage Group Membership for Service Administrator Accounts To enhance security, limit the membership in each of the service administrator groups to the absolute minimum that your organizational logistics allow, while preserving your ability to manage Active Directory service functions. This reduces the number of possible administrative accounts an attacker can possibly compromise. The following sections explain some recommended practices for managing the membership of the service administrator groups. Assign Trustworthy Personnel Assign only trustworthy personnel with service administrator control of the configuration and the directory service. This responsibility should only be entrusted to reliable, trusted users who have demonstrated responsible ownership, and who fully understand how to maintain the directory. These administrators should be completely familiar with your organization’s security and operations policies, and they should have demonstrated their willingness to enforce them. Restrict Service Group Membership to Users in the Forest Microsoft recommends not including users or groups from another forest as members of service administrator groups, unless you completely trust the service administrators of the other forest. Because service administrators in the other forest have full control on the user accounts in that forest, they can easily impersonate or authenticate to your forest using the credentials of one of those users. Furthermore, trusting the remote domain (or forest) in this way also places your trust in the remote domain's security measures, which is something that you cannot control. Note If you determine that you need to establish a trust with another forest, implement security identifier (SID) filtering between the forests. SID filtering is enabled on external trusts by default, but is not enabled on forest trusts. This prevents the administrator of one forest (Forest A) from gaining elevated permissions in the other forest (Forest B) by injecting the SID of the Domain Admins security group in Forest A into the sidhistory attribute of his account in Forest B. If it is necessary for an administrator from another forest to act as a service administrator in your domain, create an account in your domain that the administrator can use to perform administrative tasks. Creating such an account eliminates your dependence on the security measures of the other forest. Limit the Schema Admins Group to Temporary Members The Schema Admins group is a special group in the forest root domain that provides administrative access to the Active Directory schema. Members of this group have the necessary user rights to make changes to the schema. In general, because schema changes are only made rarely, it is not necessary for a schema administrator to be available at all times. This account is only needed when a schema update must be processed or if a change must be made to the configuration of the schema operations master role holder. To minimize the possibility of an Active Directory attack through a schema administrator account, Microsoft recommends keeping the membership of the Schema Admins group empty. Add a trusted user to the group only when an administrative task must be performed on the schema. Remove the member after the task is completed. Limit Administrator Rights to Those Rights That Are Actually Required Active Directory contains a built-in group named Backup Operators. Members of this group are considered service administrators, because the group’s members have the privilege to log on locally and restore files, including the system files, on domain controllers. Microsoft recommends to limit membership in the Backup Operators group in Active Directory to only those individuals who back up and restore domain controllers. All member servers also contain a built-in group called Backup Operators that is local to each server. Microsoft recommends to make individuals who are responsible for backing up applications, such as SQL Server on a member server, members of the local Backup Operators group on that server, instead of making them members of the Backup Operators group in Active Directory. Limit the membership of the Backup Operators Group in Active Directory to those individuals who backup and restore domain controllers. On a dedicated domain controller, you can reduce the number of members in the Backup Operators group. When a domain controller is used to run other applications, as it might be in a branch office, individuals who are responsible for backing up applications on the domain controller must also be trusted as service administrators. This is because they require privileges necessary to restore files, including system files, on domain controllers. Avoid using the Account Operators group to strictly delegate "data administration" tasks, such as account management. Because the default directory permissions give this group the ability to modify the membership of other service administrator groups, such as Server Operators, members of the Account Operators group can elevate their privileges to become service administrators. By default, there are no members in the Account Operators group, and its membership should be left empty. Microsoft recommends creating custom security groups and assigning these groups necessary rights and permissions instead of using built-in groups. This is because the existing built-in groups are typically assigned more rights and permissions than necessary to perform a specified role. Creating custom groups allows you to assign only the rights and permissions that are necessary for an individual to perform a specific role in your organization. For example, you could create a new security group called Help Desk Staff and then assign this security group only the necessary rights and permissions that members who belong to it require to perform their role. Encrypt Data on Local Drives Using BitLocker Drive Encryption BitLocker Drive Encryption is a data protection feature available in the Windows Vista® Enterprise and Windows Vista® Ultimate operating systems for client computers, and in Windows Server 2008. BitLocker provides enhanced protection against data theft or exposure on computers that are lost or stolen, and more secure data deletion when BitLocker-protected computers are decommissioned. Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. BitLocker helps mitigate unauthorized data access on lost or stolen computers by combining two major data-protection procedures: - Encrypting the entire Windows operating system volume and data volumes on the hard disk. BitLocker encrypts all user files and system files in the operating system volume, including the swap and hibernation files, and can also encrypt data volumes.
- Checking the integrity of early boot components and boot configuration data. On computers that have Trusted Platform Module (TPM) version 1.2, BitLocker leverages the enhanced security capabilities of the TPM to help ensure that your data is accessible only if the computer’s boot components appear unaltered and the encrypted disk is located in the original computer.
Because a writable domain controller contains all domain account passwords, X.509 certificates, and other security-related information, encrypting the volumes by using BitLocker provides additional protection in the event that a domain controller, or a domain controller hard drive, is stolen. RODCs contain a subset of this information, but Microsoft still recommends encrypting the volumes by using BitLocker. For more information about configuring BitLocker for Windows Server 2008, see the BitLocker Drive Encryption. Note Secure the BitLocker volume master keys by using TPM and a startup key or TPM and a PIN on domain controllers. Do not use TPM only as a method for securing the volume master keys for domain controllers. For more information about best practices for using BitLocker, see the following resources: Backup BitLocker and TPM Recovery Information in Active Directory During installation, a recovery password is created for each BitLocker-enabled volume. If you also use TPM, you also must specify the TPM owner password. You can store the recovery information required for these technologies in AD DS. Backing up recovery passwords for a BitLocker-protected disk volume allows administrators to recover the volume if it is locked. This ensures that authorized users always can access encrypted data belonging to the enterprise. Note This method for backing up recovery passwords assumes you have more than one domain controller in your organization. If you have only one domain controller, then also copy the recovery passwords to removable media. Backing up the TPM owner information for a computer allows administrators to locally and remotely configure the TPM security hardware on that computer. As an example, an administrator might want to reset the TPM to factory defaults when decommissioning or repurposing computers. For more information about how to configure AD DS to back up BitLocker and TPM recovery information, see Configuring Active Directory. Protect the Computer Startup Key Using Syskey In secure datacenter environments, generally only authorized personnel can restart domain controllers. However, in an environment where you cannot strictly enforce these recommendations, such as in branch offices, there is increased potential for an unauthorized person to restart a domain controller. An unplanned or unexpected restart of a domain controller can indicate that an attacker has started the domain controller with an alternate operating system and compromised its security. On the other hand, the restart might simply be due to a loss of power or to scheduled maintenance on the domain controller. The following sections include SYSKEY methods, dependencies, and considerations that you can use to determine how best to use SYSKEY in your environment. Determining if SYSKEY Is Appropriate for Your Environment The system key (SYSKEY) in Windows operating systems protects security information, including passwords in the Active Directory database and other Local Security Authority (LSA) secrets, against offline attacks by encrypting their storage on the domain controller. SYSKEY can either be derived from a secret password that you specify, or you can store it on removable media, such as a floppy disk or USB drive. Note SYSKEY protects only the security information in Active Directory or other LSA secrets. BitLocker protects all data stored on BitLocker-encrypted volumes. In instances where encrypting the entire volume is inappropriate, use SYSKEY to protect Active Directory information and LSA secrets. When starting a domain controller protected by this method, you must either supply the password or the removable media containing SYSKEY to successfully restart the computer. You can use the system key utility (Syskey.exe), which installs on the domain controller with Windows Server 2008, to select which of these methods you want to use to start the computer. Implementing SYSKEY provides the following security advantages: - Point-in-time control of the domain controller restart, which evaluates the reason for the domain controller restart, and determines if security has been compromised.
- Protection for passwords stored in the directory database against offline attacks if the domain controller or a disk is stolen.
There are certain logistic operational issues with SYSKEY. The first of these is the management of SYSKEY passwords or removable media. For example, requiring a branch manager or local administrative staff to come to the office at 3 A.M. to enter passwords or insert removable media might be problematic. To help mitigate this problem, you can allow centralized IT operations personnel to provide the SYSKEY password remotely, which requires additional hardware to support remote management. These remote methods allow the IT operations personnel to type the password or mount virtual images of the floppy containing the SYSKEY. The other potential logistical problem is that losing the SYSKEY password or removable media leaves the domain controller in a state in which no one can restart it. There is no way to recover a domain controller if the SYSKEY password or floppy disk is lost. In this situation, it would be necessary to rebuild the domain controller. Each method has advantages and potential difficulties. If you choose to add SYSKEY protection to your domain controllers, first evaluate your security environment to determine which method will work best for your organization. Providing SYSKEY Passwords for Domain Controller Restarts The advantage of providing SYSKEY passwords is that they do not require physical media that can be lost. Trusted personnel must type a password at a console connected to the domain controller in the event that it needs to be restarted. The password should be known to only a small group of trusted administrators, preferably only members of the Domain Admins group. The disadvantages of using a password to secure SYSKEY are that trusted personnel are required to memorize another password and they must be on site to use the password. To support branch offices, you may need to provide the SYSKEY password remotely through central IT trusted personnel. However, this requires using additional hardware to support remote management. Because attackers can compromise passwords, Microsoft recommends to increase the security of passwords for SYSKEY restarts by doing the following: - Use strong passwords.
- Store the passwords in a secure place, such as a bank safety deposit box.
- Require SYSKEY passwords to be periodically changed.
Providing SYSKEY on Removable Media for Domain Controller Restarts The advantage of providing SYSKEY on removable media is that it does not require trusted personnel to memorize a password. However, implementing SYSKEY with removable media does introduce the risk of lost or damaged physical media. Furthermore, trusted personnel are required to insert the removable media during domain controller restarts. Again, only trusted personnel, preferably members of the Domain Admins group, should have access to the SYSKEY removable media. To support branch offices, you may need to install third-party hardware devices to support remote management, so that floppy disk images can be remotely transferred to the domain controller. Using these devices, central IT trusted personnel can transfer a copy of the SYSKEY disk image to a remote domain controller. After the domain controller restarts, IT operations personnel can delete the remote image of the SYSKEY floppy disk. Because the removable media contains the cryptographic key for SYSKEY, you should take measures to ensure that the removable media is not stolen, lost, destroyed, or copied by an unauthorized person. Microsoft recommends the following measures to mitigate these risks: - Copy the removable media and store the copy at an off-site location, such as in a bank safe deposit box.
- Store the working copy of the removable media in a secure place on site.
- Remove the removable media from the domain controller immediately after it restarts.
The Domain Controller Baseline Policy (DCBP) that complements the Default Domain Controller Policy is linked to the Domain Controllers organizational unit (OU). The DCBP settings enhance overall security for domain controllers in any environment. Using only two GPOs to secure domain controllers allows the default environment to be preserved and simplifies troubleshooting. For more information about these settings, see the following resources: - "Appendix A: Security Group Policy Settings" that accompanies this guide.
- The Windows Server 2008 Security Guide Settings workbook that accompanies this guide.
The following resource provides further security best practice information about how to harden servers running the Active Directory Domain Controller role service: With the Identity Management for UNIX role service, you can authenticate credentials in Active Directory using the Network Information Services (NIS) protocol, and you can synchronize account passwords stored in Active Directory with account passwords stored in NIS servers running UNIX. The Identity Management for UNIX role service comprises the following sub-element role services: - Server for Network Information Services
- Password Synchronization
Each of these sub-element role services are discussed in subsequent sections. For more information about the Identity Management for UNIX role service, see the "Overview of Identity Management for UNIX" in the Help and Support for Windows Server 2008. The Server for NIS sub-element integrates Microsoft Windows® and NIS networks by providing a Windows–based AD DS domain controller with the ability to act as a master NIS server for one or more NIS domains. Server for NIS stores both standard and nonstandard NIS map data in AD DS, and creates a single name space for the Windows and NIS domains that a Windows administrator can manage using a single set of tools. The administrator can easily create, modify, and delete user accounts for Windows and NIS-enabled UNIX domains at the same time. A user who has accounts in both Windows and UNIX environments can be managed by AD DS with all of the attributes necessary for the respective domain and name space. Server for NIS is typically used in conjunction with Server for Network File System (NFS). NFS provides shared network file services for NFS clients, which are typically found on computers running UNIX. For more information about the Network Information Services role service, see the "Server for NIS" section in the Help and Support for Windows Server 2008. The Server for Network Information Services (NIS) role service is susceptible to the same security attacks as any NIS server. To identify the attack surface for this role service, you need to identify the following: The details of the attack surface for the Server for NIS role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this server role, on the AD DS tab of the workbook, view the sections that correspond to each of the items in the previous list. This section describes the security measures that you can incorporate into your Server for NIS role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Server for Network Information Services role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included. The following table summarizes the recommended security configuration tasks to harden servers that perform the Server for NIS role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations. Table 3.3. Configuration Checklist | | Configuration tasks | | | Configure the computer to run Server for NIS in master mode. | | | Require users to change their Windows passwords. | Note The Server for Network Information Services role service is not available on Server Core installations of Windows Server 2008. Configure the Computer to Run Server for NIS in Master Mode To operate Network Information Services (NIS), a computer can run these services in master mode or subordinate mode. The primary difference between the two modes is that both subordinate and master servers can read map data, while only the master server can update maps. In addition, the master NIS server provides periodic updates of the maps to subordinate servers. Configure one of the computers running Server for NIS to be the master NIS server. This ensures that the Windows-based master NIS server will receive updates from the other NIS servers running in subordinate mode. Because the data is stored in Active Directory, the security for the data is stronger than is typically available by storing it in a file on UNIX. For more information about master mode, subordinate mode, and the interaction between computers running these modes, see "Master and subordinate server modes" in the Help and Support for Windows Server 2008. Require Users to Change Their Windows Passwords Typically, users running UNIX or LINUX operating systems change their NIS passwords by running the yppasswd command. This command is used to update the user's password in NIS. The yppasswd command sends the old password to the NIS server in plaintext. For this reason, this command might expose the user's Windows password. Instead of using this command, users should change their NIS password by changing their Windows passwords. The server running Network Information Services will then synchronize the password change with the subordinate NIS servers. There are no Group Policy settings available for the Server for NIS role service. The following resource provides further security best practice information about how to harden server computers running the Server for NIS role service: - "Server for NIS" in the Help and Support for Windows Server 2008.
The Password Synchronization role service helps you integrate Windows and UNIX networks by simplifying the process of maintaining secure passwords in both environments. This reduces the effort required to maintain separate passwords for Windows and UNIX accounts and change the password in both systems. With the Password Synchronization role service, whenever users change their passwords on a Windows-based computer in a domain, the passwords are automatically changed on every UNIX host on which the users have an account. You also can configure the Password Synchronization role service to change Windows-based user passwords automatically whenever users change their UNIX passwords. For more information about the Password Synchronization role service, see "Password Synchronization" in the Help and Support for Windows Server 2008. The Password Synchronization role service is susceptible to the same security attacks as any AD DS domain controller. To identify the attack surface for this role service, you need to identify the following: The details of the attack surface for the Password Synchronization role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this server role, on the AD DS tab of the workbook, view the sections that correspond to each of the items in the previous list. This section describes the security measures that you can incorporate into your Password Synchronization role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Password Synchronization role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included. The following table summarizes the recommended security configuration tasks for hardening servers that perform the Password Synchronization role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations. Table 3.4. Configuration Checklist | | Configuration tasks | | | Ensure the Windows and UNIX password policies are consistent. | | | Specify a computer-specific password encryption key. | | | Explicitly list users allowed or blocked from password synchronization. | | | Block password synchronization of disabled UNIX user accounts. | | | Avoid synchronizing passwords for user accounts with elevated privileges. | | | Do not use the default port number and encryption key. | | | Secure the sso.conf file. | | | Ensure that the directory identified by TEMP_FILE_PATH on the UNIX host is properly protected. | | | Ensure that log files are appropriately protected on the UNIX host. | Note The Password Synchronization role service is not available on Server Core installations of Windows Server 2008. Ensure the Windows and UNIX Password Policies Are Consistent If you are providing only one-way password synchronization, ensure that the password policy on the computer from which passwords will be synchronized is at least as restrictive as the policy on the computer to which it will synchronize passwords. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it will synchronize passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent can result in synchronization failure when a user changes a password on the less restrictive system, or the password might be changed on the more restrictive system even though it does not conform to the system's policies. Also ensure that Windows users are aware of any special password restrictions on UNIX systems with which they will synchronize their passwords. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, limit passwords to seven or eight characters in length unless you are sure that all of the UNIX systems in your environment can support longer passwords. Specify a Computer-Specific Password Encryption Key A Windows-based computer can send and receive updated passwords from a UNIX-based computer as encrypted text only. The Password Synchronization single sign-on daemon (SSOD) receives the encrypted password and decrypts it before requesting the password change on the UNIX host. Similarly, if you configure Password Synchronization to support UNIX-to-Windows synchronization, the pluggable authentication module (PAM) encrypts the password before sending it to Password Synchronization on the Windows-based computer, which then decrypts the password before requesting the password change on the Windows-based computer. For added security, you can specify an encryption key for use only between a specific Windows-based computer and a UNIX host. This helps ensure that only specific computers can decrypt passwords from each other. For more information, see Set computer-specific synchronization properties. Explicitly List Users Allowed or Blocked From Password Synchronization To provide maximum control over which users can synchronize passwords, do not use the ALL keyword with the SYNC_USERS list in the sso.conf file on the UNIX host. Instead, explicitly list each user who you want to allow or block from password synchronization. On the Windows-based computer running Password Synchronization, create the PasswordPropAllow group, and then add the accounts of users whose passwords you want to synchronize to this group. For more information about this topic, see Controlling password synchronization for user accounts. Block Password Synchronization of Disabled UNIX Accounts In some versions of UNIX, changing the password of a disabled user account activates that account. Consequently, if a user has a disabled account on a UNIX computer that is configured to synchronize passwords with a Windows-based computer, the user or an administrator can activate the UNIX account by changing the user's Windows password. To prevent this, use the PasswordPropDeny group to block synchronization for disabled UNIX accounts. Also, when you disable a UNIX account, ensure that you use the SYNC_USERS entry in the sso.conf file to block password synchronization for the account. Avoid Synchronizing Passwords for User Accounts with Elevated Privileges Do not synchronize passwords for members of Windows groups with elevated privileges or the owners of the UNIX superuser or root accounts, because these accounts do not have elevated permissions on the other system. For example, members of the Domain Admins group have no elevated permissions on computers running UNIX by default. Do Not Use the Default Port Number and Encryption Key If you use the default port number and encryption key, you make it possible for an attacker to set up an impostor UNIX host to capture passwords. To help prevent imposter UNIX hosts from capturing passwords, change the value of the port and the default password encryption key used by password synchronization. Note Protect the port number and encryption keys that you use to synchronize passwords as carefully as the passwords themselves. For more information about these topics, see the following sections in the Help and Support for Windows Server 2008: - "Setting the default port."
- "Setting the password encryption key."
Secure the sso.conf File The sso.conf file on each UNIX host contains important configuration information that an attacker could use to compromise security. Microsoft recommends setting the mode bit mask of this file to 600 to better secure it. Ensure That the Directory Identified by TEMP_FILE_PATH on the UNIX Host is Properly Protected The temporary files created on UNIX hosts by Password Synchronization contain information that an attacker could use to compromise system security. For this reason, ensure that any directory referenced by TEMP_FILE_PATH in the sso.conf file has read access only for the root account, and that no other users access this account. Ensure That Log Files are Appropriately Protected On the UNIX Host Password Synchronization uses the syslogd daemon to log messages that result from synchronization operations. The resulting logs contain such information as the names of users whose passwords are synchronized with which computers, propagation errors, and so on. Ensure that only the root account can read the log files and that no other users can access the files by granting only the root account access to the directory where the logs files are stored. Check the configuration of the syslogd daemon to determine the directory where the log files are stored. There are no Group Policy settings available for the Password Synchronization role service. The following resources on Microsoft.com provide further security best practice information about how to harden server computers: - For computers running the Active Directory Domain Controller role service, see:
- For information about the Server for Network Information Services (NIS) role service, see:
- "Server for NIS" in the Help and Support for Windows Server 2008.
- For information about the Password Synchronization role service, see:
|