I'm using a Server 2008 R2 domain controller, trying to troubleshoot a bug where password complexity requirements seem to be enabled, even though they are disabled in group policy. Some notes:

  • I am changing the Password Policy at the domain level
  • I have set no password age, set length requirement to a low number, and disabled complexity requirements, but I still am required to submit a complex password
  • Local secpol settings are the same, although I don't think they should be taken into account
  • I have ran gpupdate with the /force option and rebooted the system
  • RSOP says the complexity requirement should be disabled.

I'm not sure if my GPO is not being applied (although RSOP says it is), or if there is another setting that is enabled (all my searching doesn't indicate one).

Any help would be appreciated.

Edit: Another odd thing: I booted into Active Directory Restore Mode to try to change the password of the local administrator account, and there is a complexity requirement on those local accounts also! Running secpol.msc from ADRS shows complexity should not be required, so I don't think it's an Active Directory problem or really a WIndows Security Policy thing. Perhaps something was corrupted? Unfortunately it doesn't seem like there's an easy way to see exactly what SAM (or LSASS?) is looking at to determine that complex passwords are required. Doesn't make any sense.

  • Was password complexity required by GPO in the past and has since been changed to Not Defined? Commented Jul 10, 2015 at 18:29
  • It's possible, but the GPO I've got linked now defines all the settings and is being applied at the domain level so I'd be surprised if tattooing could be hurting me now.
    – prelic
    Commented Jul 10, 2015 at 18:31
  • 2
    Is this defined in the Default Domain Policy?
    – joeqwerty
    Commented Jul 10, 2015 at 18:43
  • Confirm that the settings appear in the output of gpresult /h gpresult.html from an elevated command prompt on the domain controller.
    – Greg Askew
    Commented Jul 10, 2015 at 18:59
  • @GregAskew - Yes they show in gpresult as applied (complexity disabled).
    – prelic
    Commented Jul 10, 2015 at 19:14

2 Answers 2


Check if you have custom password filter installed.

Key: HKLM\System\CurrentControlSet\Control\LSA  
Value: Notification Packages  

Normally when a custom password filter is not installed, it will have: scecli rassfm

Installing and Registering a Password Filter DLL

  • BINGO! An additional password filter was loaded! Thanks so much! Will award bounty when enabled!
    – prelic
    Commented Jul 13, 2015 at 17:29

Domain based Account Policies are applied from the Default Domain GPO. If you're configuring them in another GPO then that GPO must be linked at the Domain level and must have a higher precedence than the Default Domain policy.

Because Account Policies are Computer Configuration settings they affect the local security account database on the machines that are affected by the settings, which in a domain is the AD database on each Domain Controller. So when you make changes to your Domain based Account Policies you need to refresh Group Policy on your Domain Controllers before you'll see their effect on Domain users.

  • My default domain policy is disabled, but the account policy GPO is the highest precedence on my domain-level list. By "refresh Group Policy", do you mean gpupdate?
    – prelic
    Commented Jul 10, 2015 at 19:11
  • This seems to be the prevailing answer I've found (make sure the policy is applied in the default domain policy or in a policy at the domain level), but this does not solve the problem, and complexity is still required.
    – prelic
    Commented Jul 11, 2015 at 22:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .