GPResult/RSoP reports missing *some* settings from the Default Domain Policy (GPO) on a particular domain controller

MMcDonald
MMcDonald used Ask the Experts™
on
Hello Experts!  I have another strange one for ya.  Hope you can help.

While working on my test 2003 AD domain, I noticed something really odd.  I was running the Group Policy Results to compare some settings between the 2 DCs, and I noticed that DC2 is completely missing chunks of settings from the Computer Configuration/Windows Settings/Account Policies section, which are configured within the Default Domain Policy GPO.

The following settings/sections are missing:  Account Policy/Password Policy as well as the Account Lockout Policy.

The only settings/section from the policy that are showing up, are the Account Policies/Kerberos Policy settings.

I get the same results if I run the command line GPResult tool, or Group Policy Results from within GPMC.

If I open up the Domain Security Policy mmc snap-in from Administrative Tools on DC2, the settings are configured as they should be.  Unfortunately I'm wondering if this snap-in is just reading the actual Default Domain Policy settings from the GPO.

Additional oddity:  If I disable the Default Domain Policy entirely and GPupdate, the section from that GPO that does show up on DC2 (i.e., Kerberos Policy) goes away, as expected!!  When I re-enable the policy, the Kerberos Policy section of the GPO returns in my GPResults.  It's clear DC2 is processing the policy.  In fact, GPResult does indeed show the policy was applied successfully.

In attempting to fix the problem, I went as far as demoting this DC.  When it was a standard member server on the domain, GPResult showed all settings from the GPO applied!!  I repromoted it as a DC and they went away again except for the Kerberos Policy section!!

What on earth could be causing this?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
This is normal. The Account password and lockout policies are actually written to the domain, not individual computers and servers (if the policies are attached directly to the domain, as is the case with Default Domain Policy). This is because the password and lockout policies are for the domain at that level and the policy changes take place at the domain level. The changes are actually written to the Domain Schema in this situation and not visible in local policy on local computers.

Author

Commented:
@acBrown2010, thanks for your quick response, but I think you are confused about my problem.

When I run GPResult on DC1, the correct GPO settings show as applied (all settings from the GPO).  When I do the same on DC2, *some* of the GPO settings are missing ENTIRELY from the results, as if they don't exist.  Other parts of that same GPO show as applied, as expected.

On a side note:
I think you're slightly mistaken.  We have the account password/lockout policies applied at the Default Domain Policy GPO level.  As such every machine on the domain would inherit these settings, including member servers.  This was done to prevent users from creating local accounts with unsafe passwords.  In this case, GPResult would show these settings as applied on any machine.  In fact, as stated above, when I demoted DC2 to a member server, GPResult showed those settings.  When I repromoted it, they went away again.

Now If I had applied the settings via the Default Domain Controllers Policy, then the settings would only apply to the DCs, and as a result only affect domain user accounts. I think this is what you are referring to, however, my issue still exists as one DC shows them, whereas the other does not.
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
Actually, linking a Password Policy to the Domain Controllers OU does absolutely nothing. Password policy must be set at the domain level. Setting password policy in a GPO linked to any OU will only affect local users of computers that fall under the scope of the policy. Domain Controllers have no local users and are thus unaffected by a password policy GPO that is linked to the Domain Controllers OU. This is why the Password Policy is set in the Default Domain Policy by default.
11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

Author

Commented:
@acbrown2010

My GPO is not linked at the DC OU.  It is linked at the domain level.  You are focused on something that is not part of my issue.  Thanks anyway.

Author

Commented:
Btw acbrown2010, your logic for the password policy is slightly flawed.  I'd like to reference you to a KB article, just for a piece of info it contains about where the password policy applies.  Granted the article is for Windows 2000 but the information is the same for 2003.

http://support.microsoft.com/kb/269236

Quoted for convenience:  In Windows 2000, password policies are read-only at the domain level. The policy must be applied to the domain controllers for the policy to be applied. If you initiate a password change for a domain password from anywhere in the domain, the change actually occurs on a domain controller.

While the policy is typically applied at the domain level, this policy is inherited by the domain controllers.  While DCs do not have local accounts, in the normal sense of the word, all domain accounts are stored on the DCs.  As such, the password policy must apply to the DCs in order for those accounts to be bound by them.
Senior Systems Admin
Top Expert 2010
Commented:
http://support.microsoft.com/kb/255550

"Because domain controllers do not have local accounts as servers and workstations do, account policies that are defined in the default domain controller's organizational unit have no effect."

Blocking policy inheritance on the Domain Controllers OU keeps them from properly applying the domain level password settings.

At any rate, I just ran GPResult on both domain controllers in my test environment and got the exact same results as you did. The reason for this is that the password policy only shows up in GPResult if the domain controller you run it on holds the PDC emulator role. If you want to test this, transfer PDC Emulator role to your secondary DC, run GPUpdate, then GPResult. This is *by design* because a part of the PDC Emulator's job is to manage password policies. If you run GPedit.msc on your secondary DC, prior to changing the PDC emulator, you'll also see that it *does* in fact pick up the password policies.

Author

Commented:
Hmm.. that's interesting.  MS KB articles conflicting with each other.  :)

At any rate, I think you've nailed the issue that I care about.  Is there any documentation that shows why this information only shows on the PDC emulator?

Author

Commented:
BTW, I have confirmed by moving PDC role to the other server.  Now the results show on DC2, but not on DC1.  THANK YOU!  I would just now like to know why this is.
Adam BrownSenior Systems Admin
Top Expert 2010
Commented:
Best I can give you is the following: http://www.petri.co.il/understanding_fsmo_roles_in_ad.htm

Essentially, the PDC Emulator manages a few different things on the domain, but the one that matters in this context is its preferential treatment in the case of password resets and its management of account lockout. Any account that is locked out on the domain is locked by the PDC emulator directly. When passwords are reset, the reset is replicated directly to the PDC emulator, and all failed login attempts are forwarded to the PDC Emulator for final authorization before failing. In essence, the PDC Emulator controls all the password management and as such is the only system that *needs* to have the domain password policy applied to it.

Also, the apparent conflict between the two KB articles isn't really a conflict, as there is a great technical difference between the DC OU inheriting the Password policy from the Domain level and directly linking it to the OU. I originally thought that the Domain Password settings were applied to the schema, since I thought I had seen some entries in a few schema objects for it. Apparently I was mistaken in that. From what I can tell of my testing and the results, it seems the PDC emulator is capable of determining when the Password policy is set at the domain level and applying it, but it must be able to inherit the policy from the domain before it can do this. To confirm this I'd probably need to spend hours digging through AD white papers which is almost better than Valium for getting to sleep.

Author

Commented:
Thanks acbrown2010!  While I still don't understand 100% of why it is how it is, at least I understand the issue now.  Thanks again.

Author

Commented:
Interesting note:  I found another setting that seems to hide on non-PDC emulator DCs.

•Local Policies/Security Options/Network Security -> Network Security: Force logoff when logon hours expire.

There are other settings defined in the Network Security section that shows up on all DCs.  Just that one above seems to hide.  Very odd.

Author

Commented:
Just wanted to update.  Someone on a thread I was posting to posted a KB article explaining this issue.  http://support.microsoft.com/kb/830748

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial