TABLE OF CONTENTS


Password Requirements in Active Directory


A question that we frequently get when using the Enzoic Client app, is "why am I seeing different password policy reasons than I would expect for this user?". Active Directory's password policy settings can be confusing and convoluted especially when it comes to Group Policies. In this article we will hope to shed some light on how these values are calculated, what the Enzoic Client is looking for, and how you can help troubleshoot this in your own environment.


Group Policy and the Default Domain Password Policy


There are multiple places you can configure a password policy in active directory. These are policies that can configure requirements for Minimum Password Length, Minimum/Maximum Password Age, Password Complexity requirements (requiring number, symbols, uppercase, and lowercase characters), and Password History. The "Default Domain Policy" is a built in GPO that is the defacto policy on every new AD Domain and is the one that will typically be enforced unless you have configured another GPO to take precedence which we will get to later. If you are seeing any discrepancies with what you would expect to be enforced for a user vs what you are seeing the Enzoic Client displaying, then this is the first place to look. An important powershell command to know is:


Get-ADDefaultDomainPasswordPolicy


Running this from powershell this will return you the values for whatever policy is viewed as the Default Domain Password Policy, e.g:


In most cases this will be your Default Domain Policy. However, if you have spent time configuring other Group Policy objects, there is a good chance that another Group Policy with a configured Password Policy, is taking precedence over the Default Domain Policy and its password settings are the ones being returned by the above command.


How are Group Policy Password Policies applied?


Now we get to the crux of the problem. Microsoft would say the following information is intuitive, but I think most of us would disagree here. A lot of cases come in with multiple Group Policy password policies configured, but this will not work. A Password Policy configuration lives under the computer settings portion of Active Directory, not the user settings. This means that GPO defined Password Policies will not and cannot apply to user objects or objects like OUs. Only the highest level Group Policy object, linked at the top of the domain, will take effect.


Wait, but my Default Domain Policy isn't being followed!


If you can't tell yet, things can get complicated quickly. There are other things that should also be taken into consideration when expecting a given password policy to be applied to a user. 

  • Is this the only group policy linked at the root of the domain with a password policy setting?
    • Only the GPO with the highlest link order will take precedence in this scenario. You can verify this by looking under the 'Linked Group Policy Objects' tab when selecting the root of your domain in GPMC.msc

  • Is Inheritance blocked on the Domain Controllers OU?
    • If you block inheritance on the Domain Controllers OU, then NO password policy settings from policies linked at the root of your domain will be applied. Any changes you make to your Default Domain Policy, will NOT be applied to password changes. The ways around this are to either:
      • Remove blocked inheritance from the Domain Controllers OU
      • Mark the Group Policy Password Policy at the root of the domain as 'Enforced'. Marking it as enforced will override any blocked inheritance set.

  • Have you updated your group policy settings?
    • A simple but easy thing to miss is to make sure that you run the following command after any group policy setting changes. Without running this it is highly likely that you will not see any of your changes.
      gpupdate /force

  • Do you have any Fine Grained Password Policies in place?
    • Introduced with Server 2008, Windows created the Fine Grained Password Policy feature. This finally gave admins the power to set granular, user-level password policies like how they had expected the Group Policies to work. FGPPs, as they are commonly referred to, ALWAYS take precedence over any Group Policy. Keep reading for more info.



How can I set up Fine Grained Password Policies?


Great question! FGPPs can be configured in a variety of ways; through the AD Administrative Center snap in, using ADSIEDIT, or they can be configured with powershell commands. 

These password policies live in AD under the <Domain>\System\Password Settings container. You can also view them from any of the above mentioned places as well. If you wish to see which FGPP is applying to which user you have a few options.

  1. You can see all of the FGPPs via powershell by running the following command and then cross reference the 'AppliesTo' field with user's memberships.
    Get-ADFineGrainedPasswordPolicy -filter *

  2. You can also just query which policy is the resultant password policy object (RSoP) for a user. This value is stored in the AD attribute namedmsDS-ResultantPSO. If this command returns nothing for a given user, then it is safe to assume that the user is NOT under the influence of any FGPP. If you are seeing password requirements being enforced during password changes for a user then it would be wise to look at your Group Policies.

    Get-ADUserResultantPasswordPolicy

Of course, with everything there is a caveat! FGPPs ONLY apply to individual users OR Global Groups. Always double check to make sure your FGPP is being applied as you would expect after creating them for the best end user experience.


Useful Links