Compartilhar via

Fail to log Security Settings from Default Domain Policy

  • Artigo

Hello everyone, Scott Goad here, and today I want to take a few minutes and talk about a recent case where we fail to log security settings from the Default Domain Policy. In this case, we had a small environment with 2 domain controllers, one holding all of the FSMO roles, the other a replica domain controller.

The issue was noticed during an internal audit, and the customer noticed that certain security settings were not logged when you run GPRESULT /v, which normally details the resultant set of policies for the particular user and computer. To troubleshoot the issue we began gathering data, and sure enough, some items that were specified in the Default Domain Policy were skipped, and no errors were logged.

We could even demote the Domain Controller down to a member server, and policy would apply and report correctly.

Here’s a piece from each domain controller:

….snippet from GPRESULT on DC1 (non FSMO holder)….

        Account Policies
  ----------------             GPO: Default Domain Policy
                Policy: MaxServiceAge
                Computer Setting: 600             GPO: Default Domain Policy
                Policy: MaxTicketAge
                Computer Setting: 10             GPO: Default Domain Policy
                Policy: MaxClockSkew
                Computer Setting: 5             GPO: Default Domain Policy
                Policy: MaxRenewAge
                Computer Setting: 7 ….snippet from GPRESULT on DC2 (holds FSMO roles)….

 

 

 

 

 

   Account Policies
   ----------------

            GPO: Default Domain Policy
                Policy: MaxServiceAge
                Computer Setting: 600

            GPO: Default Domain Policy
                Policy: MaxTicketAge
                Computer Setting: 10

            GPO: Default Domain Policy
                Policy: MinimumPasswordAge

Computer Setting: 1

            GPO: Default Domain Policy
                Policy: PasswordHistorySize

Computer Setting: 6

            GPO: Default Domain Policy
                Policy: LockoutDuration

Computer Setting: 4294967295

            GPO: Default Domain Policy
                Policy: ResetLockoutCount

Computer Setting: 30

            GPO: Default Domain Policy
                Policy: MaxClockSkew
                Computer Setting: 5

            GPO: Default Domain Policy
                Policy: MinimumPasswordLength

Computer Setting: 8

            GPO: Default Domain Policy
                Policy: LockoutBadCount

Computer Setting: 3

            GPO: Default Domain Policy
                Policy: MaximumPasswordAge

Computer Setting: 90

            GPO: Default Domain Policy
                Policy: MaxRenewAge
                Computer Setting: 7

Also, on both Domain Controllers, we logged Event ID 1704:

image image

At this point, we looked at the Default Domain Policy, and the settings were there:

image

After investigating the issue further, we decided to look at the local security policy, and see what was actually getting applied. Below is a piece that was failing, according to GPRESULT:

image

image

These screenshots were taken from different servers, after we made the changes in the policy. At this point, we know that we applied the settings, but we are not logging this anywhere. We asked our friends at the Global Escalation Services (GES) Team to take a look. They asked us to move the PDC emulator role to the other DC, and see if the behavior changed. It did! The policy settings in GPRESULT followed the PDC emulator role.

GES reviewed the code and this is a by design behavior. The PDC emulator, member servers and domain-joined workstations apply these settings through group policy. Replica domain controllers for a domain apply these settings by monitoring what is present on the domain naming context head. These settings are replicated via Active Directory replication between the domain controllers of each domain in a forest. These settings are looked at by the domain controllers to help govern some aspects of how they behave. If these settings are changed somehow, the change is replicated and then immediately noticed by the receiving DC and the new behavior takes effect. Here is the full list of attributes:

  • minPwdAge
  • pwdHistoryLength
  • lockoutDuration
  • lockOutObservationWindow
  • minPwdLength
  • lockoutThreshold
  • maxPwdAge
  • pwdProperties (this is complexity on/off)

These settings can be viewed in LDP, as seen in the snippet below:

Expanding base 'DC=adatum,DC=com'...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: DC=adatum,DC=com
          3> objectClass: top; domain; domainDNS;
          1> distinguishedName: DC=adatum,DC=com;
          1> instanceType: 0x5 = ( DS_INSTANCETYPE_IS_NC_HEAD | IT_WRITE );
          1> lockoutDuration: 1800;
          1> lockOutObservationWindow: 1800;
          1> lockoutThreshold: 0;
          1> maxPwdAge: 3710851;
          1> minPwdAge: 86400;
          1> minPwdLength: 7;
          1> modifiedCountAtLastProm: 0;
          1> nextRid: 1006;
          1> pwdProperties: 1;
          1> pwdHistoryLength: 24; Until next time,

 

- Scott “Scooter” Goad

Comments

  • Anonymous
    September 30, 2008
    196 Microsoft Team blogs searched, 97 blogs have new articles in the past 7 days. 218 new articles found