共用方式為

Appendix A: RODC Technical Reference Topics

  • 發行項

Applies To: Windows Server 2008, Windows Server 2012

This appendix includes supplemental information that can help organizations plan a read-only domain controller (RODC) deployment:

  • Password changes on an RODC

  • DNS updates for clients that are located in an RODC site

  • User and computer credentials

  • How the authentication process works on an RODC

  • How the cross-domain authentication process works with RODCs

  • How the Windows Time service works on an RODC

Password changes on an RODC

Users change their passwords on a regular basis as specified by the Default Domain policy or a fine-grained password policy (FGPP). After each authentication attempt that is serviced by an RODC, the RODC performs a replicate single object (RSO) operation to replicate the account credentials if it does not have the current credentials stored locally. In a site that has an RODC and no writable domain controller, one of two actions can occur when users try to change their passwords:

  • The password change request is sent directly to a writable domain controller.

    In this case, the password change is written locally and then forwarded by the writable domain controller to the domain controller that holds the primary domain controller (PDC) emulator operations master (also known as flexible single master operations or FSMO) role in the domain. This is the same behavior as in Windows Server 2003.

  • The password change request is sent to the RODC, which in turn forwards the request to a writable domain controller that runs Windows Server 2008 or later.

    The next steps are the same as would occur if the password change happened directly on the writable domain controller.

If the password of a user is changed directly on a writeable domain controller, when any RODC that has the old password for that user performs a normal replication cycle that includes that password update, it has the effect of making it appear as if the password for that user is no longer present. (Although the old password is still present in the database on the RODC, the metadata that is associated with the password attributes mark the password as absent. Only on the next occasion that the user logs on by using the RODC will the new password be replicated to the RODC by an RSO operation. For more information about how an account password is allowed to be cached, see Credential caching.

In some other cases, a newly changed password is replicated from the writable domain controller to the RODC synchronously as part of the password change operation. In other words, a best effort is made to replicate the password change before returning to the client that is requesting the change. This is slightly different from the RSO behavior after a successful forwarded authentication at the RODC. In that case, the RSO is queued and is therefore asynchronous.

Whether the RODC attempts to replicate the new password without waiting for the replication schedule depends on how the password change is made. The following table describes how the RODC handles replication of various types of password changes. These changes include password changes that can be triggered by selection of the User must change password at next logon setting on a user account, routine password expiration, and unprompted password change. For all the types of situations that are described in the table, assume that the workstation is in the same site as the RODC. Also, replication occurs only if the user account is cacheable on the RODC. For more information about caching, see Credential caching.

Type of password change operation How the RODC replicates the password change

User account password change using Ctrl+Alt+Del on a computer running Windows Vista or Windows Server 2008 or later

This password change method typically uses Kerberos. Specifically, the NetUserChangePassword function calls into the Negotiate security package, which on Windows Vista or Windows Server 2008 or later tries the Kerberos change password protocol, in most cases. The password change sequences is as follows:

  1. A password change is initiated on a computer running Windows Vista or Windows Server 2008

  2. The RODC forwards the password change request to a writable domain controller, where the write actually takes place.

  3. A logon without user interaction is triggered on the computer where the password change was initiated.

  4. The RODC has the old password so it forwards the logon request to the writable domain controller and tries to replicate the new password by RSO.

  5. The writable domain controller checks the PRP, and if password caching allowed, it sends the new password to the RODC by RSO.

    If the RSO did not occur, or failed, the password would be nulled out on the RODC (that is, the link between the password attribute value and its memory address is removed; the password itself is unchanged and remains stored in memory). Passwords never replicate into an RODC by normal replication. If a newer password exists on the writable domain controller then normal replication nulls any password on the RODC.

User account password change using Ctrl+Alt+Del on a computer running Windows XP, Windows Server 2003, or Microsoft Windows 2000

This password change method uses NTLM, which in turn calls in to the Security Accounts Manager (SAM) password change protocol.

By default, password change requests that are initiated from Windows XP and Windows Server 2003 clients locate a writable domain controller to perform the password change. Therefore, the RODC has no knowledge of the password change and does not immediately attempt to perform an RSO operation to get the new password. The RODC acquires the passwords for cacheable users when they log on at the RODC.

You can apply a cumulative hotfix to these client computers if they are in a site where an RODC services the logon attempts. For Windows XP computers, see Update for Windows XP (KB944043) on the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkId=120318). For Windows Server 2003 computers, see Update for Windows Server 2003 (KB944043) on the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkId=120317). If you apply the hotfix, this behavior changes to the following:

