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

Reply via email to