Thanks Mike, that does help with the explanation as to why. So, in my stated scenario, since the badPwdCount is not being incremented because it's within the N-2, we are safe from brute force attempts, because that would increase the counter.
Am I understanding that correctly and we can safely disable the authentication reports? What's best practice for that? Thanks for the input!! On Tue, Aug 8, 2017 at 11:28 AM, Mike King <m...@mpking.com> wrote: > Hi Charles, > > You might want to have your AD guys recheck they're sources. > > It's a feature from Server 2003, JUST for that reason. > > https://blogs.technet.microsoft.com/instan/2012/09/ > 17/why-doesnt-a-user-get-locked-out-after-a-number-of- > invalid-password-attempts-greater-than-the-domain-account-lockout-policy/ > > To improve the experience for users and to decrease the overall total cost > of ownership, Microsoft made the following changes to the behavior of > domain controllers in the Windows Server 2003 family: > > - Password > history check (N-2): Before a Windows Server 2003 operating > system increments badPwdCount, it checks the invalid password against > the password history. If the password is the same as one of the last two > entries that are in the password history, badPwdCount is not > incremented for both NTLM and the Kerberos protocol. This change to domain > controllers should reduce the number of lockouts that occur because of user > error. > > > Lelio, > Yes, you can track down the IP address of device performing the > authentications. But you can't apply lockout policies based on that. > > While on that subject, Read this one: > > https://support.microsoft.com/en-us/help/906305/new-setting- > modifies-ntlm-network-authentication-behavior > > Beginning with Microsoft Windows Server 2003 Service Pack 1 (SP1) there is > a change to NTLM network authentication behavior. Domain users can use > their old password to access the network for one hour after the password is > changed. > > > On Tue, Aug 8, 2017 at 11:55 AM, Charles Goldsmith <wo...@justfamily.org> > wrote: > >> So, a question out to the community about how you deal with this issue. >> If an organization is using Webex Messenger for IM and end-users are >> connecting Jabber to it, along with phone services and voicemail locally, >> jabber is setup with accounts to authenticate to AD locally. SSO is not in >> the mix. >> >> When a user's AD password comes up on their expiration and it's changed, >> they usually forget to update jabber on their laptop, phone and tablets, >> generating a lot of authentication alerts. Those can be filtered down by >> adjusting the thresholds. >> >> I'm not an AD guy, but talking with some, when asking about why this >> activity is not locking out the AD accounts, I was told that CUCM/CUC uses >> a read-only connection to AD, so it will not lock out the accounts. >> >> Because of that problem, we can't simply disable the alerts, we need to >> monitor them in case of brute force via MRA. >> >> Any thoughts on a better way to handle this specific scenario? >> >> I may wind up writing a script to consolidate the email authentication >> reports into something to give a report on thresholds per user, like >> John.Doe had 30 authenticaiton attempts in the last hour, Jane.Smith had >> 15, and Mark.Jones had 650. >> >> Thanks! >> >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip