none
NT AUTHORITY\SYSTEM Modified Default Domain Policy RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    1
    Sign in to vote

    We changed our account lockout policy back in March and our password policy the first week of April. Today, we realized the changes weren't being enforced and when reviewing the settings in the default domain policy, we noticed the password and account lockout policy settings were reverted back to the original values we had set for years. After some research we found that the computer account (NT AUTHORITY\SYSTEM) on our PDC modified the settings one week to the day after we modified the password policy. No AD restore was done.

    What would cause the computer account on the PDC to change the password policy and account lockout policy settings back to the original settings we've been using for years?

    I've been combing through logs, forums, blogs, etc. for hours looking for an answer to this and no luck as yet, so I'm hoping someone on here may have some insight.


    • Edited by MsBrowning Thursday, May 24, 2012 6:45 PM
    Thursday, May 24, 2012 6:45 PM
    |

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    How many DC do you have in your Domain?

    Modify Password Group Policy settings in one DC and check GPO status in another DC, make sure modifications can be replicated successfully.

    > we noticed the password and account lockout policy settings were reverted back to the original values we
    > had set for years.

    Do you mean revert to system default values or your defined values?

    Run below command and check the result:

    At the command prompt, type below commend, and then press ENTER

    secedit /refreshpolicy user_policy /enforce

    At the command prompt, type below commend, and then press ENTER

    secedit /refreshpolicy machine_policy /enforce

    For more information please refer to following MS articles:

    Using SECEDIT to Force a Group Policy Refresh Immediately
    http://support.microsoft.com/kb/227302


    Lawrence

    TechNet Community Support

    Friday, May 25, 2012 6:55 AM
    |
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Similar this has happened to me as well... The values also appear to have reverted back.

    Alan Burchill (MVP)
    http://www.grouppolicy.biz

    @alanburchill

    Sunday, May 22, 2016 9:54 PM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    Drum roll... The answer is, if someone changed the local secuirty policy setting on a local DC (e.g. net command to change the password account lockout). Then this change will be pushed into the default domain GPO so that the password policy is then consistent for the entire domain.

    Moral of the story is, dont try to modify the local security policy on any domain controllers, as this could trigger it to be pushed out to the entire domain.

    Hope it helps.

    Alan Burchill (MVP)
    http://www.grouppolicy.biz

    @alanburchill

    • Proposed as answer by Alan Burchill Monday, May 30, 2016 11:25 PM
    Monday, May 30, 2016 11:24 PM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote
    > Moral of the story is, dont try to modify the local security policy on
    > any domain controllers, as this could trigger it to be pushed out to the
    > entire domain.
     
    Better Solution: Do not modify the Default Domain Policy but create your
    own and link it above the DDP :-))
     
     
    Thursday, June 2, 2016 10:47 AM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote
    So, I don't have anyone confessing to manually setting password policy via secpol or net on a DC.  Cowards.  How do I undo their damage?  It feels like if I repeat their error to put my desired password policy in place, I'll cause a problem for the future admins.
    Wednesday, September 25, 2019 7:04 PM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote
     
    Better Solution: Do not modify the Default Domain Policy but create your
    own and link it above the DDP :-))
     
     

    Late entrant to the discussion, but I would actually argue against this point.

    Use the Default Domain Policy for these settings:

    1. It is a kindness to any successor -- they don't have to do the math/logic to determine where it is in your environment at anyway (though, adminittedly, it should be really easy to find as the true domain-wide password policy really can only be linked at the domain).
    2. The Native AD Cmdlet Set-ADDefaultDomainPasswordPolicy works with password settings in this GPO only.
    Wednesday, October 23, 2019 3:16 PM
    |