RODC - AD DS: Read-...
 
Bildirimler
Hepsini Temizle

RODC - AD DS: Read-Only Domain Controllers - 2003 server 2008 server  

  RSS
Rahmi DILLI
(@rahmidilli)
Tecrübeli Üye

http://technet.microsoft.com/en-us/library/cc732801.aspx

A read-only domain controller (RODC) is a new type of domain
controller in the Windows Server® 2008 operating system. With an RODC,
organizations can easily deploy a domain controller in locations where
physical security cannot be guaranteed. An RODC hosts read-only
partitions of the Active Directory® Domain Services (AD DS) database.

Before
the release of Windows Server 2008, if users had to authenticate with a
domain controller over a wide area network (WAN), there was no real
alternative. In many cases, this was not an efficient solution. Branch
offices often cannot provide the adequate physical security that is
required for a writable domain controller. Furthermore, branch offices
often have poor network bandwidth when they are connected to a hub
site. This can increase the amount of time that is required to log on.
It can also hamper access to network resources.

Beginning with
Windows Server 2008, an organization can deploy an RODC to address
these problems. As a result, users in this situation can receive the
following benefits:

  • Improved security
  • Faster logon times
  • More efficient access to resources on the network

What does an RODC do?

Inadequate
physical security is the most common reason to consider deploying an
RODC. An RODC provides a way to deploy a domain controller more
securely in locations that require fast and reliable authentication
services but cannot ensure physical security for a writable domain
controller.

However, your organization may also choose to
deploy an RODC for special administrative requirements. For example, a
line-of-business (LOB) application may run successfully only if it is
installed on a domain controller. Or, the domain controller might be
the only server in the branch office, and it may have to host server
applications.

In such cases, the LOB application owner must
often log on to the domain controller interactively or use Terminal
Services to configure and manage the application. This situation
creates a security risk that may be unacceptable on a writable domain
controller.

An RODC provides a more secure mechanism for
deploying a domain controller in this scenario. You can grant a
nonadministrative domain user the right to log on to an RODC while
minimizing the security risk to the Active Directory forest.

You
might also deploy an RODC in other scenarios where local storage of all
domain user passwords is a primary threat, for example, in an extranet
or application-facing role.

Who will be interested in this feature?

RODC
is designed primarily to be deployed in remote or branch office
environments. Branch offices typically have the following
characteristics:

  • Relatively few users
  • Poor physical security
  • Relatively poor network bandwidth to a hub site
  • Little knowledge of information technology (IT)

You
should review this section, and the additional supporting documentation
about RODC, if you are in any of the following groups:

  • IT planners and analysts who are technically evaluating the product
  • Enterprise IT planners and designers for organizations
  • Those responsible for IT security
  • AD DS administrators who deal with small branch offices

Are there any special considerations?

To
deploy an RODC, at least one writable domain controller in the domain
must be running Windows Server 2008. In addition, the functional level
for the domain and forest must be Windows Server 2003 or higher.

For more information about prerequisites for deploying an RODC, see How should I prepare to deploy this feature?

What new functionality does this feature provide?

RODC
addresses some of the problems that are commonly found in branch
offices. These locations might not have a domain controller. Or, they
might have a writable domain controller but not the physical security,
network bandwidth, or local expertise to support it. The following RODC
functionality mitigates these problems:

  • Read-only AD DS database
  • Unidirectional replication
  • Credential caching
  • Administrator role separation
  • Read-only Domain Name System (DNS)

Read-only AD DS database

Except
for account passwords, an RODC holds all the Active Directory objects
and attributes that a writable domain controller holds. However,
changes cannot be made to the database that is stored on the RODC.
Changes must be made on a writable domain controller and then
replicated back to the RODC.

Local applications that request
Read access to the directory can obtain access. Lightweight Directory
Application Protocol (LDAP) applications that request Write access
receive an LDAP referral response. This response directs them to a
writable domain controller, normally in a hub site.

RODC filtered attribute set

Some
applications that use AD DS as a data store might have credential-like
data (such as passwords, credentials, or encryption keys) that you do
not want to be stored on an RODC in case the RODC is compromised.

For
these types of applications, you can dynamically configure a set of
attributes in the schema for domain objects that will not replicate to
an RODC. This set of attributes is called the RODC filtered attribute
set. Attributes that are defined in the RODC filtered attribute set are
not allowed to replicate to any RODCs in the forest.

A malicious
user who compromises an RODC can attempt to configure it in such a way
that it tries to replicate attributes that are defined in the RODC
filtered attribute set. If the RODC tries to replicate those attributes
from a domain controller that is running Windows Server 2008, the
replication request is denied. However, if the RODC tries to replicate
those attributes from a domain controller that is running
Windows Server 2003, the replication request can succeed.

Therefore,
as a security precaution, ensure that forest functional level is
Windows Server 2008 if you plan to configure the RODC filtered
attribute set. When the forest functional level is Windows Server 2008,
an RODC that is compromised cannot be exploited in this manner because
domain controllers that are running Windows Server 2003 are not allowed
in the forest.

