Windows Server 2008—Full Installation
installation of Windows Server 2008 is what most administrators are used
to. It provides all of the desired features through a familiar GUI.
Unfortunately, all the “make life easy for the administrator” gadgets,
GUIs, tools, utilities, and applications create substantially more
opportunities for hackers to break into and take over a server, as
Windows Server 2008—full
installation is generally safe to use on the well-protected LAN or
branch office environment where the threat of compromise is reduced and
where the server is supporting less than highly sensitive data and
Adding a Domain Controller
Access to the domain
controller server is required for successful authentication of users and
computers in the enterprise. Adding a DC to a branch office introduces
increased risk, cost, and administrative overhead in human terms, and in
terms of directory services, it involves the following:
The additional hardware (cost) at the branch office.
Enterprise Admins must create, configure, and maintain a site in Active Directory for the branch office.
There will be Active Directory replication traffic over the WAN link between HQ and the branch office.
There will be the need for additional infrastructure devices or services, or both.
The remote DC must be maintained (at the server level), requiring that Administrator Role Separation be configured.
are security concerns about having a copy of the entire Active
Directory database, complete with usernames and passwords, along with
the additional infrastructure systems and services in this potentially
On the other hand, having a
DC in the branch office provides a notable improvement in performance
and reliability for the branch office for the following reasons:
Branch office users can authenticate faster and can authenticate even if the WAN link is down.
All other local requests of Active Directory Domain Services respond faster and are successful even if the WAN link is down.
having a DC in the branch office means the branch office relies more
heavily on the performance and reliability of the WAN link.
The DC provides an additional level of fault tolerance to the Active Directory database.
Microsoft recommends the addition of a DC in any site (like a branch office) in the following situations:
More than 100 users are in the site.
The site is using an application that relies on a custom Active Directory partition for replication.
logons must be successful (typically expressed as the requirement to
access domain resources) even if the WAN link is down.
Note: Active Directory Domain Services binaries
A new process that runs
prior to initializing the Active Directory Installation Wizard is the
installation of the DCPromo binaries (executables) onto the server. You
can initiate this by adding the AD DS server role to the server. Then
you can execute DCPromo. Alternatively, if you don’t first install the
AD DS server role, you’ll see it automatically initiate by simply
running DCPromo at a command prompt.
In the situations where the
DC is required in the branch office, the next decision is “What type of
DC shall be deployed in the branch office?” This question has new
potential answers in Windows Server 2008. Windows Server 2008 can now
provide the following types of DCs, engineered to help satisfy
reliability, performance, and security concerns in the branch office.
Full Domain Controller
on a full installation of controller Windows Server 2008 (as opposed to
a Server Core installation), the full domain contains all of the
standard components of Active Directory, just as it did in Windows
Server 2003. These DCs perform bidirectional replication with other DCs
in the domain and forest, just as they did in earlier versions of the
The full domain
controller is the least secure implementation of the DC. It has the
full operating system, with many opportunities for the hacker to
exploit. It has the full Active Directory database, complete with
usernames and passwords. The Active Directory database is writable,
providing the opportunity for inappropriate modification, which is a
violation of the integrity of the data in the Active Directory database.
These potential violations of integrity can be the result of either an
authorized user’s accidental misconfiguration or willful misuse or of an
unauthorized user (hacker) manipulating Active Directory.
Read-Only Domain Controller
The RODC is a more
secured version of a DC. Based on a full installation of Windows Server
2008 (as opposed to a Server Core installation), the RODC contains all
of the standard components of Active Directory, except for account
passwords. Clients are not able to write any changes to the RODC,
however. Lightweight Directory Access Protocol (LDAP) applications that
perform write operations are referred to writable DCs that are located
in the nearest site over an available WAN link. RODCs receive only
inbound, one-way domain data replication from Windows Server 2008 DCs in
In addition to the read-only Active Directory database and the one-way replication, RODC features include the following:
Limited contents are stored in the password database in case of
compromise. Administrators must configure a Password Replication Policy
to allow password replication of only specified accounts to occur to the
Administrator Role Separation Described earlier in this lesson.
RODC filtered attribute set To allow administrators to selectively filter attributes on Active Directory objects, typically for security purposes.
All Active Directory–integrated zones get replicated to the read-only
DNS server; however, the zones are nondynamic. When clients attempt to
update their DNS information, the read-only DNS server returns a
referral to the client with the address of a DNS server with a writable
copy of the zone.
Note: Increased RODC security comes at a price
RODC provides additional security against unauthorized changes to
Active Directory and minimizes the number of passwords that might be
compromised if the DC gets stolen from the branch office, the RODC
cannot be used to make any changes to Active Directory data. If the WAN
link is down, no changes can be made to Active Directory through the
RODC was largely designed for the branch office implementation. It can
be installed on the full installation or the Server Core installation of
Windows Server 2008—Server Core, of course, being the more secure of
the two. The option to install the DC as a RODC is a new setting in the
DCPromo utility, as shown in Figure 3.
Figure 3. Selecting the read-only domain controller during DCPromo
Server Core Domain Controller
previously, Server Core is the securest installation of Windows Server
2008. Server Core installs a minimal operating system, providing minimal
services and applications, with no Windows shell and a limited GUI.
Server Core is not a DC by
default, but AD DS can be added to the Server Core installation. When
the more secure RODC role is added to the Server Core installation, you
have the securest DC installation possible, optimized for the risky
branch office implementation. You add the AD DS role to the Server Core
server using the DCPromo /unattend <unattend.txt> command, along with a preconfigured answer file (Unattend.txt) for the DCPromo utility.
2008 Server Core in the branch office, whether configured as a
standalone, member, DC, or read-only DC server, provides the securest
Windows Server 2008 operating system platform due to its server
hardening by design.
The global catalog
server is required for successful authentication of users and computers
in the enterprise. The global catalog (GC) must reside on a DC.
Microsoft recommends that you place a GC in a branch office in the
There is a DC in the branch office, and:
The WAN link is unreliable.
There are more than 100 users in the branch office.
Universal group membership caching is not enabled.
The branch office supports Active Directory–aware or Distributed Component Object Model (DCOM) applications.
Placing a GC in the
branch office will improve the performance of LDAP queries, user logons,
and Active Directory–aware and DCOM applications for users in the
Placing a GC in the branch
office requires a DC in the branch office, raising the risk of the DC
being compromised. Furthermore, it increases the risk of compromise of
sensitive GC data, and it increases the amount of AD DS replication
traffic to and from the branch office over the WAN links.
Few situations would
warrant placing one or more operations masters in a branch office. These
are significant components that reside on DCs within the AD DS
environment, and placing them in an isolated, and potentially
disconnected, branch office could cause problems for the entire forest.
About the only cases where it might be appropriate are:
There is a DC in the branch office, and:
branch office is its own domain. A DC in the branch office would hold
the relative ID (RID) master, the infrastructure master, and the PDC
emulator operations master roles.
branch office is its own forest. A DC in the branch office would hold
the domain naming master, the schema master, the RID master, the
infrastructure master, and the PDC emulator operations master roles.
branch office has the bulk of down-level clients in the enterprise. A
DC in the branch office would hold the PDC emulator operations master
In almost every other
case, the operations master roles should typically remain on the
well-secured, stable, and well-connected HQ network.
Domain Name System
The Domain Name System
(DNS) server is required for successful authentication of users and
computers in the enterprise and for Internet access. Clients in the
branch office will need to locate AD DS servers and other infrastructure
services. It is useful, and can be a requirement, that a DNS server be
placed in the branch office. This provides rapid registration and query
responses, even if the WAN link to HQ is down or busy.
Providing a DNS server in
the branch office is a requirement if the branch office is configured as
its own domain in AD DS. Local clients will need local DNS to locate
domain-related services. From the perspective of the user or a computer,
the act of locating AD DS is accomplished through service location
(SRV) records within the DNS zone for the domain. In addition, other AD
DS DNS zones throughout the forest must:
Be configured as Active Directory–integrated DNS zones with proper replication partitions configured.
Have secondary DNS zones and zone transfers configured.
Have forwarders or stub zones configured.
If the branch office domain is a child domain, a delegation record in the parent DNS zone will need to be configured.
Dynamic Host Configuration Protocol (DHCP) Services
infrastructure service that is often required is DHCP for the dynamic
assignment of IP addresses and other configuration settings to clients.
Again, for performance and reliability reasons, placing a DHCP server in
the branch office is often desirable. This aids IP connectivity for
branch office clients even if the WAN link is down for extended periods.
Multisite (Branch Office) Clustering with Microsoft Cluster Services
clusters provide server fault tolerance for highly available
applications and services, such as SQL Server, Exchange Server, Windows
Server Virtualization (also known as Hyper-V or WSv) servers, DHCP
servers, and file and print services. You can place cluster nodes in
each branch office site to provide local access with increased
availability to applications, services, and data.
Distributed File System Replication for Data Fault Tolerance
tolerant mechanism that can be used in the branch office is distributed
file system (DFS) replication. DFS Replication is typically used to
replicate data files to multiple and geographically dispersed DFS
replica sets, which is ideal for the branch office deployment. DFS
Replication has been overhauled in Windows Server 2008, with
improvements in performance, data reliability, and replication on demand
(called Replicate Now), and it can be used on the new Windows Server
2008 RODC server. DFS Replication is so much better than the earlier
(Windows 2000 Server and Windows Server 2003) File Replication Service
(FRS) that it replaces FRS for SYSVOL replication for domains configured
to use the Windows Server 2008 domain functional level.
Routing and Remote Access Services
The Routing and
Remote Access Services (RRAS) server hosts several useful but
potentially risky services. It is now a component of the Network Policy
and Access Services server role, but it can be installed independently
of NAP. New in Windows Server 2008 is support for IPv6.
RRAS can be particularly useful in the branch office because it includes the following services:
In addition, RRAS provides support for these typically lesser-used but sometimes helpful services:
If you decide to
place an RRAS server in the branch office, if it doesn’t exist in the
branch office already, you’ll want to consider the potential placement
of a DC in the branch office. If the RRAS server will be authenticating
users and VPN connections, you might prefer to provide local
The VPN server
component of the RRAS server provides tremendous benefits in securing
information in transit between the branch office and HQ, between two
branch offices, and between the branch office and remote authorized
users. It can provide core network infrastructure services with NAT, IP
routing, and the DHCP relay agent.
that a dial-in server, like RRAS, allows remote users, both authorized
users and hackers, to gain access to the internal network and its
resources. This device is a gap in the security fortress and must be
implemented with careful consideration and planning. It requires ongoing
monitoring and analysis to maintain and maximize security on this
portal into your network infrastructure.
Windows Server Update Services (WSUS)
Windows Server Update Services (WSUS), currently v3.0 SP1, enables
administrators to deploy the latest Microsoft product updates to
computers running the Windows operating system. This server downloads,
stores, and distributes approved Microsoft operating system and
application updates to computers in the enterprise. Placing a WSUS
server in a branch office reduces update traffic, either from the HQ or
from the Internet. The WSUS server in the branch office can be managed
from HQ, so no administrative privilege is required other than local
administrator privilege for underlying server support. HQ
administration can, of course, grant update approval authority to the
branch office administrator, if appropriate.
The down side, again, is
the hardware cost, the slightly increased local administration
overhead, and the increase of the attack surface of the server and the
branch office network.
Virtualization in the Branch Office
Another new technology
that can be a major benefit in the branch office is Microsoft’s Hyper-V
technology. Hyper-V provides support for running multiple virtual
machines on a single physical computer host. This is referred to as
server consolidation. Because most computers operate using only 10 to 25
percent of a computer system’s available resources, such as RAM and CPU
clock cycles, the hardware is severely underutilized. By running
multiple virtual machines on a single physical server host, these server
resources are much better utilized, requiring fewer physical servers
and providing better return
on investment. Having fewer physical devices in the branch office
reduces the number and difficulty of physically securing those fewer
virtualization technology provides for rapid and easy deployment of
virtual machines and simplifies the migration of virtual machines from
one physical host to another. These features can be essential components
of the enterprise’s business continuity and disaster recovery plans.
Hyper-V can be implemented on Windows Server 2008 Server Core servers
for increased security and can be clustered to provide server failover
Hyper-V is included with
Windows Server 2008 Standard, Windows Server 2008 Enterprise, and
Windows Server 2008 Datacenter. Windows Server 2008 Standard includes
one virtual instance per license. Windows Server 2008 Enterprise
includes four virtual instances per license. With Windows Server 2008
Datacenter, customers receive unlimited virtual instances per license.
You can buy these versions without Hyper-V, but the savings are
Branch Office Communications Considerations
Branch office networks need
to connect to resources in the HQ network. This connection can be on
dedicated lines, like a T1 or T3, or it can communicate over the public
wires of the Internet. In either case, these channels of communication
should be protected from the sniffer or eavesdropper. Furthermore, it is
not uncommon for the WAN link between the branch office and HQ to go
down, forcing the network administrator to view WAN links as unreliable.
These unsecure and unreliable WAN links are required to carry sensitive
corporate, medical, financial, and otherwise private data requiring
protection by laws and regulations, as well as data to support AD DS.
The types of data an enterprise must consider in its branch office
deployment design are the following:
User data—accessed over the WAN links and for centralized backups at HQ
DFS replicated data
AD DS replication data—if the branch office holds a DC
Global catalog replication data—if the branch office holds a GC
DNS data—either within AD DS replication Active Directory Integrated zones or in zone transfers
Multisite clustering heartbeat data
Site Link Considerations for the Branch Office
Each defined site
must connect to AD DS by means of a site link. A site link is the
logical connection object between sites for AD DS replication. This
logical connection, of course, requires physical connectivity to be in
place and to be functioning properly for replication to succeed. Due to
the security constraints on different types of data that must be
replicated and to provide redundancy for failed replication servers,
there are often replication paths for Active Directory replication data
that would fail without the addition of site link bridges.
good news is that from as early as Windows 2000 Server, site link
bridging is enabled by default on all site links. If tighter control
over replication paths is required, the Bridge All Site Links option can
be disabled. The administrator must then manually construct any
specific site link bridges required to provide the proper connectivity
and redundancy on these logical connections.
Another aspect of
AD DS replication, new to Windows Server 2008, is the need to ensure
replication to the new RODC. Unfortunately, down-level domain
controllers (Windows 2000 Server and Windows Server 2003) do not
recognize an RODC because of its one-way replication processes and will
not replicate data to it. This requires that any site with only RODCs
(one or more) must have a site link directly to a site with at least one
Windows Server 2008 DC. The Windows Server 2008 DC does recognize the
RODC and will replicate AD DS data to it appropriately.
Confidentiality for Data in Transit
No matter what type
of connection you use, you should employ VPNs to secure data in transit
between the branch office and HQ and between remote clients and the
branch office. Windows Server 2008 provides VPN support for the
following VPN protocols:
Tunneling Protocol (PPTP)
The early and original Microsoft VPN protocol. This VPN is easy to set
up and provides reasonable security based on the RC4 cipher for
encryption. It uses TCP port 1723.
Layer 2 Tunneling Protocol (L2TP)
Operates at layer 2 of the OSI model, so no IP network is required.
L2TP provides strong authentication, nonrepudiation, and strong
integrity validation by using X.509 digital certificates on the end
point servers. It does not provide confidentiality (encryption). It uses
TCP port 1701.
IP Security (IPsec)
Operates at layer 3 of the OSI model, so an IP network is required. It
has become the de facto VPN protocol of choice. With Windows Server
2008, it uses 3DES or AES for encryption and can provide weak
authentication and integrity validation based on Kerberos. It can be
strengthened to provide strong authentication, nonrepudiation, and
integrity validation based on X.509 digital certificates. It uses UDP
Secure Sockets Transport Protocol (SSTP)
This is a new feature in Windows Server 2008. This VPN protocol is
based on the very popular Hypertext Transfer Protocol (HTTP) over Secure
Sockets Layer (SSL) and Transport Layer Security (TLS), but it has been
refined for use on the LAN (versus its original use for Web-based
services and applications). It can provide only client-to-server
functionality and provides strong authenticity, nonrepudiation, and
integrity validation of the server (only), along with weak
authentication and integrity validation of the client. SSTP has native
support for IPv6. It is based on an X.509 digital certificate on the
server, uses the popular RC4 and AES ciphers, and runs over TCP port