<div dir="ltr">Hi Charles,<div><br></div><div>You might want to have your AD guys recheck they're sources.</div><div><br></div><div>It's a feature from Server 2003, JUST for that reason.</div><div><br></div><div><a href="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/">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/</a><br></div><div><br></div><div><p style="box-sizing:border-box;margin:0px 0px 10px;color:rgb(51,51,51);font-family:"Segoe UI",Tahoma,Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:14px">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:</p><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:10px;color:rgb(51,51,51);font-family:"Segoe UI",Tahoma,Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:14px"><li style="box-sizing:border-box"><span style="box-sizing:border-box;font-weight:700">Password<br style="box-sizing:border-box">     history check (N-2):</span> Before a Windows Server 2003 operating system increments <span style="box-sizing:border-box;font-weight:700">badPwdCount</span>, 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, <span style="box-sizing:border-box;font-weight:700">badPwdCount </span>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.</li></ul><div><font color="#333333" face="Segoe UI, Tahoma, Arial, Helvetica Neue, Helvetica, sans-serif"><span style="font-size:14px"><br></span></font></div></div><div>Lelio,</div><div>Yes, you can track down the IP address of device performing the authentications.   But you can't apply lockout policies based on that.</div><div><br></div><div>While on that subject, Read this one:</div><div><br></div><div><a href="https://support.microsoft.com/en-us/help/906305/new-setting-modifies-ntlm-network-authentication-behavior">https://support.microsoft.com/en-us/help/906305/new-setting-modifies-ntlm-network-authentication-behavior</a><br></div><div><br></div><div><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Web","Segoe UI Symbol","Helvetica Neue","BBAlpha Sans","S60 Sans",Arial,sans-serif;font-size:15px">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. </span><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 11:55 AM, Charles Goldsmith <span dir="ltr"><<a href="mailto:wokka@justfamily.org" target="_blank">wokka@justfamily.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Because of that problem, we can't simply disable the alerts, we need to monitor them in case of brute force via MRA.</div><div><br></div><div>Any thoughts on a better way to handle this specific scenario?   </div><div><br></div><div>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.</div><div><br></div><div>Thanks!</div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>