Improvements to Active Directory in Windows Server 2008: Read-Only Domain Controller (RODC)

Is the read-only domain controller (RODC) on Windows Server? A new domain controller in the 2008 operating system. With a read-only domain controller, organizations can easily deploy domain controllers in areas where physical security is not guaranteed. An RODC contains a read-only portion of the Active Directory database.

On Windows Server? Before the release of 2008, if users had to connect to the domain controller for authentication across the WAN, there would be no better alternative. In many cases, this is not an effective solution. Branch offices typically do not provide sufficient physical security for a writable domain controller. Moreover, when branch offices are connected to hub sites, their network bandwidth is usually poor. This will result in longer login times. This also hinders access to network resources.

From Windows Server? Beginning in 2008, organizations can deploy RODCs to address these issues. As a result of the deployment, users can get the following benefits: Improved security Fast login More efficient access to network resources What can the RODC do?

When considering the deployment of RODCs, the lack of physical security is the most common reason. RODC provides a new way to deploy domain controllers where fast and reliable authentication is required, while physical security is not guaranteed for writable domain controllers.

However, your organization can also choose to deploy RODCs for special management needs. For example, a line-of-business (LOB) can only be installed on a domain controller in order to run successfully. Or, the domain controller is the only server in the branch office and has to run the server application.

In these examples, the business process owner must frequently log in interactively to a domain controller or use Terminal Services to configure and manage the program. This environment creates a security risk that is not acceptable on writable domain controllers.

RODC provides a more secure mechanical structure for deploying domain controllers in these scenarios. You can transfer the right to log in to the RODC to domain users without administrative rights while minimizing the security risks associated with the interactive directory forest.

You can also deploy RODCs in other scenarios. For example, all domain passwords stored locally in the EXTRANETS are considered to be major threats.

Are there any other special considerations?

In order to deploy an RODC, there must be at least one writable domain controller running Windows Server 2008. In addition, the functional level of the Active Directory domain and forest must be Windows Server 2003 or higher.

What new features does this feature offer?

RODC handles common problems in branch offices. These places may not have domain controllers. Or they have a writable domain controller but not enough physical security, network bandwidth and dedicated technical staff to provide support. The following RODC features alleviate these issues: read-only Active Directory database one-way replication credentials cache administrator role split read-only DNS

Read-only Active Directory database In addition to the account password, the RODC has all writable domains The objects and properties owned by the controller. However, it is not possible to make any changes to the data stored in the RODC database. Changes in the data must be made on the writable domain controller and then copied back to the RODC.

A local program requesting permission to read the directory can obtain access permission. A "referral" response will be received when a program using Lightweight Directory Access Protocol (LDAP) requests write access. In a hub site, these responses typically direct write requests to a writable domain controller.

RODC Filtered Property Sets Some programs that use AD DS as a data store may store data like trust credentials (such as passwords, trust credentials, encryption keys) on the RODC. And you don't want to store this data on the RODC because of the security threats that the RODC is subject to.

For these programs. You can dynamically configure the property set of domain objects that are not copied to the RODC in the schema. This set of attributes is called the RODC filtered attribute set. The attributes defined in the RODC filtered attribute set are not allowed to be copied to any RODC in the forest.

A malicious user who threatens an RODC can try to configure the RODC in some way and attempt to copy the attributes defined in the RODC filtered attribute set to other domain controllers. If the RODC attempts to copy these attributes from a domain controller that has Windows Server 2008 installed, the copy request will be rejected. However, if the RODC attempts to copy these attributes from a domain controller that has Windows Server 2003 installed, the copy request will be accepted.

Therefore, as a security precaution, if you want to configure the RODC filtered attribute set, make sure the forest's functional level is Windows Server 2008. If the forest's functional level is Windows Server 2008, the RODC that receives the threat will not be able to use it because the domain controller running Windows Server 2003 is not allowed in the forest.