You cannot add system-critical attributes to the
RODC filtered attribute set. An attribute is system-critical if it is
required for AD DS; Local Security Authority (LSA); Security Accounts
Manager (SAM; and Microsoft-specific Security Service Provider
Interfaces (SSPIs), such as Kerberos; to function properly. A
system-critical attribute has a schemaFlagsEx attribute value equal to 1 (schemaFlagsEx attribute value & 0x1 = TRUE).

The
RODC filtered attribute set is configured on the server that holds the
schema operations master role. If you try to add a system-critical
attribute to the RODC filtered set while the schema master is running
Windows Server 2008, the server returns an "unwillingToPerform" LDAP
error. If you try to add a system-critical attribute to the RODC
filtered attribute set on a Windows Server 2003 schema master, the
operation appears to succeed but the attribute is not actually added.
Therefore, it is recommended that the schema master be a Windows
Server 2008 domain controller when you add attributes to RODC filtered
attribute set. This ensures that system-critical attributes are not
included in the RODC filtered attribute set.

Unidirectional replication

Because
no changes are written directly to the RODC, no changes originate at
the RODC. Accordingly, writable domain controllers that are replication
partners do not have to pull changes from the RODC. This means that any
changes or corruption that a malicious user might make at branch
locations cannot replicate from the RODC to the rest of the forest.
This also reduces the workload of bridgehead servers in the hub and the
effort required to monitor replication.

RODC unidirectional
replication applies to both AD DS and Distributed File System (DFS)
Replication of SYSVOL. The RODC performs normal inbound replication for
AD DS and SYSVOL changes.

noteNote
Any other shares on an RODC that you configure to replicate using DFS Replication would be bidirectional.

Credential caching

Credential
caching is the storage of user or computer credentials. Credentials
consist of a small set of approximately 10 passwords that are
associated with security principals. By default, an RODC does not store
user or computer credentials. The exceptions are the computer account
of the RODC and a special krbtgt account that each RODC has. You must
explicitly allow any other credential caching on an RODC.

The
RODC is advertised as the Key Distribution Center (KDC) for the branch
office. The RODC uses a different krbtgt account and password than the
KDC on a writable domain controller uses when it signs or encrypts
ticket-granting ticket (TGT) requests.

After an account is
successfully authenticated, the RODC attempts to contact a writable
domain controller at the hub site and requests a copy of the
appropriate credentials. The writable domain controller recognizes that
the request is coming from an RODC and consults the Password
Replication Policy in effect for that RODC.

The Password
Replication Policy determines if a user's credentials or a computer's
credentials can be replicated from the writable domain controller to
the RODC. If the Password Replication Policy allows it, the writable
domain controller replicates the credentials to the RODC, and the RODC
caches them.

After the credentials are cached on the RODC, the
RODC can directly service that user's logon requests until the
credentials change. (When a TGT is signed with the krbtgt account of
the RODC, the RODC recognizes that it has a cached copy of the
credentials. If another domain controller signs the TGT, the RODC
forwards requests to a writable domain controller.)

By limiting
credential caching only to users who have authenticated to the RODC,
the potential exposure of credentials by a compromise of the RODC is
also limited. Typically, only a small subset of domain users has
credentials cached on any given RODC. Therefore, in the event that the
RODC is stolen, only those credentials that are cached can potentially
be cracked.

Leaving credential caching disabled might further
limit exposure, but it results in all authentication requests being
forwarded to a writable domain controller. An administrator can modify
the default Password Replication Policy to allow users' credentials to
be cached at the RODC.

Administrator role separation

You
can delegate local administrative permissions for an RODC to any domain
user without granting that user any user rights for the domain or other
domain controllers. This permits a local branch user to log on to an
RODC and perform maintenance work on the server, such as upgrading a
driver. However, the branch user cannot log on to any other domain
controller or perform any other administrative task in the domain. In
this way, the branch user can be delegated the ability to effectively
manage the RODC in the branch office without compromising the security
of the rest of the domain.

Read-only DNS

You
can install the DNS Server service on an RODC. An RODC is able to
replicate all application directory partitions that DNS uses, including
ForestDNSZones and DomainDNSZones. If the DNS server is installed on an
RODC, clients can query it for name resolution as they query any other
DNS server.

However, the DNS server on an RODC is read-only and
therefore does not support client updates directly. For more
information about how DNS client updates are processed by a DNS server
on an RODC, see DNS updates for clients that are located in an RODC site.

What settings have been added or changed?

To
support the RODC Password Replication Policy, Windows Server 2008 AD DS
includes new attributes. The Password Replication Policy is the
mechanism for determining whether a user's credentials or a computer's
credentials are allowed to replicate from a writable domain controller
to an RODC. The Password Replication Policy is always set on a writable
domain controller running Windows Server 2008.

AD DS attributes that are added in the Windows Server 2008 Active Directory schema to support RODCs include the following:

  • msDS-Reveal-OnDemandGroup
  • msDS-NeverRevealGroup
  • msDS-RevealedList
  • msDS-AuthenticatedToAccountList

For
more information about these attributes, see the Step-by-Step Guide for
Planning, Deploying, and Using a Windows Server 2008 Read-Only Domain
Controller ( http://go.microsoft.com/fwlink/?LinkId=87001 ).

How should I prepare to deploy this feature?

The prerequisites for deploying an RODC are as follows:

  • The RODC must forward authentication requests to a writable domain
    controller running Windows Server 2008. The Password Replication Policy
    is set on this domain controller to determine if credentials are
    replicated to the branch location for a forwarded request from the RODC.
  • The domain functional level must be Windows Server 2003 or higher so
    that Kerberos constrained delegation is available. Constrained
    delegation is used for security calls that must be impersonated under
    the context of the caller.
  • The forest functional level must be Windows Server 2003 or higher so
    that linked-value replication is available. This provides a higher
    level of replication consistency.
  • You must run adprep /rodcprep
    once in the forest to update the permissions on all the DNS application
    directory partitions in the forest. This way, all RODCs that are also
    DNS servers can replicate the permissions successfully.

 

Alıntı
Gönderildi : 19/08/2008 18:50
Paylaş: