[cisco-voip] authentication failed alerts

[Charles Goldsmith]

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 <me at 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 <wokka at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170808/a33761ec/attachment.html>