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.
or
dcpromo /unattend /option1=”value1” /option2=”value2” /option=…”
Where unattendfile is the name of a Dcpromo.exe unattend file. You must install the AD DS role using an unattend file because the Dcpromo.exe graphical wizard is not supported.
To start the Active Directory Domain Services service, run the following command:
net start "Active Directory Domain Services"
To stop the Active Directory Domain Services service, run the following command:
net stop "Active Directory Domain Services"
See the following resources for more information about the Server Core installation option and managing AD DS from a command line:
Managing Active Directory From the Command Line.
Server Core.
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 avoiding 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.
Avoid Combining the Domain Controller Role Service with Other Role Services
Although it is possible to install other role services on computers with the Active Directory Domain Controller role service, Microsoft recommends avoiding this whenever possible. This is because combining roles in this way can cause undesirable situations to arise. For example, users with accounts in Active Directory Directory Services (AD DS) may have too much access to data associated with other role service or conversely, users accessing the network services provided by the other role service may have inappropriate access to information stored in AD DS. Installing certain role services with the Active Directory Domain Controller role service can be particularly risky, such as the Routing and Remote Access role service or those available with Active Directory Certificate Services.
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. For RODCs, you can implement Administrator Role Separation (ARS), as shown on the RODC Administration page on TechNet.
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:
Appendix D: Active Directory Extended Rights.
Best Practices for Delegating Active Directory.
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 doing 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.
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.
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.
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.
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.
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.
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.
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 limiting membership in the Backup Operators group in Active Directory to only those individuals who backup and restore domain controllers.
All member servers also contain a built-in group called Backup Operators that is local to each server. Microsoft recommends making 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 Step-by-Step Guide.
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:
BitLocker Drive Encryption.
IT Showcase: Optimizing Client Security by Using Windows Vista.
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 BitLocker Drive Encryption Configuration Guide.
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 increasing 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.
Relevant Group Policy Settings
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 Windows Server 2008 Security Baseline Settings workbook.
