Imagine you’re in a multi-site environment that has several DCs in all sites across the nation. Imagine further you have a user John who calls you monday morning. You’re setting in the headquarters. “Dude”, he asks, “can you reset my password? My weekend’s been so hard. They sent me to this branch office where they party all night..”. Well, you feel like that’s okay and after you asked John some additional questions to verify that it is really John you’re talking to, you reset the password.

Immediately after that, John tries to authenticate and – he succeeds. He’s prompted to change his password, does so and logs successfully in. “Thanks buddy”, he ends the conversation. You scratch your head wondering how that password got replicated so fast. You’re sitting in the headquarters doing the change and John is in some branch office which has a pretty tight replication schedule and intervall – rep takes place every three hours between headquater and John’s branch. You verify that “Active Directory Users and Computers” you used to reset John’s password with is “connected” to a local headquarter-DC. You scratch your head. How’s that possible? How’s password reset getting replicated so fast to the branch DC?

The answer lies in PDC chaining. The password isn’t immediately replicated to the branch DC – the mechanism is different. Once a domain controller receives an authentication request, it checks for the credentials provided. In our scenario, the password hasn’t replicated yet to John’s branch office and as John tries the password we manually resetted it to, it fails. Smart-pants branch-DC doesn’t give up though and the next step it tries is ask the PDC emulator-FSMO-holder-DC for help. It chains the authentication request to the PDC. The PDC checks the credentials and – since it got our resetted password already, it replies to the branch-DC that the password is valid. In addition to the “pass is valid” reply to the branch DC, it actually sends the current pass in a follwing message.

Branch-DC now lets John authenticated, but provides him with the “Change password” dialog to pick a new password. After that, John is allowed to log on to his machine.

What basically happened was that branch-DC, evaluating John’s password to “not valid”, forwarded John’s auth request to the PDC which evaluated to true and responded accordingly. After that, the PDC pushes the John’s current credentials to the branch-DC so that it’s up-to-date. This “push” isn’t anything like immediate rep or urgent-rep but a special LDAP operation (Single object replication).

So — why’s branch-DC asking PDC to re-check John’s credentials? Branch-DC knows what all DCs know and that is that PDC always has the valid password* for all users. Once a password gets changed, the DC that handles the password change request pushes the new update via a special RPC call to the PDC to update the password. The PDC is the first to know about password changes and password resets. Again, this isn’t done with pure replication but with a special RPC call to the PDC.

* Exceptions are environments that don’t allow direct DC communication (e.g. a meshed network). In cases where DCs cannot reach the PDC directly – either for chaining an auth request or RPC-pushing the password – the request fails. In those cases, the passwords go along their way through normal replication. Password changes aren’t pushed directly and auth requests are evaluated as “invalid” if the PDC isn’t reachable.

The process is here in a small picture:

1) An admin in site B resets a user’s password in site B.

(2) The DC pushes the new password via an RPC call to the PDC.

(3) At the same time, the user in site C tries to authenticate using the new password. DC-C checks the password with its local database and comes to find that the password isn’t correct (the password reset hasn’t replicated to DC-C).

(4) DC-C forwards the authentication request to the PDC which knows the new password because of the RPC call. It reponds to DC-C, that the password is valid.

(5) Immediately after that, it pushes the new user password via an LDAP operation to DC-C so that DC-C’s database is updated (regarding the user’s password only!). This is not done by normal replication means – it’s a special push.

(6) DC-C allows the user to authenticate.

If you’d like to learn more about Active Directory, I’d recommend that you get hold of these Active Directory Training Videos. If you truly want to Learn Active Directory you won’t find better training than this.