Re: Replication of password resets/unlocks

> Well the name urgent replication is used to distinguish the normal
> replication process from the changes that triggers immediate
> replication
> instead of waiting the default period of 15 seconds (or 300 seconds on
> domain controllers that are running Windows 2000).
> Of course this doesn't mean that all DCs will be automatically updated > once
> that urgent replication occurs, I agree with you on that.

Correct. It is urgent queueing, not urgent replication. I have seen urgent replication triggers take hours to get from one site to another even with change notification enabled. It isn't fun when that happens as it usually indicates an overworked bridgehead, but it can easily happen. It isn't a shortcut at all. It simply, as you indicated, forgoes the configurable holdback period.

> - An account lockout is urgently replicated to the PDC emulator
> and is then
> urgently replicated to the following:

Again, urgent replication is urgent queuing. You can't urgent replicate to the PDC itself, it is normal replication that follows standard replication connections. It is just queued in an urgent manner. Once queued, it is normal replication traffic. If it went straight to the PDC, that would be an out of band RPC update and again, I haven't seen anything to lead me to believe this occurs other than some propaganda. I believe nothing MSFT documents until I actually see it function that way myself because the documentation isn't written by developers, it is written by folks who are trying to figure out notes from the developers when those notes may be horrible or nonexistent or even incorrect because something changed after it was internally "documented". I have found numerous documentation errors that I have dug into the source code and verified and then sent update requests to MSFT. Each month I probably submit 5-25 requests depending on how much "new" stuff I work on that month and that is generally split between MSDN and MSKB.

The PDC will almost always be the first place that an account locks out at simply due to how


> If authentication fails at a BDC, the authentication request is passed
> immediately to the PDC, which is guaranteed to have the current
> password.

This is actually incorrect as well. The PDC is not guaranteed to have the current password. It is just highly likely that it does. There is no mechanism in place to guarantee it. If AvoidPDCOnWan is enabled it is very likely unless using legacy clients that the PDC will not have the current password for a user who recently changed it in a WAN site. Other than that, it is usual that the PDC will have the current password but if the RPC out of band update fails for some odd reason (network stutter, gamma rays from outerspace, PDC is down at the time) the PDC will not get the update until the it replicates in normally.

joe



--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm



Jorge Silva wrote:
That is quite a hodgepodge from different documents. There are problems in there.

This isn't from different documents!!! This is technical reference. If MS is wrong... Well sometimes there isn't some consistency in some documents at the first glance.


First off, I know it isn't your fault, but the name urgent replication implies something that it isn't guaranteed to be.

Well the name urgent replication is used to distinguish the normal replication process from the changes that triggers immediate replication instead of waiting the default period of 15 seconds (or 300 seconds on domain controllers that are running Windows 2000).
Of course this doesn't mean that all DCs will be automatically updated once that urgent replication occurs, I agree with you on that.



Second off, there isn't such a thing as urgent replication to the PDC. There is an out of band update that occurs which is a special RPC call that isn't replication based to get info to the PDC.
To my knowledge, this occurs in the case of a password change (assuming AvoidPDCOnWan isn't set) but not for a lockout. What can occur for a lockout is that as a password is tested and is incorrect, the password attempt is chained to the PDC (again if AvoidPDCOnWan is not enabled) and the lockout will occur at the same time on the two DCs. In actual fact, the lockout can occur before the lockout on the local DC if for some reason another DC was queried along with the first, then two DCs are sending attempts to the PDC. For instance, say you send an auth request with a bad password to DC2 and to DC3, assuming a simple auth attempt with no additional auth providers that means one bad on password hit on DC2 and DC3 and 2 bad password hits on DC1 (the PDC).


Makes sence to me, but isn't true that :

- An account lockout is urgently replicated to the PDC emulator and is then urgently replicated to the following:
*Domain controllers in the same domain that are located in the same site as the PDC emulator.
*Domain controllers in the same domain that are located in the same site as the domain controller that handled the account lockout.
* Domain controllers in the same domain that are located in sites that have been configured to allow change notification between sites (and, therefore,
urgent replication) with the site that contains the PDC emulator or with the site where the account lockout was handled.


???

If authentication fails at a BDC, the authentication request is passed immediately to the PDC, which is guaranteed to have the current password.



Because a user cannot specify the domain controller on which
the password change is attempted, an attack of this type
requires an advanced tool.



Eheheh, well not by default... But we can change that.


.