The clients locate the closest domain controller, which happens to be the RODC, and send the password change request to the RODC. The RODC forwards the request to a writable domain controller.

After forwarding the password change request to the writable domain controller, the RODC attempts to replicate in the updated password using the RSO mechanism.

User account password change using Lightweight Directory Access Protocol (LDAP)

This password change method can be used by some forms or by administrative scripts that reset passwords. For example, Outlook Web Access has a form that users can use to change their domain password. The form is implemented on Microsoft Internet Security and Acceleration (ISA) Server 2006. It uses LDAP over Secure Sockets Layer (SSL) to transfer the user name, old password, and new password to the domain controller in a secure manner.

The password change happens directly on a writable domain controller. Therefore, the RODC has no knowledge of the password change, and it does not attempt to perform an RSO operation to get the new password.

The next time that the user logs on at the RODC, the authentication is forwarded to the writable domain controller. If the PRP allows the password to be cached on the RODC, the RODC replicates the new password as an individual change after authentication succeeds.

For more information about password changes using LDAP, see article 269190 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=119599).

Computer account password change on a computer running any version of Windows

Computer account password changes are performed over the Netlogon secure channel. If the client computer has a secure channel to the RODC, the RODC forwards the password update to the writable domain controller. The RODC then attempts to replicate the new password using an RSO operation. For the client computer to be able to establish a secure channel with the RODC, its current credentials must be cached on the RODC.

If the client computer does not have a secure channel with the RODC, it attempts the password change on a writable domain controller. (This always happens if the client computer account is not cached on the RODC.) The next time that the computer logs on at the RODC, the authentication is forwarded to the writable domain controller. If the PRP allows the password to be cached on the RODC, the RODC replicates the new password as an individual change after authentication succeeds.

DNS updates for clients that are located in an RODC site

When a client attempts a dynamic update, it sends a start of authority (SOA) query to its preferred Domain Name System (DNS) server. Typically, clients are configured to use the DNS server in their branch site as their preferred DNS server. The RODC does not hold a writeable copy of the DNS zone. Therefore, when it is queried for the SOA record, it returns the name of a writable domain controller that runs Windows Server 2008 or later and hosts the Active Directory–integrated zone, just as a secondary DNS server handles updates for zones that are not Active Directory–integrated zones. After it receives the name of a writable domain controller that runs Windows Server 2008 or later, the client is then responsible for performing the DNS record registration against the writeable server. The RODC waits a certain amount of time, as explained below, and then it attempts to replicate the updated DNS object in Active Directory Domain Services (AD DS) from the DNS server that it referred the client to through an RSO operation.

Note

For the DNS server on the RODC to perform an RSO operation of the DNS record update, a DNS server that runs Windows Server 2008 or later must host writeable copies of the zone that contains the record. That DNS server must register a name server (NS) resource record for the zone. The Windows Server 2003 Branch Office Guide recommended restricting name server (NS) resource record registration to a subset of the available DNS servers. If you followed those guidelines and you do not register at least one writable DNS server that runs Windows Server 2008 or later as a name server for the zone, the DNS server on the RODC attempts to perform the RSO operation with a DNS server that runs Windows Server 2003. That operation fails and generates a 4015 Error in the DNS event log of the RODC, and replication of the DNS record update will be delayed until the next scheduled replication cycle.

More specifically, the SOA query triggers the DNS server on the RODC to put an entry in remotePollList, which is an internal queue on each DNS server. The entry includes the following:

  • The object to be replicated

  • The source domain controller to replicate from

  • A time stamp

The time stamp is set to a time in the future that is equal to the current time plus a replication delay. The replication delay is controlled by a registry setting named DsRemoteReplicationDelay. By default, the value of this setting is 30 seconds.

