Welcome to TechNet Blogs Sign in | Join | Help

Ask the Directory Services Team

Microsoft's official Enterprise Platform Support DS blog

News

  • Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.

    Locations of visitors to this page
Fail to log Security Settings from Default Domain Policy

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

Posted: Monday, September 22, 2008 12:15 PM by NedPyle

Comments

BlogMS - Official Microsoft Team Blogs said:

196 Microsoft Team blogs searched, 97 blogs have new articles in the past 7 days. 218 new articles found

# September 30, 2008 9:19 AM
Anonymous comments are disabled
Page view tracker