Where did the user blocking policy go?

At one point, the administrator decides to make sure that the user blocking policy works on all domain controllers. On the domain controller, rsop.msc runs and gives the administrator the expected picture:

But on the second admin server, a light shock lurks:

It is worth noting immediately that all servers are in “ou = Domain Controllers” and the same policies apply to them. OS controllers: 2008 R2.

I propose to make this little Friday's riddle.


')
The first thought, that in some way the policy was not applied, is immediately dismissed by issuing summary data on the team

gpresult /R 

The set of applied policies for all controllers is the same.

The morale is finally undermined by the following command:

 gpresult /Z /S ad2 

does not mention anything about the “Account Lockout Policy” section. At the same time for the first controller

 gpresult /Z /S ad1 

lists the section "Account Lockout Policy" with all the parameters.

Check your controllers - you may be surprised at the result .
The most interesting thing is that the policy works! If you try the specified number of times to make a failed entry through the second controller (for example, using an LDAP bind), the user is blocked.

I suggest that the community, in the comments, set forth its versions of the reasons for what is happening, as well as suggestions on how to test the performance of the user's blocking policy.

In the evening I undertake to lay out the answer to this question in any case.

UPD. Judging by the number of assumptions in the comments and by voting for this post - the topic is not interesting and it will not be possible to arrange a discussion with “drawing out” the nuances of AD. It is a pity, perhaps I would have discovered something new for myself.

Since I promised to post the answer

There is a document KB927908 in which it is described that on domain controllers running 2003 the RSoP server does not display the established values ​​of the part of the policies, namely:
Policies in Computer Configuration / Windows Settings / Security Settings / Account Policies / Password Policy:

• Enforce password history
• Maximum password age
• Minimum password age
• Minimum password length
• Password meet meet requirements
• Store password using reversible encryption for all users in the domain

Policies in Computer Configuration / Windows Settings / Security Settings / Account Policies / Account Lockout Policy:

• Account lockout duration
• Account lockout threshold
• Reset account lockout counter after

Policies in Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options:

• Network Security: Force logoff when logon hours expire

in practice, I observed the described problem on both 2008 and 2008 R2 servers.
It also indicates that you can use the command line utility to view the current policy on domain controllers without the role of the PDC emulator:

 net accounts /domain 

Features of applying policies on DC

Regarding the peculiarities of the policy of blocking users, you should also read document KB259576 , which says that some of the settings on domain controllers are applied only from policies that are tied to the domain root. And the user blocking policy is included in this list.

What is the special role of the PDC emulator in applying user blocking policies?

First of all, how the policy is implemented - in fact, when determining the criteria for blocking a user, DC takes parameters from the attributes of the domain object.

So when applying the policy, these values ​​in the attributes are set by the controller with the role of the PDC emulator.
About this you can read an interesting detective story .

Perhaps this is why RSoP does not display this policy on other controllers — they do not need it — they have parameters in the directory.