Partager via

Fine-Grained Password Policy and “Urgent Replication”

  • Article

Hi folks, Ned here again. Today I discuss the so-called “urgent replication” of AD, specifically around Fine-Grained Password Policies.

Some background

If you’ve read the excellent guide on how AD Replication works, you have probably come across the section around so-called “urgent replication”:

Certain important events trigger replication immediately, overriding existing change notification. Urgent replication is implemented immediately by using RPC/IP to notify replication partners that changes have occurred on a source domain controller. Urgent replication uses regular change notification between destination and source domain controller pairs that otherwise use change notification, but notification is sent immediately in response to urgent events instead of waiting the default period of 15 seconds.

    • Assigning an account lockout, which a domain controller performs to prohibit a user from logging on after a certain number of failed attempts.
    • Changing a Local Security Authority (LSA) secret, which is a secure form in which private data is stored by the LSA (for example, the password for a trust relationship).
    • Changing the password on a domain controller computer account.
    • Changing the relative identifier (known as a “RID”) master role owner, which is the single domain controller in a domain that assigns relative identifiers to all domain controllers in that domain.
    • Changing the account lockout policy.
    • Changing the domain password policy.

So as long as the connection between the DC’s had Change Notification enabled, changing one of these special data types “urgently” replicated that change to immediately connected partners. Ordinarily this just meant DC’s in your own site, unless you have configured Inter-Site Change Notification on your Site Links. This is the part that confused most folks: urgent replication isn’t so much for security as for consistency. By default, these “urgent” changes might take a few hours or days to transitively reach outlying DC’s but maybe you don’t care because the end user experience would be consistent within every AD site.

Suspiciously absent from the documentation though: Fine-Grained Password Policies. Does this mean that we didn’t update this old article, or that FGPP’s don’t count for urgent replication? After all, FGPP has account and password policies out the wazoo, that’s the whole point of them.

Figuring it out

When I first thought about writing this this article I figured I’d just look at source code, get an answer, make a three line blog post and be on my way. Except that unlike me, you don’t have that source code privilege, so that’s not super helpful. Instead I’ll show you how to determine the behavior yourself; it may be helpful in other scenarios someday.

Let’s do this.

1. You will be making changes on the PDC Emulator DC. You will also need to pick out a DC that directly replicates inbound from the PDCE within the same AD Site. Obviously, you better create a FGPP in this test domain you are using; it doesn’t need to be assigned to anyone. If you’re using Windows Server 2008 R2 you can load up PowerShell and quickly create a password settings object with:

import-module activedirectory

New-ADFineGrainedPasswordPolicy -Name "DomainUsersPSO" -Precedence 500 -ComplexityEnabled $true –Description "Test Domain Users Password Policy" -DisplayName "Domain Users PSO" –LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 10

2. Turn on Active Directory Diagnostic Event Logging for replication events on that downstream partner DC.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
“5 Replication Events” [REG_DWORD] = 5

3. Pick some trivial object on the PDCE to modify (I change a user’s "Description" attribute). Use repadmin.exe /showmeta to see what its current USN is for that description attribute:

image

4. Change the description. After 15 seconds the change replicates to the downstream partner DC:

image

5. If you look in the Directory Services event log on my downstream server, you can also see that there was a USN update as a 1364 event, from the old USN to the new one. So in my example above, the old USN was 692689 and the new one is 692706. There is also a 1412 event, more on that later. The event log reflects this also with my USN vector raising exactly 15 seconds after the originating time:

image

Note: I am using Hyper-V guests here so I have perfect time sync. You may not be this fortunate in your lab. :)

6. Now you change one of the known “urgent replication” settings. For example, the account lockout threshold:

image

7. Neato. This time you don’t get a 1364 event. You still get a 1412 event that has the right USN (so did the Description change previously, not that it matters). But where is the 1364?

image

You don’t get that event because the normal change notification process was bypassed and you’re in the “urgent replication” code path. This is the key indicator that you are using urgent replication, as there is no instrumentation for it. If you choose any of the various “urgent replication” data types and try this, they will all behave the same way.

8. So now we’re pretty confident that getting a 1364 means normal replication and not getting one means urgent replication. So back to the original question – does FGPP follow urgent change replication? Find out: change an FGPP PSO to alter its settings for account lockout threshold.

image

image

As you can see, FGPP does notuse urgent replication. It is treated just like everyone else and showed up roughly 15 seconds later.

But whhhhyyyyy?

Back when Windows 2000 Active Directory was released we were paralyzed with fear that replication traffic would overwhelm networks with massive RPC data storms and everyone would hate us. So Win2000 DC’s took 5 minutes for even intra-site replication to catch up between DC’s. What we found was that replication was low bandwidth already and customers weren’t changing that much data – but when they did change data, they wanted it on all DC’s faster. So intra-site replication became 15 seconds in Win2003 and we started telling everyone through Support cases, MCS engagements, and PFE ADRAPS to turn on change notification inter-site also. This so-called “urgent replication” mechanism was designed to quickly catch up servers for “more important” changes. But since now everything happens in a few seconds it’s mostly pointless overkill and urgent replication no longer gets any new lovin’.

So there you go.

- Ned “don’t forget to turn that logging off when you’re done” Pyle

Comments

  • Anonymous
    August 18, 2010
    Very Nice.  I dont really care much about PSOs today, but this was a good background on how to watch this sort of thing.  I also never really understood the breakdown between win2k's 5 minutes, the urgent and non-urgent 2k3+ traffic! also - if Enable Change Notification is a best practice now, is it enabled by default in win2k8?

  • Anonymous
    August 18, 2010
    If only it were enabled by default, I'd be a happy man. But nope, you still have to go do it. Maybe in Windows 2043...

  • Anonymous
    August 18, 2010
    The comment has been removed

  • Anonymous
    August 18, 2010
    My pleasure, thanks :)

  • Anonymous
    August 18, 2010
    The comment has been removed

  • Anonymous
    August 18, 2010
    If you turned on change notification by default would you worry about the locations with low bandwidth/slow links?     Many locations would have no issues today; and hopefully by Windows 2043 slow links will be a thing of the past.

  • Anonymous
    August 18, 2010
    The comment has been removed