none
[2008 R2] Password does not meet complexity requirements, but they're disabled!!

    Question

  • Prior to firing off a quick response, please read the entirety of my post to understand this may not be as easy a solution as it sounds.

    On a Windows Server 2008 R2 Active Directory domain, I have users within containers that were once receiving enforced complexity requirements from a default domain policy so "Password must meet complexity requirements" was set to 'Enabled' and "Minimum password length" was set to '6 characters'.

    Those complexity requirements were relaxed from head office so I set the policy setting to 'Disabled' and '1 characters'.

    Unfortunately some users were still unable to set a non-complex password.

    • I evaluated all other group policies and I found no reference to complexity lengths in any of the other policies.
    • I created a new container with a group policy that set the complexity requirements to 'Disabled' and min length to '1 character', I blocked inheritance and I moved the afflicted users and their PC's into this container.
    • I adjusted the 'Default Domain Controllers Policy' complexity requirements to 'Disabled' and min length to '1 character'.

    And even after doing all that, users cannot change to non-complex passwords and I cannot set non-complex passwords from the server.

    Can anyone advise how this setting is still taking effect?

    Saturday, August 17, 2013 2:53 PM

Answers

  • Please run gpresult on affected user computer with elavated command promt wich help you to verify what GPO is applied to the computer/user

    Command : gpresult.exe /h c:\nameofyourreport.html

    So now check the GPO report wich will provide  enough information to hopefully track it down. So check the report whether password GPO is applied ?was it denied? You can get some of this in the Event Log, but it is usually easier to check your gpresult.exe output since both pieces of information should be there. If it didn’t apply or got denied, check the Event Log for more information about why the GPO didn’t apply or was denied.

    • Marked as answer by williamgault Sunday, August 18, 2013 4:42 PM
    Saturday, August 17, 2013 6:41 PM
  • Hello,

    it sounds for me that you configure the password settings on OU level and NOT on the domain level? The password and account lockout settings MUST be configured on domain level ONLY and can be changed with FGPP(fine grained password policy) for users.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    • Marked as answer by williamgault Sunday, August 18, 2013 4:42 PM
    Sunday, August 18, 2013 10:45 AM

All replies

  • A couple of things to check:

    * Have you run gpupdate /force on all the DCs and the the affected users workstations?
      * Have you check for a workstation --> Local Computer policy -> Password enforcing policy?

    Sorry for the quick response but, we sometimes forget about simple things.


    Ricardo Fuentes A+ MCP MCDST MCTS MCITP

    Saturday, August 17, 2013 3:59 PM
  • Yes, the DC's have been gpupdate /force many times and the users / workstations have been gpupdate /sync'd and /force'd many times as well.

    There are no local computer password policies, nothing is assigned per-computer, it's all GPOs.

    Saturday, August 17, 2013 5:16 PM
  • Please run gpresult on affected user computer with elavated command promt wich help you to verify what GPO is applied to the computer/user

    Command : gpresult.exe /h c:\nameofyourreport.html

    So now check the GPO report wich will provide  enough information to hopefully track it down. So check the report whether password GPO is applied ?was it denied? You can get some of this in the Event Log, but it is usually easier to check your gpresult.exe output since both pieces of information should be there. If it didn’t apply or got denied, check the Event Log for more information about why the GPO didn’t apply or was denied.

    • Marked as answer by williamgault Sunday, August 18, 2013 4:42 PM
    Saturday, August 17, 2013 6:41 PM
  • Hello,

    it sounds for me that you configure the password settings on OU level and NOT on the domain level? The password and account lockout settings MUST be configured on domain level ONLY and can be changed with FGPP(fine grained password policy) for users.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    • Marked as answer by williamgault Sunday, August 18, 2013 4:42 PM
    Sunday, August 18, 2013 10:45 AM
  • Please run gpresult on affected user computer with elavated command promt wich help you to verify what GPO is applied to the computer/user

    Command : gpresult.exe /h c:\nameofyourreport.html

    So now check the GPO report wich will provide  enough information to hopefully track it down.

    This is a good suggestion and it's along the same lines of Ricardo's suggestion to check the simpler things first. It's quite possible that a GPO was edited by an administrator and it's not fully applying all the settings as it's common when a glitchy GPO hits a setting that it can't apply, it stops trying to apply all the other settings. I'll get back to you on this shortly, I think you hit the nail on the head here...
    Sunday, August 18, 2013 4:30 PM
  • it sounds for me that you configure the password settings on OU level and NOT on the domain level? The password and account lockout settings MUST be configured on domain level ONLY and can be changed with FGPP(fine grained password policy) for users.


    You may have lead me to my issue - I went to re-evaluate the domain level settings and they've reverted to their original settings with complexity requirements 'Enabled' so I have a feeling that someone higher up the chain has made it so regional IT admins cannot save settings even if they've changed them. I just tested this again by undoing complexity settings at the domain level and they were reset when I loaded the GPMC again.
    Sunday, August 18, 2013 4:42 PM