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.

prelic
  • 319
  • 1
  • 4
  • 17
  • 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
  • @joeqwerty - default domain policy is disabled, this GPO only contains password policy information, and is applied at the domain level – prelic Jul 10 '15 at 19:15
  • Get-ADFineGrainedPasswordPolicy -Filter {Name -like "*"} | ft Name, Precedence,MaxPasswordAge,MinPasswordLength,ComplexityEnabled -A – Greg Askew Jul 10 '15 at 20:33
  • That doesn't return anything, I guess I don't have any "fine grained password policies" – prelic Jul 10 '15 at 20:59
  • The settings you have changed, did you change them from something to something, or from something to not configured? – Drifter104 Jul 13 '15 at 15:20
  • By now I've tried a lot of different things, but we don't ever change from something to Not Defined. Basically we have a GPO that explicitly enforces strong passwords and another policy that explicitly relaxes policies. I have the relaxed one enabled and the complex one disabled, and RSoP shows this to be true. If RSoP showed that complex passwords were required, that would make sense and I could troubleshoot...but it doesn't...it shows exactly what I think it should show. – prelic Jul 13 '15 at 15:31
  • Is fine grained password configured? This could be over riding your domain password policy. – Jon Jul 13 '15 at 15:07
  • No, unfortunately not. get-adfinegrainedpasswordpolicy returns nothing. Also checked under ADSI – prelic Jul 13 '15 at 15:28
  • I have my password policy defined in a global GPO that is linked above the Default Domain Policy at the top level. Might not be helpful, but that's my configuration that is working. Look into the Fine-Grained Password Policies. Set relaxed at global, and then set the Strong Password requirements to specific Security Groups. – mortenya Jul 13 '15 at 16:40

2 Answers2

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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 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
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
https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766%28v=vs.85%29.aspx

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • BINGO! An additional password filter was loaded! Thanks so much! Will award bounty when enabled! – prelic Jul 13 '15 at 17:29