• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2944
  • Last Modified:

"Bad Pwd Count" attribute not incrementing above "1" for many users

I recently began troubleshooting an issue with our Domain Account Lockout policy which appeared not to be working.  It turns out, that the policy is working and a few accounts will actually get locked out.

However, many of the accounts in my domain never have the "Bad Pwd Count" attribute increment over 1 - no matter how many bad passwords they enter.

Dumping the badpwdcount value for all the users in the domain shows a mix mostly of 0 & 1.
The 0 & 1 values do not correlate with the account's ability to increment the badpwdcount.  (Some 0's & some 1's will increment over 1, while some of each will not increment over 1.)
We are testing the badpwdcount increment with random characters - nothing that should be in the PWD History [N-2] and hence excluded from incrementing the attribute.

I am at a loss to explain why some account have their badpwdcount attribute incremented and some do not.

Any suggestions on further troubleshooting/solutions?

Thanks!
0
VIBT
Asked:
VIBT
  • 6
  • 3
  • 2
2 Solutions
 
McKnifeCommented:
Well... you don't even mention important details like the "reset account lockout counter after" policy. That resets the counter all the time if set.
0
 
VIBTAuthor Commented:
Sorry, here are the account lockout policy specifics defined in a separate policy from Default Domain Policy (applied to "Authenticated Users").  These settings are "Not Defined" in the Default Domain policy.  We experienced the same behavior when the settings were in the Default Domain Policy.

Account Policies/Account Lockout Policy
    Policy                                                       Setting
Account lockout duration                      22 minutes
Account lockout threshold                     7 invalid logon attempts
Reset account lockout counter after    22 minutes
0
 
McKnifeCommented:
To complete your reply: so you are sure your effect cannot be due to the counter reset that comes after 22 minutes?
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
VIBTAuthor Commented:
When we do our testing for this, we actively watch the counter with the lockoutstatus.exe tool from microsoft.

We will do several "passes" in a row.  Each pass consists of one bad password attempt and a rescan with the lockoutstatus tool to show the updated badpwdcount.  We test at least 3 passes, but have tested 15 passes in well under the unlock threshold.  The accounts that do not increment over "1" remain at "1" even after the reset counter time frame has passed.

The user I had tested right before I first posted this question at 11:52 showed the count at "1".  Refreshing now at 2:15 shows the count still at "1".
0
 
gjeff80Commented:
I am working with MS PSS right now on this same exact issue.  We have the same issue going on right now.
0
 
VIBTAuthor Commented:
That is good to know that we are not the only ones having the issue.  I also have opened a case with Microsoft.  I have had several remote sessions with them over the last 2 weeks and they have now engaged several tech leads to see if they can resolve it.

If you get a resolution on this, please post it here.  I will do the same.
0
 
gjeff80Commented:
So i ended up finding what was causing this problem in our domain..   Are you by chance running 2008 for your domain level?  Someone went and created a Fine Grained Password policy in our domain which ended up being configured incorrectly and it was taking precedence over the domain policy.  You can check this through Active Directory Administrative Center (or by drilling through ADSIEDIT.MSC).  Once we deleted the bad policy our badPwdCount started incrementing again.
0
 
VIBTAuthor Commented:
We are running 2008 for the domain level and I looked online for instructios for creating a PSO.

http://technet.microsoft.com/en-us/library/cc754461%28v=ws.10%29.aspx#BKMK_1

I drilled down into the Password Settings Container and it looks like there WAS one created in February of 2012.

A note from the technet article:
Important
To disable account lockout policies, assign the msDS-LockoutThreshold attribute the value of 0.
Guess what is set to 0...

I'm going to do some more investigating into this as to why it was created and the settings and will report back with my findings.

Thanks for the heads up!  You may have just found my solution!!
0
 
VIBTAuthor Commented:
Drilling down in adsiedit.msc to

DC=<domain_name>
CN=System
CN=Password Settings Container

I confirmed we had a Fine Grained Password Policy Object with the msDS-LockoutThreshold attribute set to 0.

I edited the  msDS-PSOAppliesTo attribute and removed the listed security group.  I then confirmed that the BadPWDCount user attribute was now increasing for my affected accounts (they were members of the group).

We have since removed the Fine Grained Password object and the lockout policy is working as expected.

Thanks gjeff80 for the heads up!
0
 
gjeff80Commented:
Fantastic, I let me PSS engineer know this was the problem too, so I'm sure microsoft will log it in their database now :)
0
 
VIBTAuthor Commented:
I chose my solution as part of the answer as I gave more detail as to the location of the problem.  I gave all points to gjeff80 for pointing me in the right direction.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 6
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now