What is PDC chaining?

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.

Thanks to joe who pushed hard on Microsoft to get this behavior done. It wasn’t there by default but came with a hotfix. See http://blog.joeware.net/2005/11/22/137/Â and http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.server.active_directory/2007-01/msg01384.html

6 Comments so far

  1. Mike Kline on June 23rd, 2009

    Good entry and good explanation Florian, the diagram and 6 steps are going to help a lot of people understand this.

  2. florian on June 23rd, 2009

    Thanks Mike! I hope I got everything right in the article. Most of the content was off the top of my head.

  3. Matt Huxtable on June 26th, 2009

    Florian,

    Thanks. This is a great explanation which, as Mike said, will clarify a lot of issues. For many – I bet they never even considered this being a problem though :-)

    Matt

  4. [...] is locked out or if a user’s password was correct. Group Policy MVP Florian has a great blog post on [...]

  5. Pradeep Rawat on August 12th, 2009

    Many thanks florian for sharing such a great article..

  6. Premkumar Yogeswaran on January 4th, 2011

    Florian,

    Thanks for this great article.

    i have a question, does the same process done for time sync and group policy update.

    Please let me know if any link for this from your blog.

    Thank You again…!