0
What else can I help you with?
What do you do to install a new Windows 2003 R2 DC in a Windows 2003 AD?
A. If you're installing Windows 2003 R2 on an existing Windows 2003 server with SP1 installed, you require only the second R2 CD-ROM. Insert the second CD and the r2auto.exe will display the Windows 2003 R2 Continue Setup screen. If you're installing R2 on a domain controller (DC), you must first upgrade the schema to the R2 version (this is a minor change and mostly related to the new Dfs replication engine). To update the schema, run the Adprep utility, which you'll find in the Cmpnents\r2\adprep folder on the second CD-ROM. Before running this command, ensure all DCs are running Windows 2003 or Windows 2000 with SP2 (or later). Here's a sample execution of the Adprep /forestprep command: D:\CMPNENTS\R2\ADPREP>adprep /forestprep ADPREP WARNING: Before running adprep, all Windows 2000 domain controllers in the forest should be upgraded to Windows 2000 Service Pack 1 (SP1) with QFE 265089, or to Windows 2000 SP2 (or later). QFE 265089 (included in Windows 2000 SP2 and later) is required to prevent potential domain controller corruption. For more information about preparing your forest and domain see KB article Q3311 61 at http://support.microsoft.com. [User Action] If ALL your existing Windows 2000 domain controllers meet this requirement, type C and then press ENTER to continue. Otherwise, type any other key and press ENT ER to quit. C Opened Connection to SAVDALDC01 SSPI Bind succeeded Current Schema Version is 30 Upgrading schema to version 31 Connecting to "SAVDALDC01" Logging in as current user using SSPI Importing directory from file "C:\WINDOWS\system32\sch31.ldf" Loading entries..................................................... ...................................................... 139 entries modified successfully. The command has completed successfully Adprep successfully updated the forest-wide information. After running Adprep, install R2 by performing these steps: # Click the "Continue Windows Server 2003 R2 Setup" link, as the figureshows. # At the "Welcome to the Windows Server 2003 R2 Setup Wizard" screen, click Next. # You'll be prompted to enter an R2 CD key (this is different from your existing Windows 2003 keys) if the underlying OS wasn't installed from R2 media (e.g., a regular Windows 2003 SP1 installation). Enter the R2 key and click Next. Note: The license key entered for R2 must match the underlying OS type, which means if you installed Windows 2003 using a volume-license version key, then you can't use a retail or Microsoft Developer Network (MSDN) R2 key. # You'll see the setup summary screen which confirms the actions to be performed (e.g., Copy files). Click Next. # After the installation is complete, you'll see a confirmation dialog box. Click Finish
What do you do to install a new Windows 2003 DC in a Windows 2000 AD?
If you plan to install windows 2003 server domain controllers into an existing windows 2000 domain or upgrade a windows 2000 domain controllers to windows server 2003, you first need to run the Adprep.exe utility on the windows 2000 domain controllers currently holding the schema master and infrastructure master roles. The adprep / forestprer command must first be issued on the windows 2000 server holding schema master role in the forest root doman to prepare the existing schema to support windows 2003 active directory. The adprep /domainprep command must be issued on the sever holding the infrastructure master role in the domain where 2000 server will be deployed
What DNS design to enable no DNS maintenance support at branch office?
you can use stub zone in the branch office but the best would be to install 2008 server RODC. AD DS: Read-Only Domain Controllers 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, 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. RODCs also perform automatic load balancing of inbound replication connection objects across a set of bridgehead servers in a hub site. 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, 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 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.
What are the modifications to DNS for accommodating RODC?
AD DS: Read-Only Domain Controllers 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, 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. RODCs also perform automatic load balancing of inbound replication connection objects across a set of bridgehead servers in a hub site. 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, 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 RODC Planning and Deployment Guide 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. http://technet.microsoft.com/en-us/library/cc732801%28WS.10%29.aspx
Why are the modifications necessary to DNS for accommodating Read Only Domain Controllers?
"Because the DNS server that runs on an RODC cannot directly register client updates, it has to refer the client to a DNS server that hosts a primary or Active Directory-integrated copy of the zone file. This server is sometimes referred to as a "writable DNS server." When a client presents a Find Authoritative Query, which is the precursor to an update request, the DNS server on the RODC uses the domain controller Locator to find domain controllers in the closest site.The RODC then compares the list of domain controllers that is returned with the list of name server (NS) resource records that it has. The RODC returns to the client the NS resource record of a writable DNS server that the client can use to perform the update. The client can then perform its update.If no domain controller in the closest site matches an entry in the list of NS records for the zone, the RODC attempts to discover any domain controller in the forest that matches an entry in the list.Suppose that a new client is introduced to a site that has a DNS server running only on an RODC. In this case, the RODC DNS server tries to replicate the DNS record that the client has tried to update on the writable DNS server. This occurs approximately five minutes after the RODC provides a response to the original Find Authoritative Query.If the DNS client on the RODC attempts a DNS update, a writable domain controller running Windows Server 2008 is returned so that the RODC can perform the update."thamilselvan@hp.comAD DS: Read-Only Domain ControllersA 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 networkWhat 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 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,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 databaseExcept 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 setSome 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 replicationBecause 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.noteNoteAny 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 bridgehead servers in a hub site.Credential cachingCredential 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 separationYou 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 DNSYou 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,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-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.AD DS: Read-Only Domain ControllersA 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 networkWhat 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 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,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 databaseExcept 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 setSome 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 replicationBecause 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.noteNoteAny 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 bridgehead servers in a hub site.Credential cachingCredential 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 separationYou 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 DNSYou 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,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-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.Because the DNS server that runs on an RODC cannot directly register client updates, it has to refer the client to a DNS server that hosts a primary or Active Directory-integrated copy of the zone file. This server is sometimes referred to as a "writable DNS server." When a client presents a Find Authoritative Query, which is the precursor to an update request, the DNS server on the RODC uses the domain controller Locator to find domain controllers in the closest site.The RODC then compares the list of domain controllers that is returned with the list of name server (NS) resource records that it has. The RODC returns to the client the NS resource record of a writable DNS server that the client can use to perform the update. The client can then perform its update.If no domain controller in the closest site matches an entry in the list of NS records for the zone, the RODC attempts to discover any domain controller in the forest that matches an entry in the list.Suppose that a new client is introduced to a site that has a DNS server running only on an RODC. In this case, the RODC DNS server tries to replicate the DNS record that the client has tried to update on the writable DNS server. This occurs approximately five minutes after the RODC provides a response to the original Find Authoritative Query.If the DNS client on the RODC attempts a DNS update, a writable domain controller running Windows Server 2008 is returned so that the RODC can perform the update."
