Windows Server 2008 contains a variety of enhancements to Active Directory (AD)
services. A standout AD feature change is the new read-only domain controller
(RODC). As the name indicates, this enhancement adds a read-only mode
for DCs, so you can’t write changes to the AD database, and you can replicate
only one way from other DCs. However, unlike the Windows NT Server 4.0 Backup Domain
Controllers (BDCs), which might come to mind, an RODC can be configured to store only the
passwords of specified users and computers. This limitation reduces
the risks in case an RODC is compromised. The Server 2008 RODC
feature, because it has the potential to reduce attack vectors thus
improving physical security, will have a major impact on how you
deploy and manage DCs in branch offices and the perimeter network
(aka the DMZ).
Before I examine the RODC, I’ll show you other enhanced AD
features in Windows 2008. I’ll walk you through the AD functional
levels, both the domain functional levels (DFL) and the forest functional
levels—FFL). This should give you a good understanding of the
requirements for deployment of RODC and other new options, such
as Fine-grained password policies (FGPP) and DFS replication for
SYSVOL, which I’ll cover here. In addition, I’ll discuss changes made
to DNS in Windows 2008 so that the DNS service works with smoothly
with RODC.
For a quick overview, see a Web Table 1 which lists the RODC and other important
enhancements to AD.
AD Functional Levels
The RODC requires at least FFL2 (Windows
2003). What does this mean? Let’s look at
the background of AD functional levels.
AD functional levels were introduced with
Windows Server 2003 to avoid conflicts
between AD features specific to each OS
version. Such conflicts can occur when
multiple OS versions are deployed on DCs
in an AD domain or forest. Functional levels
are especially important when you want to
introduce changes that affect the AD replication
mechanism or other domain- or
forest-wide features that downlevel versions
of the Windows Server OS don’t
understand.
For example, suppose you’re upgrading
from a Windows 2000 (Win2K) forest,
which is functional level 0, to a Windows
2003 forest. After all DCs in a domain are
upgraded or replaced with Windows 2003
DCs, you can increase the domain’s functional
level (DFL) to DFL2 (Windows 2003).
DFL2 enables features such as DC Rename
and the ability to write the last logon timestamp.
After you switch all domains in a
forest to DFL2, you can finally upgrade the entire forest’s functional level (FFL) to
FFL2 (Windows 2003). FFL2 introduces features
such as transitive forest trusts, domain
rename, and linked value replication (LVR).
LVR is a major improvement for the replication
of large multi-valued attributes such
as group membership. With LVR, if you
make changes (e.g., adding or removing a
member to or from a group) to a long list of values, only those changes are replicated to
other DCs, instead of replicating the whole
list of values with every change of the list, as
Win2K DCs do.
Note that many new features in Server
2008 AD don’t have a specific requirement
for a DFL or FFL, but a minimum of DFL2
and FFL2 is desirable. Microsoft made an
effort to ensure implementation of RODCs
in domains hosting Windows 2003 DCs. This
allows companies to deploy RODCs without
first having to upgrade the whole domain or
forest. But expect some Windows 2003 hotfixes
along with Server 2008 to help make the
two DC versions work smoothly with each
other in the same domain. (For information
on deploying RODCs in a forest containing
Windows Server 2003 DCs, see the Learning
Path.)
Four new features are enabled when you
switch to DFL3 (Server 2008). Two of those
affect AD design: the ability to assign different
password policies to users in the same
domain and the use of DFS replication for
SYSVOL. No new AD features are enabled
after you switch the forest to FFL3 (Server
2008)—i. e., once all DCs in the forest are running
Server 2008. However, switching to FFL3
means that all domains in the forest must run
Server 2008 DCs and that no domains or DCs
with a legacy OS can be added to the forest.
See Table 1 for a summary of new AD features
by functional level.
Fine-Grained Password
Policies
For OS versions prior to Server 2008, an
AD domain can have only one password policy that applies to the user accounts in
the domain. The password policy determines
rules for password length, expiration
date, and complexity for every account
in the domain. Because these settings are
defined via a Group Policy Object (GPO—
i.e. the domain’s Default Domain Policy),
many administrators thought they could
apply multiple password policies simply
by adding different GPOs at different organizational
unit (OU) levels in the domain.
However, these GPOs applied only to the
computer’s objects located in the respective
OUs and would thus affect only local
accounts on those computers. Many companies
found this situation disappointing
and confusing.
Server 2008 changes this limitation by
introducing Fine Grained Password Policies
(FGPP). This feature is available only when
all DCs in a domain are running Server 2008
and the domain has been switched to DFL3
(Server 2008). Although DFL3 still won’t let
you apply different password policies to different
OUs, DFL3 does let you define different
password policies directly to a user account
or to a group. Note that these policies also
allow you to set different lockout rules. So,
for example, you can set sensitive accounts
to lock out after fewer attempts than with
ordinary user accounts. To reduce the overall
management effort, the best practice is to
specify policy at the group level rather than
the user level.
Because users can be members of multiple
groups, potentially more than one of
which is assigned a password policy, Server
2008 AD includes a feature to determine
the resulting policy for any user. In case no
policies have been assigned to the user or
any of the user’s group memberships, the
default domain policy applies. This feature
gives companies flexibility in setting password
policies. Although most companies
have learned to live with the pre-Server 2008
limitations of a single password policy per
domain, some organizations have deployed
different domains just to allow creation of
different policies. With Server 2008, you can
use FGPP instead. Companies can consolidate
domains previously used for different
password policies and eliminate the hardware
and operational costs associated with
additional domains. Most companies will
value the ability to enforce tighter policies
for sensitive accounts in a domain, such as the administrative accounts and those used
by services.
You manage the new password policies
via Password Settings objects (PSO) created
in the Password Settings Container
in the system container of an AD domain.
Currently, no native GUI or scripting tools
are available from Microsoft to manage
PSOs. Although ADSI Edit is not the sexiest
GUI to work with for this purpose, this tool,
which is now installed natively on every
DC, works well to allow easy creation and
management of PSO objects. Other UIs and
new PowerShell cmdlets might be made
available by Microsoft in the future, but
already there are various tools available for
free on the Internet to download and manage
PSOs. See the Learning Path for more
information on tools.
Using ADSI Edit to
Create PSOs
Using ADSI Edit, you can create PSOs in five
steps:
- Ensure that all your DCs in your domain
are running Server 2008 and that you’ve
switched to Server 2008 domain functional
mode (for example, by using the Microsoft
Management Console–MMC–snap-in AD
Users and Computers ).
- Start Adsiedit.msc and connect to
the default naming context (DC=), then browse to the following
container: CN=Password Settings Container,
CN=System,DC=
- Right-click the Password Settings Container
object and select New, Object.
- Use the Create Object wizard, to create
a new msDS-PasswordSettings object.
Create the object with the attribute values
shown in Table 2. The resulting new Password
Settings Object, My-ServerAdmin-
PSO (along with other settings), requires
specified users to enter a 15-character
password that needs to be changed every
30 days. To take effect, the PSO still needs to
be applied to user or group objects, which is
the next step.
- Apply the newly created PSO by viewing
the properties of the My-ServerAdmin-
PSO object in ADSI Edit and editing the
msDS-PSOAppliesTo attribute. Enter users
or groups (i.e., those that users must be a
member of) to apply the policy to your target
users. For example, I created a group called
My-ServerAdmins.
Using DFSR for SYSVOL
A key enhancement of Windows Server
2003 R2 was a new, efficient file replication
service. Surpassing its predecessor in
integration with DFS, the new file replication
service was called DFS Replication
(DFSR). A major new feature was the ability
to restrict the replication traffic to just the
changes in files between two DFS replicas.
So if a file of many hundred megabytes is
changed by just a few bytes, DFSR ensures
that only the changed bytes are replicated
to the various replication partners. Previously,
with NT File Replication System (NTFRS), any change in a file (including
changes to attributes such as a file’s NTFS
permissions) caused the whole file to replicate.
Now Server 2008 adds even more
scalability enhancements to DFSR, such as
an increased number of parallel file replication
threads, and the removal of the 5,000
DFS targets limit per AD-integrated DFS
root. (Now DFS roots can have an unlimited
number of DFS targets.)
Ever since the availability of DFSR in
Windows 2003 R2, AD administrators had
hoped to leverage this new service for SYSVOL,
after upgrading all DCs to Windows
2003 R2. However, this was not possible—
SYSVOL had to keep using the inefficient
NTFRS engine for replicating their Group
Policy changes and the contents of the
scripts folder (NETLOGON share). The inefficiency
of NTFRS was actually one cause for
AD architects to sometimes design multidomain
forests, merely to reduce the NTFRS
traffic if a large company had many slow
high-latency network links that DCs needed
to replicate across.
Continue on Page 2
Previous
Register
