(2011-10-12) Password Replication Between RWDCs And Between An RWDC And An RODC
Posted by Jorge on 2011-10-12
With this blog post I want to explain the difference in replication of regular data in AD and the replication of password, also when RODCs are included in the mix. The focus will be on replication of passwords.
One thing you can be sure of is that passwords do not replicate the same way and other data in the directory, especially between an RWDC and an RODC. Between RWDCs, passwords replicate like any other piece of data in the directory. In addition to that, the following ALSO applies:
- When a password is changed/reset on some RWDC (the initial RWDC), that RWDC will automatically forward the password to the RWDC that hosts the PDC FSMO role. This occurs over the NetLogon secure channel the initial RWDC has with the RWDC hosting the PDC FSMO role. This is default behavior of RWDCs. The exception to this behavior (in other words, the password will not be forwarded) is when the “AvoidPdcOnWan” registry option has been configured on the initial RWDC (see: New Password Change and Conflict Resolution Functionality in Windows
- When a user tries to authenticate against a specific RWDC (the initial RWDC) and the password provided does not match the password on that initial RWDC, then that RWDC will automatically retry authentication of that same user against the RWDC hosting the PDC FSMO role. If authentication against the RWDC hosting the PDC FSMO role succeeds, then the user can log on and the forwarding RWDC (the initial RWDC against which authentication was tried) will instantly inbound replicate the (new) password. This the default behavior. The exception to this behavior (in other words, authentication will not be forwarded) is when the “AvoidPdcOnWan” registry option has been configured on the initial RWDC (see: New Password Change and Conflict Resolution Functionality in Windows. If authentication against the RWDC with the PDC FSMO role fails, the user is presented with an error stating the username or password is incorrect.
- The new password on both the initial RWDC and RWDC with the PDC FSMO role will replicate that new password in the normal way using AD replication to other RWDCs in the same AD domain, with or without change notification depending on the location of the RWDC (from an AD site perspective) and whether or not change notification has been enabled on one or more AD site links.
Between an RWDC and an RODC, the replication of passwords is a different story. A password NEVER replicates automatically from an RWDC to any RODC, no matter what happens! Remember though that this does not apply to password related metadata, such as for example the “pwdLastSet” attribute. The password related metadata does replicate automatically from an RWDC to an RODC. So, how does a password replicate from an RWDC to an RODC? One thing is for sure and that is that it will always occur on demand/request. Two on demand/request scenarios exist, being:
-  the user authenticates against the RODC while the (new) password is not cached yet. In this case the RODC forwards authentication, because it does not have the password, to the RWDC with which the RODC has setup a secure channel with. After authentication the RODC uses the “replicate single object” method to get the latest password of that user account. The RWDC will only allow on demand/request replication of a password to the RODC when that account is explicitly listed in the “Allowed To Cache List” of that RODC and also not explicitly listed in the “Denied To Cache List” of that RODC. This of course will only work when the RODC can reach any RWDC. If the RODC cannot reach the RWDC, the authentication forwarding will not work and the inbound replication of the (new) password will also not work.
-  the admin pre-populates the password of the user/computer account in question on the RODC using ADUC, scripting (e.g. PowerShell) or REPADMIN. Remember that, whatever the case, an RODC will ALWAYS try to inbound replicate the password using the “Replicate Single Object” method, whether or not the user/computer is listed in the “Allowed To Cache List”. It is the responsibility of the RWDC to enforce the password replication policy configuration such as the “Allowed To Cache List” and the “Denied To Cache List”. That’s WHY an RODC can only replicate the default domain NC from a W2K8 or higher RWDC and not from a W2K/W2K3 RWDC. The W2K/W2K3 RWDCs do not understand the password replication policy configuration of an RODC and will therefore not enforce it.
When a password is changed/reset on an RWDC, the password related metadata (e.g. “pwdLastSet” attribute) is replicated to the RODC. Based upon that information the RODC knows the locally stored password (if any) is not valid anymore in the AD domain and will therefore invalidate it. After that it will try to inbound replicate the (new) password using the “replicate single object” method.
Also see the following posts:
(2005-11-24) How To Determine On What DC A Password Was Changed For A User?
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########