Securing Windows Server 2008 in the Branch Office

11 Aug

Windows Server 2008 has introduced several significant enhancements to improve security in
installations like the branch office. The most important new additions are the following:
■ The Server Core server
■ The read-only domain controller (RODC)
■ The Password Settings Object (PSO)
■ Network Access Protection
■ Administrator Role Separation
Lesson 2: Branch Office Server Security 313
Server Core and Administrator Role Separation were covered in detail in Lesson 1, “Branch Office
Deployment,” and NAP is covered in Chapter 5, “Designing a Network Access Strategy.” The
RODC and the setting of fine-grained password policies with the PSO remain to be discussed.
The Read-Only Domain Controller
A new security-related feature in Windows Server 2008 is the RODC. It is designed for implementation
in environments where:
■ There is a need for local access to Active Directory by users, computers, applications, or
other entities.
■ The physical security of the server cannot be guaranteed.
■ The server might be exposed to a hazardous network environment, such as an extranet.
■ There are relatively few users.
■ WAN link connectivity to the main network might be unreliable.
■ Local technical support skills might be limited.
As you review that list, you will undoubtedly realize that it sounds like a branch office environment.
The RODC differs from the full DC in the following ways. The RODC:
■ Holds a read-only copy of the Active Directory database.
■ Participates in only one-way replication of all replication partitions, including domain
data from a Windows Server 2008 DC.
■ Participates in only one-way replication of schema, configuration, and application directory
partitions, and the global catalog from a Windows Server 2003 DC but not the
domain partition.
■ Does not receive user or computer credentials (passwords) from Active Directory, by
default.
■ Can cache only selected user and computer credentials for accounts specified in a Password
Replication Policy.
■ Supports the removal of specified sensitive attributes from replication through the
RODC filtered attribute set.
■ Supports Administrator Role Separation.
■ Supports a read-only instance of the DNS zones.
RODC Disadvantages Because of the read-only nature of the RODC, it cannot be used as an
operations master or a replication bridgehead server. In addition, if Active Directory–aware
applications need to write data to Active Directory, the RODC cannot accept those write commands
and the application’s process will fail. Microsoft Exchange Server is an example of this
type of application. An Active Directory write process fails if the request is sent to an RODC.
Active Directory–aware applications should be tested with the RODC prior to deployment into
production.
314 Chapter 6 Design a Branch Office Deployment
The RODC might fail to authenticate smart card logons by default. For any DC to be able to
authenticate smart card logons, the DC must receive a domain controller X.509 digital certificate
from a trusted certification authority. These digital certificates are typically distributed to
the DCs through certificate autoenrollment. The permissions on the certificate template must
be modified to allow the RODC to receive this certificate.
The RODC does not advertise properly as a time source, causing the clocks on the branch
office client computers to become desynchronized. The simple solution is to configure a
Windows Server 2008 full DC server as the PDC emulator operations master for the domain,
making it the time master for the domain. Another solution is to manually configure a time
master for the domain.
Installing an RODC You need to take a few steps before you can install the first RODC in a
domain:
1. Ensure that the forest functional level is Windows Server 2003 or higher. Remember that
this means you must purge the forest of any Windows NT Server 4.0 and Windows 2000
Server DCs.
2. Run ADPrep/RODCPrep. This can only be done on the Schema Operations master for
the forest and only by a member of the Enterprise Admins group. This step is not
required if this is a new Windows Server 2008 forest. Copy the contents of the
\sources\adprep folder to the schema master DC, and execute the command from there.
3. Install a Windows Server 2008 DC into the domain. This DC is the replication source for
the RODC. The Windows Server 2008 DC must hold the PDC emulator operations master
role and be located in the site nearest the site of the RODC, based on site link cost.
Then you can install the RODC on a Windows Server 2008 server. You can install the RODC
on a Windows Server 2008 full installation server or on a Windows Server 2008 Server Core
installation server. Installing the RODC on the Server Core server provides the greatest level of
security because of the hardened server nature of the Server Core server.
Delegated Installation of the RODC The RODC computer object can be created in, or
moved to, the DC OU during the installation of the RODC, but this will require membership
in the Domain Admins group in the domain for the installer. However, this level of privilege is
often not desirable for users in the remote office.
Because the RODC is often located in a remote office with a nondomain administrator user as
the installer, it is possible to pre-create the RODC account in the Domain Controllers OU in
Active Directory Users and Computers and delegate authority to the remote, nondomain administrator
installer who completes the DCPromo installation. Furthermore, you can specify details
about the DCPromo installation that get stored on this unoccupied domain controller account
object. These details get pushed down to the remote RODC during the DCPromo installation.
Lesson 2: Branch Office Server Security 315
In Active Directory Users And Computers, on the Domain Controllers OU, right-click and
select the Pre-Create Read-Only Domain Controller Account option, as shown in Figure 6-4.
You now see the Active Directory Domain Services Installation Wizard.
Figure 6-4 The delegated RODC installation
To see all configurable options for the RODC, on the Welcome page, select the Use Advanced
Mode Installation check box. After a few standard DCPromo pages, such as the Network Credentials
page, you are prompted to define information, such as the necessary credentials to
pre-create the domain controller account, computer name, site location, and whether you
want to configure the RODC to host services such as DNS or the global catalog. You can next
specify the Password Replication Policy for the RODC server, as shown in Figure 6-5.
This policy defines the list of passwords that can be replicated to, and cached on, the RODC.
This Password Replication Policy will be explained in more detail later in this lesson. The
Active Directory Domain Services Installation Wizard next prompts you to specify which user
or group of users are delegated the authority to run the DCPromo process on the Windows
Server 2008 server in the remote office, as shown in Figure 6-6. The delegated users do not
require any additional privileges to complete the installation.
The recommendation for granting privilege, including the privilege to install an RODC, as
always, is to follow A-G-DL-P. Place user accounts into global groups, place global groups into
domain local groups, and then grant the necessary privileges to the domain local group. The
Summary dialog box has an Export button to generate an answer file for use in other similar
unattended installations.
316 Chapter 6 Design a Branch Office Deployment
Figure 6-5 Specifying the Password Replication Policy for the RODC installation
Figure 6-6 Specifying the nonadministrator installer of the remote RODC
Lesson 2: Branch Office Server Security 317
Installing the RODC from Customized Media As you probably recall from Windows
Server 2003, the DCPromo utility could be executed using the /ADV switch. This allowed the
remote DC to acquire the Active Directory database (NTDS.dit) from a system state data
backup copy of a DC in the same domain. This feature has been replaced in Windows Server
2008 with what is called Install From Media (IFM). By using the NTDSUTIL.exe utility with
the IFM subcommand, you can create a copy of the NTDS.dit database and remove “cached
secrets”—that is, passwords that you do not want to cache on the RODC server.
The RODC installation methods that can use the custom IFM media with passwords removed
from the Active Directory database include the following:
■ The Active Directory Installation Wizard (DCPromo.exe) where the media can be specified
■ From the command line using DCPromo/ReplicationSourcePath
■ Within an Answer file
The RODC Authentication Process In Windows Server 2008, the authentication processes
have been changed in environments like a branch office where the only DC is an RODC. When
a member computer boots up or when a user attempts to log on to a domain account, the
request is sent to the local DC—in this case, it is an RODC. The RODC does not cache user or
computer credentials by default. The RODC, acting as a relay agent, will then refer the authentication
request across the WAN link to a Windows Server 2008 full (writable) DC in the nearest
site. This can be slow and will fail the authentication process if the WAN link is down.
To improve performance and reliability, an administrator can create a Password Replication
Policy that will replicate the passwords of the users and computers in the remote branch office
to the branch office RODC. Now when a member computer boots up or when a user attempts
to log on to a domain account, the local RODC can complete the authentication process within
the local branch office. A different Password Replication Policy can be created for each RODC.
If a member computer boots up or a user attempts to log on to a domain account and the local
RODC does not have its credentials cached, after the authentication process completes
through the referral process, the RODC will request that the writable DC replicate the credentials
to the RODC for caching. If the account (user or computer) is on the Allowed list of the
Password Replication Policy for that RODC, the credentials are replicated from the writable
DC to the database of the RODC in the branch office.
If the account is not on the Allowed List of the Password Replication Policy for that RODC, the
credentials are not replicated from the writable DC to the RODC, and the authentication process
will need to be completed over the WAN link through the referral process every time.
318 Chapter 6 Design a Branch Office Deployment
The Password Replication Policy maintains four lists. They are:
■ Allowed List These passwords (secrets or credentials) can be replicated to the RODC.
■ Denied List These passwords (secrets or credentials) cannot be replicated to the RODC.
■ Revealed List A list of accounts whose passwords are cached on RODCs. This list can be
used to reset passwords of accounts on RODC servers that become compromised.
■ Authenticated List A list of accounts that have been successfully authenticated against
the RODC.
You can view these lists in Active Directory Users and Computers by displaying the properties
of the RODC server’s computer object. In the Password Replication Policy tab, you can see the
allowed and denied entities by examining the Setting column, as shown in Figure 6-7.
Figure 6-7 Accessing the Allowed and Denied Lists on the RODC
Click the Advanced button to access the Revealed and Authenticated Lists, as shown in Figure 6-8.
Lesson 2: Branch Office Server Security 319
Figure 6-8 Accessing the Revealed and Authenticated Lists on the RODC
Replication Concerns with the RODC As stated previously, the RODC can receive domain
replication data only from a Windows Server 2008 full (writable) DC. The site with the RODC
must be connected to a site with a Windows Server 2008 full (writable) DC in the same
domain, by a site link with the lowest cost. If the nearest site (again, based on site link cost)
does not contain a Windows Server 2008 full (writable) DC in the same domain, domain data
replication to the RODC will fail.
The RODC can receive all other partitions of replication from a Windows Server 2008 DC or
a Windows Server 2003 DC.
Automatic Site Coverage Sites are defined in Active Directory by mapping IP subnets to
specific sites. Active Directory clients authenticate against and otherwise access DCs in their
local site, based on their IP addresses. To ensure that all Active Directory clients are able to
identify the appropriate local DC, DNS SRV records are created for DCs and mapped to each
site within the DNS zone for the domain.
320 Chapter 6 Design a Branch Office Deployment
Because it is possible to create a site without placing a domain controller in the site, Windows
2000 Server, Windows Server 2003, and Windows Server 2008 perform a service called automatic
site coverage. If a site is recognized to be without a DC, a DC in the nearest site, based
on site link cost, registers a service location (SRV) record for the remote site. This allows the
Active Directory clients in the remote site without a local DC to connect to the nearest DC to
their site.
However, Windows 2000 Server and Windows Server 2003 do not recognize a Windows
Server 2008 RODC and might register a SRV record for a remote site, with only an RODC in
it. This is a problem. In DNS for the branch office site there is a SRV record for the RODC that is
actually in the branch office site and a SRV record for a Windows 2000 Server DC or a Windows
Server 2003 DC in a site remote from the branch office. With DNS round robin (enabled by
default), 50 percent of the time Active Directory clients in the branch office site will commute
the WAN link to access Active Directory when they have their own RODC locally. This causes
increased and unnecessary traffic on the WAN link, degrades performance, and can cause
Active Directory–related failures for clients in the branch office site if the WAN link is down.
At the time of this writing, Microsoft recommends using one of five adjustments to resolve this
problem:
■ Wait for a hotfix from Microsoft.
■ Use only Windows Server 2008 DCs in the site nearest to the RODC site.
■ Disable automatic site coverage on the Windows 2000 Server DCs and the Windows
Server 2003 DCs.
■ Adjust the weight of the Windows Server 2003 DC SRV records (this is only a partial
solution).
■ Use a GPO to adjust the weight of the Windows Server 2003 DC SRV records (this is
only a partial solution).
RODC Compromise The main reason to use the RODC is the increased threat of compromise
of the DC in an unsecure environment, either by physical theft or access of the system or
electronic attack. If the RODC is stolen or becomes otherwise compromised and the hacker
cracks into the Active Directory database, the hacker has access to only a few account passwords,
so the amount of accounts potentially compromised is reduced. By using the Revealed
List for the RODC in Active Directory Users and Computers, you can quickly reset the potentially
compromised passwords.
Because the RODC cannot replicate to other DCs, there is no risk of a hacker modifying anything
in Active Directory, such as permissions and group membership, and then poisoning the
legitimate Active Directory through replication.
Lesson 2: Branch Office Server Security 321
If your RODC is stolen, you can easily delete the RODC computer object in Active Directory
Users and Computers without a successful DCPromo to remove the DC from Active Directory
and without using the NTDSUTIL MetadataCleanup command. (Using the NTDSUTIL
MetadataCleanup command to remove Active Directory objects leaves broken links from processes
that refer to the now removed object. These broken links will generate numerous errors
about the missing object in event logs of DCs for the life of the domain.) To delete the RODC
computer object, in Active Directory Users And Computers, right-click the RODC computer
object in the Domain Controllers OU, and select Delete. Click OK to close the Warning message
dialog box. You can then export a list of all accounts that were cached on the RODC and
force the resetting of user and computer passwords for all accounts that were cached on the
RODC, as shown in Figure 6-9.
Figure 6-9 Deleting a stolen RODC from Active Directory Users and Computers
To summarize, a Windows Server 2008 domain controller in the branch office will maximize
performance by having a local copy of all passwords, accepting Active Directory changes, and
performing two-way replication. But it also maximizes the amount of sensitive data loss and
the risk of poisoning the legitimate Active Directory in the case of compromise.
A Windows Server 2008 RODC in the branch office will support most Active Directory
requirements in the branch office while minimizing the amount of sensitive data loss and the
risk of poisoning the legitimate Active Directory in the case of compromise. The more
accounts you cache, the better the performance but the greater the risk of exposure. The fewer
accounts you cache, the poorer the performance but the less the risk of exposure.
322 Chapter 6 Design a Branch Office Deployment
Installing the RODC on a Windows Server 2008 Server Core server in the branch office provides
the greatest level of security in the branch office by reducing the attack surface of the
server and minimizing the amount of sensitive data loss and the risk of poisoning the legitimate
Active Directory in the case of compromise.
The RODC supports delegated installation, as well as Administrator Role Separation for
increased security.
The Password Settings Object
New to Microsoft Windows Server 2008 is the ability to define different password and account
lockout policies to users in the domain. This support for different policies for different users is
called fine-grained password policies. In earlier versions of Windows, only one password and
account lockout policy could be effective for all users in the domain. It is a common concern
that different users in the domain, like the users in a branch office, require different strengths
of passwords and more or less strict account lockout policies. These differing password policies
are defined in Password Settings Objects (PSOs) and are applied to users and (preferably)
groups of users. PSOs cannot be applied to computer objects or to OUs.
To utilize fine-grained password policies in the branch office, the domain functional level must
be set to Windows Server 2008. This requires that all DCs in the domain run Windows Server
2008. Next, create one or more global security groups, one for each different PSO required in
the branch office, and populate the group(s) with the appropriate users. Chapter 4, “Planning
a Terminal Services Infrastructure,” explains in detail how to configure fine-grained password
policies.
Using fine-grained password policies, you can configure values, including the following:
■ Maximum Password Age
■ Minimum Password Age
■ Minimum Password Length
■ Password History
■ Password Complexity
■ Reversible Encryption Enabled
■ Account Lockout Threshold
■ Account Lockout Window
■ Account Lockout Duration
■ Users or global security groups to which the PSO applies
If you don’t like ADSI Edit, you can use LDIFDE. LDIFDE uses a script to configure the new
PSO. Save the following script to an ASCII text file and apply an .ldf file extension. Adjust the
parameters as desired. For example, you will need to replace the domain name specified in the
“dn:” line with your domain name.
Lesson 2: Branch Office Server Security 323
dn: CN=BoPSO, CN=Password Settings
Container,CN=System,DC=dc1,DC=litware,DC=internal
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:24
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=BOusers,CN=Users,DC=dc1,DC=litware,DC=internal
The time values are calculated using the I8 format. The I8 format breaks the time units into
negative 100 nanoseconds (billionths of a second), so all forward-looking time values must be
negative. To convert time into I8 values:
■ Multiply minutes by -6,000,000,000.
■ Multiply hours by -36,000,000,000.
■ Multiply days by -864,000,000,000.
After you create the PSO, you can adjust the users and groups to which it is applied by using
Active Directory Users and Computers. Complete the following steps:
1. Under the View menu item, select Advanced Features.
2. Expand the Active Directory Users And Computers tree to <Domain Name>, System,
and then select the Password Settings Container.
3. In the right pane, right-click the PSO and choose Properties.
4. In the Attribute Editor tab, select the msDS-PsoAppliesTo attribute and click Edit.
5. Add the distinguished name of the user or global security group to which you want to
apply the PSO or remove the desired entry.
Fine-grained password policies allow administrators to define unique password and account
lockout policies for users and global security groups in a domain. They are well-suited for
application to users in the branch office environment, which commonly requires a different
level of security.
MORE INFO Creating the Password Settings Object
For more detail on the creation of the PSO, see the following Technet article:

