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.
> 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
> 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:
> 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
> On Tue, Aug 8, 2017 at 11:55 AM, Charles Goldsmith <wo...@justfamily.org>
>> 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.
>> cisco-voip mailing list
cisco-voip mailing list