The internal queue (remotePollList) is processed at regular intervals. The queue-processing interval is controlled by a registry setting named DSPollingInterval. By default, the value of the interval is three minutes.

Important

DsPollingInterval controls all Active Directory polling, not just RODC RSO handling. If you change this value, be aware that this change will affect more than just RODC RSO operations. For example, this setting will affect how often the DNS server polls AD DS for new or updated resource records or DNS zones.

When the DNS server processes the queue, it attempts to replicate only objects whose time stamp is less than current time. Therefore, the delay between the time that the RODC refers the client to an authoritative DNS server and then attempts to replicate in is determined by the following:

  1. The next time that the DNS server processes the queue

  2. Whether the remote replication delay that is set on the entry in the queue has elapsed

If you use the default values for the registry settings, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 30 seconds and a maximum of 210 seconds.

You can modify the values of these registry settings to reduce the amount of time before the RODC attempts to replicate the DNS update. The minimum value for the DsRemoteReplicationDelay setting is 5 seconds. The minimum value for the DSPollingInterval setting is 30 seconds. If you use the minimum values, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 5 seconds and a maximum of 35 seconds.

The following table lists some additional registry entries that are related to the RSO operations that are performed for DNS updates on an RODC. These registry entries are stored in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Registry entry

Minimum value

Maximum value

Default value

EnableRSOForRODC

Either True or False

 

True

MaximumRodcRsoQueueLength

1

1000000

300

MaximumRodcRsoAttemptsPerCycle

1

1000000

100

DsRemoteReplicationDelay

5

3600

30

To modify any of the registry entries that are related to the RSO operations for DNS updates on an RODC, use the Dnscmd.exe command-line tool to set the appropriate parameter. For example, suppose that you add a member server in a branch office with an RODC, and the member server runs a service that registers records in DNS. To help reduce the time that it takes for clients in the branch to locate the new member server by looking up its IP address in DNS, you can run the following command to change the value of DsRemoteReplicationDelay to 10:

dnscmd <server>.<domain>.<com> /Config /DsRemoteReplicationDelay 10

