Ad ds rodc
Upcoming SlideShare
Loading in...5
×
 

Ad ds rodc

on

  • 1,028 views

 

Statistics

Views

Total Views
1,028
Views on SlideShare
1,028
Embed Views
0

Actions

Likes
0
Downloads
36
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ad ds rodc Ad ds rodc Document Transcript

  • AD DS: Read-Only Domain ControllersUpdated: January 13, 2011Applies To: Windows Server 2008A read-only domain controller (RODC) is a new type of domain controller in the Windows Server® 2008 operatingsystem. With an RODC, organizations can easily deploy a domain controller in locations where physical securitycannot 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 areanetwork (WAN), there was no real alternative. In many cases, this was not an efficient solution. Branch offices oftencannot provide the adequate physical security that is required for a writable domain controller. Furthermore, branchoffices often have poor network bandwidth when they are connected to a hub site. This can increase the amount oftime 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 networkFor more information about RODCs, see the Read-Only Domain Controller (RODC) Planning and DeploymentGuide (http://go.microsoft.com/fwlink/?LinkID=135993).What does an RODC do?Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a wayto deploy a domain controller more securely in locations that require fast and reliable authentication services butcannot ensure physical security for a writable domain controller.However, your organization may also choose to deploy an RODC for special administrative requirements. Forexample, 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 TerminalServices to configure and manage the application. This situation creates a security risk that may be unacceptable ona writable domain controller.An RODC provides a more secure mechanism for deploying a domain controller in this scenario. You can grant anonadministrative domain user the right to log on to an RODC while minimizing the security risk to theActive Directory forest.You might also deploy an RODC in other scenarios where local storage of all domain user passwords is a primarythreat, 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 havethe 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 thefollowing 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 officesAre 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 adomain controller. Or, they might have a writable domain controller but not the physical security, networkbandwidth, 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 databaseExcept for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domaincontroller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must bemade 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 ApplicationProtocol (LDAP) applications that request Write access receive an LDAP referral response. This response directsthem to a writable domain controller, normally in a hub site.RODC filtered attribute setSome applications that use AD DS as a data store might have credential-like data (such as passwords, credentials, orencryption 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 objectsthat will not replicate to an RODC. This set of attributes is called the RODC filtered attribute set. Attributes that aredefined 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 replicateattributes that are defined in the RODC filtered attribute set. If the RODC tries to replicate those attributes from adomain controller that is running Windows Server 2008, the replication request is denied. However, if the RODCtries to replicate those attributes from a domain controller that is running Windows Server 2003, the replicationrequest can succeed.Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan toconfigure the RODC filtered attribute set. When the forest functional level is Windows Server 2008, an RODC thatis compromised cannot be exploited in this manner because domain controllers that are runningWindows 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 isrequired for AD DS; Local Security Authority (LSA); Security Accounts Manager (SAM; and Microsoft-specificSecurity Service Provider Interfaces (SSPIs), such as Kerberos; to function properly. A system-critical attribute hasa 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 tryto 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 RODCfiltered attribute set on a Windows Server 2003 schema master, the operation appears to succeed but the attribute isnot actually added. Therefore, it is recommended that the schema master be a Windows Server 2008 domaincontroller when you add attributes to RODC filtered attribute set. This ensures that system-critical attributes are notincluded in the RODC filtered attribute set.Unidirectional replicationBecause no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writabledomain controllers that are replication partners do not have to pull changes from the RODC. This means that anychanges or corruption that a malicious user might make at branch locations cannot replicate from the RODC to therest of the forest. This also reduces the workload of bridgehead servers in the hub and the effort required to monitorreplication.RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication ofSYSVOL. The RODC performs normal inbound replication for AD DS and SYSVOL changes. NoteAny other shares on an RODC that you configure to replicate using DFS Replication would be bidirectional.
  • RODCs also perform automatic load balancing of inbound replication connection objects across a set of bridgeheadservers in a hub site. For more information, see Bridgehead Server Selection(http://go.microsoft.com/fwlink/?LinkID=208721).Credential cachingCredential caching is the storage of user or computer credentials. Credentials consist of a small set of approximately10 passwords that are associated with security principals. By default, an RODC does not store user or computercredentials. The exceptions are the computer account of the RODC and a special krbtgt account that each RODChas. 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 differentkrbtgt 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 hubsite and requests a copy of the appropriate credentials. The writable domain controller recognizes that the request iscoming from an RODC and consults the Password Replication Policy in effect for that RODC.The Password Replication Policy determines if a users credentials or a computers credentials can be replicated fromthe writable domain controller to the RODC. If the Password Replication Policy allows it, the writable domaincontroller 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 users logon requests until thecredentials change. (When a TGT is signed with the krbtgt account of the RODC, the RODC recognizes that it has acached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to awritable domain controller.)By limiting credential caching only to users who have authenticated to the RODC, the potential exposure ofcredentials by a compromise of the RODC is also limited. Typically, only a small subset of domain users hascredentials cached on any given RODC. Therefore, in the event that the RODC is stolen, only those credentials thatare cached can potentially be cracked.Leaving credential caching disabled might further limit exposure, but it results in all authentication requests beingforwarded to a writable domain controller. An administrator can modify the default Password Replication Policy toallow users credentials to be cached at the RODC.Administrator role separationYou can delegate local administrative permissions for an RODC to any domain user without granting that user anyuser rights for the domain or other domain controllers. This permits a local branch user to log on to an RODC andperform maintenance work on the server, such as upgrading a driver. However, the branch user cannot log on to anyother domain controller or perform any other administrative task in the domain. In this way, the branch user can bedelegated the ability to effectively manage the RODC in the branch office without compromising the security of therest of the domain.Read-only DNSYou can install the DNS Server service on an RODC. An RODC is able to replicate all application directorypartitions that DNS uses, including ForestDNSZones and DomainDNSZones. If the DNS server is installed on anRODC, 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 moreinformation about how DNS client updates are processed by a DNS server on an RODC, see DNS updates forclients 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. ThePassword Replication Policy is the mechanism for determining whether a users credentials or a computerscredentials are allowed to replicate from a writable domain controller to an RODC. The Password Replication Policyis 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 includethe following: msDS-Reveal-OnDemandGroup msDS-NeverRevealGroup msDS-RevealedList msDS-AuthenticatedToAccountListFor more information about these attributes, see the RODC Planning and Deployment Guide(http://go.microsoft.com/fwlink/?LinkID=135993).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.Whats the difference between transferring a FSMO role andseizing one? Which one should you NOT seize? Why?Seizing an FSMO can be a destructive process andshould only be attempted if the existing server with the
  • FSMO is no longer available.If you perform a seizure of the FSMO roles from a DC, youneed to ensure two things:the current holder is actually dead and offline, and thatthe old DC will NEVER return to the network.If you do an FSMO role Seize and then bring the previousholder back online, youll have a problem. An FSMO role TRANSFER is the graceful movement ofthe roles from a live, working DC to another live DCDuring the process, the current DC holding the role(s) isupdated, so it becomes aware it is no longer the role holder