none
FGPP created but PSO seems like it is not applied

    Question

  • I am running a native 2012R2 domain and forest with the forest and domain level being that of 2012 R2.  I have created a Fine-Grained Password Policy via the AD Admin center and have it applied to a single test user. There is only one PSO applied to this user and this is the only PSO in the directory. When querying the user via "dsget user <User-DN> -effectivepso" the correct PSO is applied for that user. When looking at the user attribute of msDS-ResultantPSO it also shows the correct PSO is being applied. The PSO disables password complexity, however whenever I try and reset the test user account via aduc or the as admin center tools the operation fails stating "Failed to reset the password for test user. The password does not meet the length, complexity or history requirements of the domain". I have removed all other requirements in the PSO for length, history, etc in a basic attempt to confirm that the PSO is being applied, but I am unable to reset the user password to anything less than what is specified in the default domain policy (which includes complexity). I have waited for replication (within this one site only) and also rebooted the domain controllers with no change to this behavior.

    Is the PSO only read and applied when the user is actually logged in within their context and when changing a password? Is the failure of being able to administratively reset the account in question to a password that complies with the PSO attached to that user operating by design?

    I will be logging in with that test user account to see if this interpretation is true, but I would appreciate any insight for anyone with experience with this situation can give. 

    Thanks,

    Brian


    Monday, January 12, 2015 5:28 AM

Answers

  • Hi Brian,

    I have tested this in my testing environment, it turns out that my test PSO takes higher precedence than the default domain password policy settings.

    To be more specifically, I have configured the minimum password length of test PSO to 9 and 7 in default domain password policy, the test PSO only applies to one user account. The results are I cannot change its password to 7 characters long, but I can set the exact same password to another user in the domain.

    Would you tell us that how did you set the precedence for the PSO? In addition, are there multiple PSOs configured? Which users does the PSO apply to?

    Best Regards,

    Amy


    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.

    Thursday, January 15, 2015 9:02 AM
    Moderator

All replies

  • Update...

    I am unable to change the password as the user without any complexity. I made a change to the PSO and now am requiring a 10 character minimum length. When trying to use a password that meets the complexity and length requirement as defined in the default domain GPO, I am unable to set the user's password to that mix of criteria. However, if I use a password that is now 10 characters in length and has complexity it takes the password without error. When trying to set the password to one of a 10 character value without meeting complexity however it still returns an error. 

    I would summarize my working hypothesis as this:

    The PSO complexity setting and password length setting acts more like a GPO setting with a choice of enabled or not enabled. If set to not enabled (as in my case for complexity), it seems it still applies the default domain password policy and then overlays any changes to the password settings specified in the PSO. Since the PSO does not have a "disabled" checkbox (only and unchecked enable), it is not overriding the values as read by the default domain policy.

    This could just my mistake, but I did not see any best practices or other documentation stating that if you use PSO in your AD then it is necessary to remove the password settings in the default domain policy and recreate a PSO so that one PSO may be applied to each user (not one for each user, rather one for each type of requirement that you would apply (with complexity, without complexity) so every user account has a PSO applied rather than relying on the default domain policy. I found quite the opposite, stating it is best practice to have as few PSO objects as possible in the directory.

    So, my original question still stands (although with an updated understanding of what I think it is trying to do)....is this behavior by design? Can anyone that uses PSOs weigh in and confirm that if you have something less restrictive than the password settings defined in the default domain policy that it was necessary to not define those settings there and instead move those settings to their own PSO?

    Thanks,

    Brian


    Monday, January 12, 2015 5:14 PM
  • Hi Brain,

    I will test this and get back to you after complete the test.

    Best Regards,

    Amy


    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.

    Tuesday, January 13, 2015 6:22 AM
    Moderator
  • Hi Brian,

    I have tested this in my testing environment, it turns out that my test PSO takes higher precedence than the default domain password policy settings.

    To be more specifically, I have configured the minimum password length of test PSO to 9 and 7 in default domain password policy, the test PSO only applies to one user account. The results are I cannot change its password to 7 characters long, but I can set the exact same password to another user in the domain.

    Would you tell us that how did you set the precedence for the PSO? In addition, are there multiple PSOs configured? Which users does the PSO apply to?

    Best Regards,

    Amy


    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.

    Thursday, January 15, 2015 9:02 AM
    Moderator