Where <server> is the name of the RODC and <domain>.<com> is the name of your domain. For more information about using Dnscmd.exe, see Dnscmd (https://go.microsoft.com/fwlink/?LinkId=127970).

User and computer credentials

Credentials consist of approximately twelve attributes that may not be present for all accounts. User and computer account credentials typically include the five attributes in the following table.

Attribute name

Description

ATT_UNICODE_PWD

The Windows NT hash of the user’s password

ATT_DBCS_PWD

The LAN Manager (LM) hash of the user’s password (deprecated)

ATT_NT_PWD_HISTORY

Password history for ATT_UNICODE_PWD

ATT_LM_PWD_HISTORY

Password history for ATT_DBCS_PWD

ATT_SUPPLEMENTAL_CREDENTIALS

Optional key material that is computed by authentication packages when a user changes a password

How the authentication process works on an RODC

This section explains how the authentication process works when you use an RODC for authentication. The processes for a computer account authenticating to the domain, a user logging on to the domain, and a user attempting to access a resource through an RODC are described.

The scenario for discussing the processes that are described in this section is as follows:

  • The accounts, resources, and objects that are described in this section are assumed to be in a single Active Directory domain.

  • A network user named Bob Kelly has a user account named BobKelly.

  • Bob Kelly’s workstation is named BKCOMPUTER.

  • BKCOMPUTER is located in a site in AD DS named Branch1.

  • RODC1 is an RODC for the domain, and it is the only domain controller in Branch1.

  • The PRP allows the passwords for BKCOMPUTER and BobKelly to be cached on RODC1.

  • The account passwords for BKCOMPUTER and BobKelly are not yet cached on RODC1.

  • WDC1 is a writeable domain controller, and it is running Windows Server 2008 or later.

  • WDC1 is located in a site in AD DS named Hub.

The scenario is depicted in the following illustration.

Note

This document uses terminology that is specific to the Kerberos authentication process. For an overview of how Kerberos authentication works, see Kerberos Explained (https://go.microsoft.com/fwlink/?LinkId=120374).

Computer account authentication using an RODC

Domain member computers must authenticate to the domain. When computer accounts are located in sites that are serviced by an RODC, they attempt to authenticate through the RODC. The following figure and steps describe the process that occurs when BKCOMPUTER authenticates to the domain for the first time to request a ticket-granting ticket (TGT). Because RODC1 is advertised as the Kerberos Key Distribution Center (KDC) for the site, BKCOMPUTER uses RODC1 as the KDC. (The KDC is a network service that supplies session tickets and temporary session keys that are used in the Kerberos version 5 (V5) authentication protocol.)

BKCOMPUTER authenticates to the domain

  1. BKCOMPUTER prepares a Kerberos authentication service request (KRB_AS_REQ) and sends it to RODC1 in the Branch1 site.

  2. RODC1 receives the KRB_AS_REQ from BKCOMPUTER. RODC1 checks its local database to see if the account password for BKCOMPUTER is cached. Because the password is not cached, RODC1 cannot authenticate BKCOMPUTER.

  3. RODC1 forwards the KRB_AS_REQ from BKCOMPUTER to a writeable domain controller running Windows Server 2008 or later in the Hub site, which is a computer named WDC1 in this scenario.

  4. WDC1 receives the KRB_AS_REQ and is able to authenticate BKCOMPUTER using its full copy of the Active Directory database.

  5. WDC1 generates a Kerberos authentication service response (KRB_AS_REP) for BKCOMPUTER and sends it to RODC1.

  6. RODC1 performs the following two actions:

    1. Requests that WDC1 replicate the credentials for BKCOMPUTER to its replica of the Active Directory database.

    2. Forwards the KRB_AS_REP to BKCOMPUTER.

  7. WDC1 checks the PRP and determines that BKCOMPUTER is allowed to cache its account password on RODC1.

  8. The credentials for BKCOMPUTER are replicated to RODC1, and BKCOMPUTER is added to the list of Accounts whose passwords are stored on this Read-only Domain Controller (also known as the Revealed List, or the msDS-RevealedList attribute) of RODC1.

  9. RODC1 caches the account password for BKCOMPUTER.

At the conclusion of this process, BKCOMPUTER has a TGT that is signed with the domain key and its account credentials are cached on RODC1.

Initial user logon process using an RODC

When Bob logs on to the domain using BKCOMPUTER, the TGT must be retrieved from the domain controller and then a service ticket allowing BobKelly to use BKCOMPUTER must be obtained. The TGT retrieval process, as well as the process for obtaining a service ticket, is described in the following illustrations and steps.

TGT retrieval process

  1. Bob attempts to log on using BKCOMPUTER.

  2. Because RODC1 is advertised as the KDC for the Branch1 site, BKCOMPUTER prepares a TGT request (KRB_AS_REQ) and sends it to RODC1.

  3. RODC1 receives the KRB_AS_REQ from BKCOMPUTER. RODC1 checks its local database and does not have the account password for BobKelly stored locally; therefore, it cannot authenticate BobKelly.

  4. RODC1 forwards the KRB_AS_REQ to WDC1 (a writeable domain controller that runs Windows Server 2008 or later in the Hub site).

  5. WDC1 receives the KRB_AS_REQ and is able to authenticate BobKelly using its full copy of the Active Directory database.

  6. WDC1 signs a TGT using the domain krbtgt account and sends the KRB_AS_REP to RODC1.

  7. RODC1 then performs the following two actions:

    1. Requests that WDC1 replicate the credentials for BobKelly to its replica of the Active Directory database.

    2. Forwards the KRB_AS_REP for BobKelly to BKCOMPUTER.

  8. WDC1 checks the PRP and determines that BobKelly is allowed to cache its account password on RODC1.

  9. The credentials for BobKelly are replicated to RODC1, and BobKelly is added to the Revealed List.

  10. RODC1 caches the account password for BobKelly.

At the conclusion of this process, the BKCOMPUTER and BobKelly accounts have TGTs that are signed with the domain key and both accounts have cached credentials on RODC1. However, before Bob can use BKCOMPUTER, his user account (BobKelly) must obtain a service ticket. The following illustration and steps describe the acquisition of a service ticket for BobKelly using RODC1.

Service ticket acquisition

  1. BKCOMPUTER transmits a Kerberos ticket-granting service (TGS) request (KRB_TGS_REQ) for BobKelly to RODC1 in the Branch1 site, along with the TGT that was issued by WDC1.

  2. RODC1 cannot decrypt the TGT because it does not know the password of the krbtgt account that writeable domain controllers use to encrypt the TGT. RODC1 therefore forwards the KRB_TGS_REQ to WDC1 in the Hub site.

  3. WDC1 receives and deciphers the KRB_TGS_REQ and replies with a Kerberos TGS response (KRB_TGS_REP) to RODC1.

  4. Because RODC1 has cached BobKelly’s credentials, it is able to satisfy requests for service tickets. Therefore, after receiving a KRB_TGS_REP from WDC1, RODC1 returns an error message (KDC_ERR_TGT_REVOKED) to BKCOMPUTER, instead of a Service Ticket.

  5. BKCOMPUTER discards the TGT that was previously issued by WDC1 after receiving the error message from RODC1. Then, BKCOMPUTER sends another KRB_AS_REQ to RODC1.

  6. RODC1 receives the KRB_AS_REQ. Because BobKelly’s credentials are cached, RODC1 uses its own krbtgt account to encrypt the TGT.

  7. RODC1 then sends a KRB_AS_REP with the new TGT to BKCOMPUTER.

  8. BKCOMPUTER sends another KRB_TGS_REQ (including the new TGT issued by RODC1) to RODC1.

  9. RODC1 receives the KRB_TGS_REQ and is able to decrypt the TGT this time. Because BKCOMPUTER credentials are cached locally, RODC1 generates and sends a KRB_TGS_REP with the service ticket to BKCOMPUTER for BobKelly.

At the conclusion of this process, BobKelly is logged on to BKCOMPUTER and has a service ticket to use BKCOMPUTER that was issued by RODC1. Both BobKelly and BKCOMPUTER account credentials are cached on RODC1. WDC1 has recorded that it revealed the credentials of BKCOMPUTER and BobKelly to RODC1.

Subsequent user logons after credentials are cached on the RODC

After the credentials for a user account and the credentials for the workstation to which the user logs on are cached on an RODC, the RODC can process the logon request without contacting a writeable domain controller. The process for allowing subsequent access of BKCOMPUTER for BobKelly using RODC1 for authentication is described in the following illustration and steps.

BobKelly logs on after credentials are cached on RODC1

  1. Bob attempts to log on using BKCOMPUTER.

  2. Because RODC1 is advertised as the KDC for the Branch1 site, BKCOMPUTER sends a KRB_AS_REQ to RODC1.

  3. RODC1 receives the KRB_AS_REQ from BKCOMPUTER and is able to authenticate BobKelly using its local copy of the Active Directory database, because the credentials for BobKelly and BKCOMPUTER are cached locally.

  4. RODC1 creates the KRB_AS_REP, including a TGT that is signed with the krbtgt account of RODC1, and sends it to BKCOMPUTER.

  5. BKCOMPUTER stores the TGT in a ticket cache that is associated with Bob’s logon session. BKCOMPUTER then prepares a KRB_TGS_REQ for BobKelly and sends it to RODC1.

  6. RODC1 is able to decrypt the TGT in the KRB_TGS_REQ from BKCOMPUTER because the TGT was encrypted by the krbtgt account on RODC1. Because the credentials for BKCOMPUTER are stored locally, RODC1 creates a KRB_TGS_REP, which includes the service ticket.

  7. RODC1 sends the KRB_TGS_REP to BKCOMPUTER, where it is stored in a ticket cache that is associated with Bob’s logon.

Bob’s logon session now includes a TGT, as well as a service ticket, that allows use of BKCOMPUTER, which were both provided by RODC1. Bob is now able to begin working at BKCOMPUTER.

Warning

For an RODC to authenticate a logon request locally, both the user and computer credentials must be cached locally. If the user’s credentials are cached, but the computer credentials are not cached, the RODC cannot provide a service ticket for the user to log on to the computer. If a network outage prevents the RODC from contacting a writeable domain controller running Windows Server 2008 or later, the RODC will not be able to provide a service ticket for the computer account and the user logon will fail.

Resource access using authentication by an RODC

When Bob needs to access a resource on a server in another site, his account requires a service ticket that allows access to that server. The process for BobKelly to obtain a service ticket to access a server named FileServ in the Hub site is described by the following illustration and steps.

BobKelly accesses a resource on a server in a different site

  1. Bob attempts to access a resource on FileServ in the Hub site by using BKCOMPUTER in the Branch1 site.

  2. BKCOMPUTER sends a Kerberos TGS request (KRB_TGS_REQ) for FileServ to RODC1.

  3. RODC1 can read the TGT in the KRB_TGS_REQ, but it does not have the credentials for FileServ cached locally. Therefore, it forwards the request to a writeable domain controller running Windows Server 2008 or later, which in this example is WDC1.

  4. WDC1 can decrypt the TGT that was created by RODC1. However, because writeable domain controllers do not trust TGTs that are issued by RODCs, WDC1 recalculates the privilege attribute certificate (PAC).

  5. WDC1 sends a Kerberos TGS response (KRB_TGS_REP), including the recalculated PAC in a service ticket for FileServ, to RODC1.

  6. RODC1 forwards the KRB_TGS_REP to BKCOMPUTER.

  7. BKCOMPUTER is now able to make a connection to FileServ to allow BobKelly to access resources to which his account has been granted access.

FileServ credentials are not cached on RODC1, but Bob has access to the resources for which his account has been granted access on FileServ.

Smart-card logons

Smart-card logons are handled the same as password-based Kerberos logons, except that the certificate in the smart card is used instead of the password for the account. The RODC issues the TGT only if the account is already cached locally (even though the RODC is capable of verifying the authentication request based on the presented certificate). If the account is not cached, the RODC forwards the request to a writable domain controller running Windows Server 2008 or later, exactly as it does with password-based TGT requests.

How the cross-domain authentication process works with RODCs

This section explains how the authentication process works when two RODCs, each from a different domain, are in the same site. The scenario that is shown in this diagram is two domains within the same forest, but the process for how RODCs proxy authentication and authorization requests to writable domain controllers is similar for RODCs that are located in domains in different forests.

An RODC does not know the trust password. It will not be able to provide or decrypt referral ticket-granting tickets (TGTs). Access to writable domain controllers must always be available for cross-domain authentication to succeed.

The following points are a summary of how operations are affected:

  • Cross-domain authentication fails if the WAN is offline.

  • RODC domain authentication for cached accounts succeeds if the WAN is offline.

  • RODC domain authentication for accounts that are not cached fails if the WAN is offline.

In other words:

Authentication: If the RODC can communicate with a writable domain controller, any user from a trusted domain can successfully authenticate to the RODC. If the RODC cannot communicate with a writable domain controller, only those accounts that exist in the same domain as the RODC have the ability to be authenticated by the RODC.

Caching: Because an RODC does not have access to a trust password and must communicate with a writable domain controller to successfully process an authentication attempt from a user in a trusted domain, user accounts in a different domain cannot be cached on the RODC but can authenticate successfully as long as the RODC can communicate with the writable domain controller.

Management: To delegate administration of the RODC to a security principal, that user or group must be in the same domain as the RODC.

Each RODC builds a replication topology that excludes the other RODC. For replication, there is no interaction. The RODCs interact for cross-domain authentication, but not directly. The following illustration shows the limitations of this functionality, based on how the underlying authentication operations work.

The branch site contains an RODC for domain A and for domain B. A user from domain A, whose computer account is also in domain A, attempts to access a resource on server 1 in domain B. The following sequence occurs:

  1. Using the ticket-granting service (TGS), the client presents a service ticket request to a local domain controller for its domain—in this case, an RODC.

  2. By reading files in the TGS, the RODC determines that the requested resource is in a different domain. The KDC on the RODC must be able to provide the client with a referral ticket. This allows the client to access a KDC in the next domain in the trust path. However, the RODC does not have the trust password. Therefore, it has to forward the request to a writable domain controller in the same domain.

  3. The full domain controller returns the referral ticket to the RODC.

  4. The RODC returns the referral TGT to the client.

  5. The client uses the referral TGT to contact a local domain controller in the target domain (domain B) to request a TGS for the resource.

  6. The domain controller, which again is an RODC, cannot decrypt the request because it does not have the trust password. Therefore, the RODC refers the request to a writable domain controller in the same domain.

  7. The writable domain controller validates the request, issues the service ticket, and returns it to the RODC.

  8. The RODC returns the TGS to the client.

The client can then present the service ticket to the resource.

The RODCs in this scenario must contact writable domain controllers because they do not have the trust password. This means that any new cross-domain authentication requests will not work if the WAN is offline.

How the Windows Time service works on an RODC

Reliable time synchronization is required for Kerberos authentication. Client computers can synchronize time from any domain controller, including an RODC. An RODC can synchronize time only from a writable domain controller that runs Windows Server 2008. When a domain controller answers time synchronization requests from clients, it is considered to be a “time source.”

When a client computer attempts to synchronize time, the following sequence occurs on the client computer:

  • The Windows Time service (W32time), using Netlogon, requests a domain controller that matches a set of criteria. For an overview of the criteria, see Keeping the Domain on Time (https://go.microsoft.com/fwlink/?LinkId=119970).

  • The Windows Time service performs scoring for all the domain controllers that are returned by the search requests. Multiple requests are made to locate an optimal time source.

When the Windows Time service chooses a time source, it attempts to synchronize with that time source. Time synchronization on a domain is designed to operate securely to prevent tampering with the responses that the time source sends.

When a client computer attempts to synchronize its local clock with the clock on the time source, the client sends out a time synchronization request. This request contains a security identifier (SID) for the client computer, which the domain controller uses to generate a signature for the response. When the client computer receives the response, the client computer validates the signature to ensure that the response did in fact come from the domain controller.

When a client computer attempts to synchronize with a time source, the following steps occur:

  • The Windows Time service requests a relative ID (RID) from NetLogon, based on the location of the time source.

Note

The RID that NetLogon returns can be either the RID for the local computer account or the RID of a Trusted Domain Object (TDO), when the time source belongs to another forest. A TDO is used when the time source is located in different forest than the client computer because the time source does not possess the required secret for a RID in a separate forest.

  • The Windows Time service adds the RID to the request (along with other values) and sends the request to the time source.

When the domain controller receives the request:

  • The client computer uses NetLogon to create a signature based on the secret associated with the RID that is contained in the request. When the client computer receives the response from the time source, it uses this signature to verify the identity of the time source as being a domain controller.

  • The domain controller performs the necessary additional processing (according to Request for Comments (RFC) 1305), and it sends the response to the client computer.

When the client computer receives the response:

  • The client computer uses NetLogon to generate a signature based on the secret associated with the RID that was sent in the original request. This signature is generated in the same way that the domain controller generated the signature before it sent the response.

  • The client computer compares the signature that it generated to the signature in the response from the domain controller. If the two signatures match, the client computer accepts the response.

RODCs pose a special challenge to this authentication mechanism because an RODC may or may not possess the required secrets to generate a proper signature. Therefore, request processing on an RODC occurs in the following way:

  • The RODC receives the request from the client computer.

  • The Netlogon service verifies that the RODC has the computer password cached for the account whose RID is specified and attempts to sign the request.

  • If the client account password is cached on the RODC:

    • The Netlogon service signs the response by adding the signature that NetLogon generates to the authentication field in the response.

    • The RODC sends the signed response over the network to the client computer.

  • If the client account password is not cached:

    • The Netlogon service is not able to generate a signature for the response, and it informs the Windows Time service that it cannot generate a signature.

    • The RODC adds an entry to the “chaining table.” The purpose of the chaining table is to allow the RODC to “remember” requests that it forwarded to a writable domain controller so that it will be able to forward the response to the client computer that made the original request. The chaining table contains the following fields:

      • IP Address: The IP address (either IP version 4 (IPv4) or IP version 6 (IPv6)) of the client computer that sent the request.

      • RID: The RID that is contained in the request.

      • OriginateTimestamp: The time stamp on the client computer that indicates when the client computer sent the request. This field, along with the RID, is critical to matching the response with the proper entry in the chaining table. The {RID, OriginateTimestamp} pair uniquely identifies a request that a particular client sends at a particular time.

      • ArrivalTime: The time stamp, according to the RODC, that indicates when the request arrived.

  • The RODC forwards a request over the network to the writable domain controller that it is currently using as a time source. The RODC always forwards time synchronization requests to the time source that it is currently using.

  • On the writable domain controller, processing of the request occurs as it normally would. From the perspective of the writable domain controller, this appears to be a legitimate time synchronization request from the RODC.

  • Over the network, the writable domain controller sends a Network Time Protocol (NTP) response back to the RODC.

  • The RODC receives the response from the writable domain controller. An RODC always attempts to match a response to an entry in the chaining table. The response from the writable domain controller contains both the RID and the OriginateTimestamp value, which the RODC matches to an entry in the chaining table:

    • If an entry is found, the RODC forwards the request to the IP address in the chaining table.

    • If an entry is not found, the RODC assumes that the RODC itself sent a request to the writable domain controller, and the RODC processes the response accordingly.

There are a number of security mechanisms that are built into the Windows Time service chaining mechanism. These security mechanisms are designed to prevent various types of attacks that can be made against an RODC.

  • Limited entry lifetime: Entries that are added to the chaining table are considered to be “expired” after 16 seconds. Entries are not cleaned up from the chaining table; instead, they are checked when a new request or response is received. At the beginning of every request or response process, the RODC checks the chaining table for expired entries, and those entries are removed. If a response from the writable domain controller is received after the entry is removed, the response is discarded. The value of 16 seconds is part of the implementation, and it is not adjustable. This value was chosen because 16 seconds is the maximum lifetime of an NTP request, according to the NTP specification (RFC 1305).

  • Acceptance-only forwarding: Responses are forwarded to a client computer only if a matching entry is found in the chaining table. In this way, an attacker cannot “force” time responses to a client through the RODC.

  • Per-RODC threshold: The size of the chaining table is adjustable, but it cannot grow beyond a specified limit. This restricts the RODC to allowing only a set number of outstanding requests at a given time, which prevents the chaining table from saturating the memory of the RODC. If a request is received when the table is full, the request is discarded.

  • Per-client threshold: By default, a client computer is limited to a maximum of four outstanding time synchronization requests at any given time. This prevents a single client computer from saturating the chaining table and preventing other clients from making time-synchronization requests. If a request is received when the client computer has reached its per-client limit, the request is discarded.

The following additional issues are related to how the Windows Time service works on RODCs. These issues can affect RODC planning and deployment:

  • RODCs are restricted to synchronize with only Windows Server 2008 domain controllers. The chaining mechanism has special requirements that only a Windows Server 2008 domain controller can satisfy. If the chaining table is disabled, the RODC is allowed to synchronize with any domain controller, but it will be not be able to answer time synchronization requests from client computers.

  • RODCs are restricted from synchronizing with other RODCs.

  • RODCs are restricted from synchronizing with domain controllers outside their own domain.

Registry entries that are specific to the Windows Time service forwarding mechanism on an RODC

All entries in the following table are located in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer

Entry name (data type)

Description

Default value

Minimum value

Maximum value

ChainEntryTimeout (REG_DWORD)

Specifies the maximum amount of time (in seconds) that an entry can remain in the chaining table before being considered “expired.” Entries that are marked as expired may be removed when the next request or response is processed on the RODC.

4

4

16

ChainMaxEntries (REG_DWORD)

Specifies the maximum number of entries that are allowed in the chaining table. The chaining table grows and shrinks dynamically as requests are received and responses are forwarded (respectively), but it never grows beyond the maximum size. If the table is full and no expired entries can be removed, any incoming requests are discarded.

128

128

1024

ChainMaxHostEntries (REG_DWORD)

Description: Specifies the maximum number of entries that are allowed in the chaining table for a particular IP address. If a request is received and the chaining table already contains the maximum number of entries for that IP address, the request is discarded.

4

4

16

ChainDisable (REG_DWORD)

Disables the chaining mechanism, allowing an RODC to synchronize with any domain controller but preventing any hosts that do not have their passwords cached on the RODC from synchronizing with the RODC. A value of 0 represents FALSE; any other value represents TRUE.

0 (FALSE, chaining is not disabled)