<mutter> STFW for ilspy <more muttering> Oh, that's interesting. I don't believe I've heard of that before - looks quite useful for real programmers, which unfortunately doesn't include me.
Still, might be worth looking through some powershell cmdlets to see what I can see. Thanks, Kurt On Thu, Jan 4, 2018 at 2:26 PM, Michael B. Smith <mich...@smithcons.com> wrote: > I don’t know the answer to your question, but I’ll tell you how I’d figure > it out. > > > > Two ways: > > > > [1] Use ILSpy and look at the cmdlet code. > > > > [2] look at both lists of users and figure out the differences by > comparing a few users and their attributes. > > > > *From:* listsad...@lists.myitforum.com [mailto:listsadmin@lists. > myitforum.com] *On Behalf Of *Christopher Bodnar > *Sent:* Thursday, January 4, 2018 4:38 PM > *To:* ntsysadm@lists.myitforum.com > *Subject:* [NTSysADM] Question regarding how AD is evaluating account > lockout status > > > > Got an AD question was hoping you someone can shed some light on for me. I > don’t think anything is wrong, but just wanted to understand this a little > better. It has to do with how AD is evaluating that an account is “locked > out”. So for example if I run this PowerShell command: > > > > *Search-ADAccount -lockedout * > > > > I get 347 results. But if I run this LDAP query: > > > > *(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))* > > > > I get 454. So it seems there are 107 accounts that have the “lockoutTime” > attribute set, but are NOT considered “locked out” by AD. That’s where I’m > having problems understanding why. Also note our Account Lockout Duration > is “0” so there should be no gap when an account is automatically enabled > and a user logs back in for the first time. All locked out accounts need > to be unlocked by an Admin in our environment. > > > > Also I’m pretty sure that the LOCKOUT value of the userAccountControl > attribute (16) is not an accurate way to determine this. > > > > So for these 107 accounts that AD does not consider locked out, but have a > lockoutTime greater than 0, how is that being evaluated? My understanding > was that AD evaluates this for an authentication request, and looks at the > badPwdCount, lockoutTime, and lockout duration policy in AD if applicable. > So for example if a user has hit 5 bad passwords (and the account lockout > threshold is 5), AD will then look at the lockoutTime value, and the > account lockout Duration value in Group Policy if applicable, and if the > time is past the sum of those 2 values, the badPwdCount and LockoutTime > values are reset, and the account is considered unlocked. Otherwise it > evaluates to locked out. > > > > Another factor is that I don’t see any correlation in the badPwdcount > value for these 2 groups of users. That value seems to be all over the > place, including null values. Which is another thing I don’t understand. > How can an account be locked out, and the badPwdCount value be NULL? If an > account was locked out, that value had to increment, and even if it’s > reset, it goes to 0, not back to NULL. > > > > Also I’m very familiar with Richard Mueller’s article on this topic: > > > > https://social.technet.microsoft.com/wiki/contents/articles/32490.active- > directory-bad-passwords-and-account-lockout.aspx > > > > > > > > Appreciate any input. > > > > Thanks > > > > > > > > *Christopher Bodnar* > Enterprise Architect II, Corporate Office of Technology:Enterprise > Architecture and Engineering Services > > Tel 610-807-6459 <(610)%20807-6459> > 3900 Burgess Place, Bethlehem, PA 18017 > <https://maps.google.com/?q=3900+Burgess+Place,+Bethlehem,+PA+18017&entry=gmail&source=g> > christopher_bod...@glic.com > > [image: cid:image001.png@01D1326B.600058E0] > > * The Guardian Life Insurance Company of America* > > * www.guardianlife.com <http://www.guardianlife.com/>* > > > > > ------------------------------ > > > > > > ----------------------------------------- This message, and any > attachments to it, may contain information that is privileged, > confidential, and exempt from disclosure under applicable law. If the > reader of this message is not the intended recipient, you are notified that > any use, dissemination, distribution, copying, or communication of this > message is strictly prohibited. If you have received this message in error, > please notify the sender immediately by return e-mail and delete the > message and any attachments. Thank you. > > >
