Re: Replication of password resets/unlocks

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.

Ok, queueing sounds better. Urgent queueing that triggers urgent
replication, i'm not sure wht difference are you trying to make here because
either way they can take time.

I believe nothing MSFT documents until I actually see it function

This explains why you contest almost everything (i this particular case of
course). :)

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".

Sounds descrimination. :)

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.

I have to agree with you in this point because I already saw some mistakes.
But is strange that you mention this... Because you're a book writer too,
and I think (not sure) that you're a MS Developer, so mistakes can happen in
your books too right?

In some tests that I did it some time ago, I tested this "thing" about "some
changes that triggers" urgent replication, and I could verify that hey
worked for me, I already saw this in action in some of my clients and it
also worked (of course I'm not going to test in each client).

So I can only speak about my experience.





--
I hope that the information above helps you

Good Luck
Jorge Silva
MCSA
Systems Administrator

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:uxAgAQNlGHA.3588@xxxxxxxxxxxxxxxxxxxxxxx
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.


.

Relevant Pages

  • Re: password replication
    ... Password change is not an urgent replication and thus it is not replicated ... server acting as PDC emulator. ... server finally authenticates the user. ...
    (microsoft.public.win2000.active_directory)
  • Re: PDC EMU ?
    ... sent to pdc em in ste 1 so the dc in site 3 isnt "immedialtely" told, ... DC in site 2 be told of the change immediately, next replication or never. ... but Windows also pushes the change to the PDCe ... that the AvoidPDCOnWan setting change only affect the DC were you're ...
    (microsoft.public.windows.server.active_directory)
  • Re: Urgent replication not seeming to work
    ... even my enemies call me joe. ... There are two components to the whole PDC Chaining story. ... If the PDC is too busy or their is a network issue the password will not be forwarded onto the PDC, it will get there through normal AD replication eventually. ... There is really no such thing as urgent replication. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Urgent replication not seeming to work
    ... There are two components to the whole PDC Chaining story. ... normal AD replication eventually. ... really no such thing as urgent replication. ... Joe Richards Microsoft MVP Windows Server Directory Services ...
    (microsoft.public.windows.server.active_directory)
  • Re: Urgent replication not seeming to work
    ... even my enemies call me joe. ... There are two components to the whole PDC Chaining story. ... If the PDC is too busy or their is a network issue the password will not be forwarded onto the PDC, it will get there through normal AD replication eventually. ... There is really no such thing as urgent replication. ...
    (microsoft.public.windows.server.active_directory)