Server 2008 will finally make
DFSR available for replication of
SYSVOL between DCs. All DCs in
a domain must be running Server
2008, and the domain must be
switched to DFL3 (Server 2008).
However, in contrast to some other
replication-related features, the
switch to DFL3 does not automatically
change the replication
of SYSVOL from NTFRS to DFSR.
A fairly cumbersome procedure,
which uses the new DfsrMig.exe
tool available on every DC, lets
you create a new DFS root for the
SYSVOL content. This new root
uses DFSR while the original SYSVOL
still uses NTFRS. As part of
the migration process, you copy
the original SYSVOL contents to
the new SYSVOL folder, called SYSVOL_
DFSR by default.
After you switch to
DFL3 and migrate to
DFSR for SYSVOL, the
SYSVOL share will leverage
the new SYSVOL_
DFSR folder. From then
on, the SYSVOL share’s
contents will replicate
much more efficiently. If
you’re planning a new
AD forest, inefficient
SYSVOL replication will
no longer be a reason to
design a multi-domain
forest.
DNS
Changes
I don’t have the space
here to explain all of the
DNS changes in Server
2008. For this
overview, you need to know that DNS has
been updated to allow read-only zones,
which are required to support the DNS
service with the RODC role. The new readonly
zones are similar to secondary DNS
zones, except that the read-only zones are
integrated in AD and can only be hosted on
an RODC. As you might guess, a read-only
DNS zone won’t accept dynamic updates
from clients. So a special mechanism for
RODCs ensures that clients are directed
to the nearest writable DNS server for
dynamic DNS registrations and update
requests. Within five minutes after telling
a client which server to update the DNS
information on, the RODC’s DNS service
will try to connect to that same DNS server
to instantly replicate the DNS changes to its
own database.
Another new AD-related DNS feature
allows clients to locate DCs in the “next closest
site” when they can’t connect to a DC in
their own site, avoiding potentially slow connections
to other remote DCs during failover.
This new capability, a function of the DNS
clients on Windows Vista and Server 2008,
uses site-topology information and site-link
costs stored in AD to determine the next
closest site, before querying DNS to provide
a DC in the respective site. This feature has
been back-ported to Windows XP in the latest
service pack. It can be enabled via Group
Policy Object (GPO):
- Path: Computer Configuration Administrative Templates System\Net Logon\DC
Locator\DNS Records
- Enable settings: “Try next closest
site”
What’s the Big
Deal with RODC?
A challenge with any Win2K or
Windows 2003 AD deployment
has always been the placement
of DCs in remote sites (such as
branch offices) that aren’t necessarily
as physically secure as a
company’s data center.
Except for special Operations
Master (FSMO) roles such as the
Schema Master and the PDC
emulator, all DCs prior to Server
2008 are basically equal. Administrators
of any Win2K or Windows
2003 DC can write changes
to the AD database and can replicate these
changes to other DCs in their AD domain
or forest. Therefore changes performed on
a single DC can affect the whole domain or
even the whole forest. A malicious user with
physical access to a DC, say, in a branch
office, can fairly easily make an elevation-ofprivilege
attack to damage or even destroy a
company’s entire AD forest and dependent
services.
As shown in Figure 1, the malicious
change on the rightmost branch-office DC
replicates out to the central hub DC, which
then replicates that change to all other DCs
in the enterprise. Furthermore, because all
DCs always copy the full AD domain partition,
including the passwords of all users
and administrators in that domain, a compromised
DC would also allow a thief to
perform password cracking attacks against
the DC’s AD database, enabling additional
remote attacks. (See that thief in Figure 1? He
just stole a DC.)
The Server 2008 RODC was designed
to reduce such risks. You can use an RODC
in locations that might not offer the same
physical security as a datacenter but require
rapid, reliable, and robust authentication
services, even if the network link to a
remote datacenter is not available. Companies
that require such authentication quality
in their branch offices no longer have
to deploy ordinary writable DCs into these sites. Organizations now have the option
to deploy RODCs, which by default don’t
replicate passwords locally and never replicate
local changes back to any other DC.
RODCs have a one-way only replication
connection agreement with their writable
DC replication partner. Various changes in
Server 2008’s underlying replication architecture
ensure that this agreement can’t
be changed. For example, RODCs aren’t
members of the Enterprise Domain Controllers
security group, which grants writeable
DCs various write permissions to the
AD database.
Password Replication Policies (PRP)
determine which passwords to replicate to
an RODC. Determining how to configure
PRPs for your company will be a key challenge
for the management of RODCs. PRPs
are managed per RODC and provide a list
of groups, users, or computer accounts that
are either allowed or denied permission to
cache their password on an RODC. The PRPs
are stored with the computer account object
of the respective RODC in AD, as Figure 2 shows.
Deploying RODCs is an extremely
attractive proposition to increase security
in branch office and DMZ deployments. As
Figure 3 shows, you would deploy writable
DCs in a Server 2008 AD infrastructure only
in fully trusted networks (data centers). You
can safely deploy RODCs in edge networks. As a result, an AD infrastructure attack
like the scenario shown in Figure 1 is now
limited to the attacked RODC in the branch
office. And because the RODC doesn’t store
any administrator user secrets (passwords)
by default and will typically be configured to
cache only the passwords of the users in the
RODC’s site, a stolen RODC doesn’t pose the
same risk to a company that a fully writeable
DC does.
An RODC can also be a Read-Only Global
Catalog (ROGC). Note however, that while
ROGCs are supported to be used as GAL
servers for Outlook clients, they aren’t supported
as GCs for use by Exchange servers.
This will have an impact on administrators
who want to deploy the RODC in a branch
office but also maintain a local Exchange
server.
You can compare the features of an
RODC with those of a proxy server. If a user
is authenticating in a site that has an RODC,
the user’s client will locate this RODC like
any other DC and attempt to authenticate
to the RODC. In fact, clients usually won’t
know if they’re talking to a writeable DC or
an RODC, because the RODC will retrieve
all the data it needs on behalf of the client.
When the user authenticates for the first
time to this RODC, the RODC will need to
talk to a writeable DC (usually across the
WAN to a DC in a hub site) and authenticate
the user against this writeable DC. If the RODC is allowed to cache the user’s password
hash, as determined by the RODC’s
PRP, the RODC will be able to fully authenticate
the user the next time without needing
to contact a writeable DC.
RODCs have other attractive features
that distinguish them from writable DCs:
For example, you can delegate local administrator
rights (or other roles) to domain
users or groups to a specific RODC, without
granting the users any special rights in your
AD domain. You do so by using the managedBy
attribute of an RODC computer
object or by assigning local roles through
NTDSUTIL. This capability saves you from
requiring a domain admin account for
maintenance tasks on branch-office DCs
that can also be performed by users with
lower privileges. (This includes the task
of promoting new DCs.) This capability is
restricted to RODCs.
More to Learn
Server 2008 debuts several major AD
enhancements, which are introduced this
article. RODC is clearly the feature that
Microsoft spent most effort on, as you
can see by looking at the changes RODC
required Microsoft to make to Server 2008’s
underlying replication architecture. The
Learning Path lists some further resources
on Server 2008 AD enhancements and
RODC.
End of Article
Register
