1

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.

13
  • Was password complexity required by GPO in the past and has since been changed to Not Defined? – Todd Wilcox Jul 10 '15 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 Jul 10 '15 at 18:31
  • 2
    Is this defined in the Default Domain Policy? – joeqwerty Jul 10 '15 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 Jul 10 '15 at 18:59
  • @GregAskew - Yes they show in gpresult as applied (complexity disabled). – prelic Jul 10 '15 at 19:14
2
+50

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
https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766%28v=vs.85%29.aspx

1
  • BINGO! An additional password filter was loaded! Thanks so much! Will award bounty when enabled! – prelic Jul 13 '15 at 17:29
3

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.

2
  • 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 Jul 10 '15 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 Jul 11 '15 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.