none
How come I'm allowed to create different password policies in Group Policy?

    Question

  • I need some help and I can't believe I can't find anything online about this particular matter. According to Microsoft, within Group Policy, you can only have one password policy per domain and it must be applied to the root of the domain (e.g., default domain policy). Fine grained password policies aside, you should only be able to have one password policy per domain. However, during testing, I am able to create different GPOs with different password settings and apply them to different OUs containing computer accounts (I'm only testing because this is the setup of the environment I am auditing). It seems that the password settings are getting applied from the GPOs assigned to the OUs and depending on what computer I'm logged on to, when I change my password, it must meet the complexity standards of that particular GPO assigned to the computer I'm logged on to. How can this be? I was always under the impression that you can only have one password policy per domain and it has to be assigned to the root of the domain and the only way to create multiple policies was through Fine Grained Password Policies. What am I missing here? What can be a negative to assigning different password policies via GPOs to different OUs containing computer accounts? Thanks all.
    Wednesday, June 8, 2016 4:48 PM

Answers

  • > Why do GPOs with password settings applied to OUs containing computer
    > accounts successfully apply to the computers and override the password
    > policy that is applied to the root of the domain?
     
    They do not override them...
     
    PW Policies linked to the domain: Processed by the PDC emulator - and
    ONLY the PDC emulator. No other computer in the domain will process PW
    policies linked to the domain.
     
    PW policies linked to OU=Domain Controllers: Ignored. No DC will process
    PW policies except the PDC, and the PDC will only process PW policies
    linked to the domain, nowhere else.
     
    PW policies linked anywhere else: Processed by member computers - and
    apply to local accounts on these members only
     --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Thursday, June 9, 2016 8:03 AM

All replies

  • For domain users, the policy is processed at the domain controller (which is why the setting is a computer setting - the DC handles it). The domain controllers will process only one password policy and it has to be linked to the domain. If you have multiple password settings applied at the domain level, the highest individual GPO will take effect.

    If my answer helped you, check out my blog: Deploy Happiness

    Wednesday, June 8, 2016 5:39 PM
  • Thank you. Why do GPOs with password settings applied to OUs containing computer accounts successfully apply to the computers and override the password policy that is applied to the root of the domain? Take the following example, there is a password policy applied to the root of the domain that says passwords must be at least 5 characters. There is also a password policy applied to an OU that contains computer accounts that forces passwords to be at least 10 characters. If you run an rsop on a computer in that OU, it would tell you that the password must be at least 10 characters. If you are logged in with a domain account and attempt to change your password on that computer to a password with a length of 7 characters, it would tell the user the password doesn't meet complexity requirements even though the password policy applied to the root of the domain only says passwords need to be 5 characters. You could also create another password policy and apply that to a different computer OU at the same level as the other one and those computers would get a different policy. So I know this works, I'm just curious why this works when Microsoft says it shouldn't and what are the risks and/or configuration errors that could occur if you setup your password policy this way.
    Wednesday, June 8, 2016 7:38 PM
  • > Why do GPOs with password settings applied to OUs containing computer
    > accounts successfully apply to the computers and override the password
    > policy that is applied to the root of the domain?
     
    They do not override them...
     
    PW Policies linked to the domain: Processed by the PDC emulator - and
    ONLY the PDC emulator. No other computer in the domain will process PW
    policies linked to the domain.
     
    PW policies linked to OU=Domain Controllers: Ignored. No DC will process
    PW policies except the PDC, and the PDC will only process PW policies
    linked to the domain, nowhere else.
     
    PW policies linked anywhere else: Processed by member computers - and
    apply to local accounts on these members only
     --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Thursday, June 9, 2016 8:03 AM
  • Hi Jwcblc,

    Thanks for your post.

    Are there any updates?

    For domain accounts, there can be only one account policy per domain. The account policy must be defined in the Default Domain Policy or in a new policy that is linked to the root of the domain and given precedence over the Default Domain Policy, which is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from a Group Policy object (GPO)linked to the domain, which by default is the Default Domain Policy GPO. This behavior occurs even if there is a different account policy applied to the organizational unit (OU) that contains the domain controller.

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, June 22, 2016 7:03 AM
    Moderator