You cannot add system key attributes to the RODC filtered attribute set. The basis for judging whether it is a key attribute of the system is to see if the following services can work normally. Such services have AD DS, LSA, SAM (and SSPIs such as Kerberos). In subsequent versions of Windows Server 2008 Beta 3, the system key attributes have attribute values ​​equal to 1 schemaFlagsEx attribute.

The RODC filtered attribute set is configured on the server that owns the schema operations master. If you try to add a system key attribute to the RODC filtered attribute set and the schema operations master is running on Windows Server 2008, the server will return an "unwillingToPerform" LDAP error. If you try to add a system key attribute to the RODC filtered attribute set, but the schema operations master is running on Windows Server 2003, the operation will appear to be successful, but the attribute value is not actually added. Therefore, when you want to add attributes to the RODC filtered attribute set, the price action host recommendation is a domain controller running Windows Server 2008. This ensures that system key attributes are not included in the RODC filtered attribute set.

One-way replication is written directly to the RODC because there are no changes to any attributes, so any changes will not be initiated from the RODC. Therefore, a writable domain controller acting as a replication partner does not generate an operation to "pull" data from the RODC. This means that the results of operations performed by malicious users on the RODC of the branch structure are not copied to the rest of the forest. This also reduces the workload of the bridgehead servers in the hub site and the amount of work required to monitor replication.

One-way replication of RODCs is applied to both AD DS and Distributed File System (DFS) replication. The RODC performs normal inbound replication for AD DS and DFS.

Credentials The cached credential cache is a store of user or computer credentials. The credentials consist of a small set of approximately 10 passwords associated with the security principal. By default RODC does not store user or computer credentials. The exceptions are the RODC's own computer account and all special krbtgt accounts for each RODC. You must show any other credential cache on the RODC.

The RODC announces the key distribution center (KDC) that becomes the branch structure. The RODC will use a different krgbrt account and password to sign or encrypt (TGT) requests than the KDC on the writable domain controller.

When an account is successfully authenticated, the RODC attempts to contact a writable domain controller in the hub site and request a copy of the appropriate credentials. The writable domain controller will recognize that the request came from the RODC and examine the password replication policy that affects the RODC.

The password replication policy determines whether the credentials of the user or computer can be copied from the writable domain controller to the RODC. If the policy allows, the writable domain controller copies the password to the RODC and the RODC caches the credentials.

After the credentials are cached by the RODC, the RODC can directly request service for the user login until the credentials change. (When the TGT is signed by RODC's krbtgt account, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC will forward the request to a writable domain controller. .)

Because the credential cache is restricted to only the credentials of users who are authenticated by the RODC can be cached, potential credential leaks due to threats to the RODC are also limited. Therefore, only a small percentage of the domain users' credentials are cached on the RODC. Therefore, when an RODC is stolen, only those cached credentials may be cracked.

Keeping the credential cache closed may allow for deeper restrictions on leaks, but this will cause all authentication requests to be passed to the writable domain controller. The administrator can modify the default password policy to allow user credentials to be cached on the RODC.

Administrator Role Segmentation You can delegate the local administrative rights of the RODC to any domain user without giving the user access to the domain or domain controller. This enables users of the branch office to log in to the RODC and perform maintenance tasks such as upgrading drivers. However, branch structure users cannot log in to any other domain controller or perform other management tasks in the domain. Therefore, the branch structure user can delegate effective rights to manage the RODC of the branch without threatening the security of other parts of the domain.

Read-only DNS You can install the DNS service on the RODC. The RODC is able to replicate all program directory partitions used by DNS, including ForestDNSZones and DomainDNSZones. If the DNS service is installed on the RODC, the user can perform name resolution just like other DNS servers.

However, the DNS service on the RODC does not support direct client updates. Because the RODC does not register the NS resource records of any AD integrated areas it owns. When the client attempts to update the DNS record on the RODC, the server returns a reference to the DNS server that contains the client update. The client can then attempt to update the DNS record using the DNS server provided in the reference. In the background, the DNS server on the RODC will attempt to copy the updated records from the updated DNS server. The copy request is for a single object (DNS record) only. The list of entire changed regions or domain data will not be replicated during a particular "copy single object" request.