http://technet2.microsoft.com/windowsserver2008/en/library/2199dcf7-68fd-4315

-87cc-ade35f8978ea1033.mspx?mfr=true.
324 Chapter 6 Design a Branch Office Deployment
Security for Data in Storage
Another area of security for the nonsecure branch office that you should address is security for
data in storage. If a computer is stolen from a branch office, the thief could crack user accounts
on the system and access data stored locally on the hard disk drives. If the thief removes the
hard disk drives from the original computer and mounts them in another computer where he
or she is the administrator, the thief can access all the content. Windows Server 2008 provides
two ways to secure this stored data:
■ The Encrypting File System (EFS)
■ BitLocker
The Encrypting File System (EFS) EFS was introduced in Windows 2000. It provides
encryption for data files and folders only. It requires that the underlying volume (partition) be
formatted with NT file system (NTFS). It uses self-generated X.509 digital certificates associated
with the user account to secure encryption keys for the encrypted content. Ultimately,
one accesses the decryption key by knowing the user’s password. If the hacker can crack the
password, the hacker can decrypt all of the user’s EFS protected content.
By default, the local administrator (standalone) or the domain administrator (domain member)
is the EFS recovery agent and can decrypt any EFS-secured content. EFS cannot be
applied to system or AD DS–related files. All other users who attempt to access another user’s
EFS content receive an Access Denied error, even if proper permissions are granted.
BitLocker BitLocker was introduced in Windows Vista and is available in Windows Server
2008. A specific partition structure must be configured prior to the installation of the operating
system in order for BitLocker to be available for implementation on a system. BitLocker
encrypts the entire volume and can be applied to system, boot, and data volumes. BitLocker
encryption remains intact even if the hard disk drive is installed in another computer and is
mounted by another operating system.
NOTE BitLocker
Use BitLocker if you need to secure the NTDS.dit database.
BitLocker is based on the Trusted Platform Module (TPM), currently version 1.2. TPM is a
microchip that holds the encryption/decryption key and a piece of code in the BIOS used to
perform the encryption/decryption process on the specified disk volumes. You can also implement
BitLocker on systems without TPM support by storing the encryption/decryption key
on a USB thumb drive.
In either case, a recovery key or recovery password, or both, should be exported to external
media in case the original encryption/decryption key(s) are lost. By default, no recovery information
is backed up. The recovery password is a 48-character numeric value that can be typed
Lesson 2: Branch Office Server Security 325
into the BitLocker Recovery Console. The recovery key is stored on a USB thumb drive and
can be accessed by the BitLocker Recovery Console. In addition, you can generate and store
the recovery passwords in AD DS by means of a GPO. The recovery key and recovery password
should be securely stored separate from the computer.
NOTE BitLocker volume recovery
For detailed instructions on backing up BitLocker recovery keys in AD DS and on the BitLocker
recovery process, see the following Technet article: http://technet2.microsoft.com/WindowsVista/en
/library/3dbad515-5a32-4330-ad6f-d1fb6dfcdd411033.mspx?mfr=true.
Securing the Branch Office with Network Access Protection
In Windows Server 2008, administrators can use Network Access Protection (NAP) to ensure
that remote, local, and branch office clients meet minimum security and configuration compliance
requirements for secure connections to branch office and HQ networks. NAP checks
the client’s health status regarding the state of its firewall, updates, antivirus protection, and
anti-spyware protection for the Windows XP SP3, Windows Vista, and Windows Server 2008
operating systems.
NOTE Network Access Protocol
NAP is covered in detail in Chapter 5.
Lesson Summary
■ Introduce all the requisite physical security measures in the branch office to establish a
reasonably secure physical environment.
■ Reduce the number of passwords that might be exposed in the branch office by using an
RODC, along with a minimal list of objects in the Password Replication Policy for that
RODC.
■ Implement the delegated installation of the RODC by pre-creating the RODC account in
Active Directory Users and Computers.
■ Create custom NTDS.dit content on installation media using the IFM subcommand in
NTDSUTIL.exe. IFM stands for installation from media. This replaces the DCPromo/
adv switch used by Windows Server 2003.
■ Implement Administrator Role Separation to limit the administrative privileges to the
operating system only and not to the AD DS.
■ Implement an RODC on a Windows Server 2008 Server Core server to reduce the attack
surface of the RODC.
326 Chapter 6 Design a Branch Office Deployment
■ Understand the need for a Windows Server 2008 full DC in the site nearest to the
RODC.
■ Consider the impact of automatic site coverage on the registration of SRV records for the
site by Windows Server 2003 DCs in nearby sites.
■ Implement fine-grained password policies by creating a Password Settings Object and
assigning it to users and global security groups.
■ Use EFS to encrypt data content while in storage.
■ Use BitLocker to encrypt the operating system, the Active Directory database file
NTDS.dit, and data content. This protects the operating system’s Active Directory database
and data even if the drive is mounted in another computer.
■ Archive the BitLocker recovery keys in Active Directory to recover data if the TPM module
on a system fails.
Lesson Review
You can use the following questions to test your knowledge of the information in Lesson 2,
“Branch Office Server Security.” The questions are also available on the companion CD if you
prefer to review them in electronic form.
NOTE Answers
Answers to these questions and explanations of why each answer choice is correct or incorrect are
located in the “Answers” section at the end of the book.
1. What type of domain controller should be implemented in the branch office for maximum
security?
A. RODC on a Windows Server full installation
B. RODC on a Server Core domain controller
C. Full (writable) domain controller on a Windows Server full installation
D. Full (writable) domain controller on a Server Core domain controller
2. How can you ensure that replication will successfully occur to a site with only one Windows
Server 2008 RODC domain controller?
A. Place a Windows Server 2008 full (writable) DC in the site nearest to the RODC.
B. Place a Windows Server 2008 RODC in the site nearest to the RODC.
C. Make the site link cost to the adjacent site higher than all other costs on site links.
D. Construct a site link bridge.
Lesson 2: Branch Office Server Security 327
3. What is the first action to take if you receive a report that one of the branch offices has
had an RODC stolen?
A. Implement Administrator Role Separation on the replacement RODC.
B. Use ADSI Edit to construct a new Password Settings Object (PSO).
C. Construct a new IFM disk.
D. In Active Directory Users and Computers, delete the RODC.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.