locked
AD FS Account Lockouts Internal/External tracing RRS feed

  • Question

  • Good day,

    We have a few users that are being locked out a few times a day.  The domain controller logs show the account tries to authenticate 5 times and then locks out.  Through the day, the account is authenticated unsuccessfully and most of the time does not reach 5 attempts before the 30 minute counter resets.   The 4740 MS Windows Security logs on the domain controller point to our ADFS server as the Caller Computer Name.  We turned on the extranet security feature last night and set the threshold to 4.  Our internal lockout policy is 5.  With a combination of 4 external and 5 internal attempts with a bad password, users are still being locked out.  I have gather logs for a particular case I am working on today. Name, domain, servers names have all been.  We have Account Management, and Event logging turned on.  I also have turned on AD FS tracing to see if I can gather more logs for this user.  Any help or insight anyone can provide would be greatly appreciated.  My goal is to-

    1. Find the source of the lockouts.

    2. Prevent user's from being locked out without compromising our security by increasing the lockout thresholds.

    Domain controller log

    Event ID 4740
    Source Microsoft Windows security
    Log name Security
    Task Catergory User Account Management
    Computer COMPANYDC
    1/26/2015 - 6:15 AM

    A user account was locked out.

    Subject:
     Security ID:  SYSTEM
     Account Name:  COMPANYDC$
     Account Domain:  COMPANY
     Logon ID:  0x3E7

    Account That Was Locked Out:
     Security ID:  COMPANY\johndoe
     Account Name:  johndoe

    Additional Information:
     Caller Computer Name: ADFSSERVER

    ~~~~~~~~~

    Event log from ADFSSERVER


    EVENT ID 516
    Source AD FS Auditing
    Log name Security
    Task Category 3
    Computer ADFSSERVER
    1/26/2016 - 6:07 AM

    The following user account has been locked out due to too many bad password attempts.

    Additional Data

    Activity ID: 00000000-0000-0000-0000-000000000000

    User:
    johndoe@company.com

    Client IP:
    190.115.180.232,157.56.238.252
    nBad Password Count:
    4
    nLast Bad Password Attempt:
    1/26/2016
    ~~~~~~~~~
    Other Event ID 512/516 since 6:15 AM

    Client IP:
    190.115.179.140,157.56.238.252

    Client IP:
    206.16.109.48,132.245.38.237

    ~~~~~~~~~

    Event ID 411
    Source AD FS Auditing
    Log name Security
    Computer ADFSSERVER
    1/26/2015

    Token validation failed. See inner exception for more details.

    Additional Data

    Activity ID: 00000000-0000-0000-0000-000000000000

    Token Type:
    http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName 

    Error message:
    johndoe@company.com-The user name or password is incorrect

    Exception details:
    System.IdentityModel.Tokens.SecurityTokenValidationException: johndoe@company.com ---> System.ComponentModel.Win32Exception: The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       --- End of inner exception stack trace ---
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

    System.ComponentModel.Win32Exception (0x80004005): The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)

    ~~~~~~~~~

    EVENT ID 4625
    Source Microsoft Windows Security
    Log name Security
    Task Category Logon
    Computer ADFSSERVER
    1/26/2015 - 6:15 AM

    An account failed to log on.

    Subject:
     Security ID:  COMPANY\adfs
     Account Name:  adfs
     Account Domain:  COMPANY
     Logon ID:  0x95292

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  johndoe@company.com
     Account Domain:  

    Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xC000006D
     Sub Status:  0xC000006A

    Process Information:
     Caller Process ID: 0xe08
     Caller Process Name: C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe

    Network Information:
     Workstation Name: ADFSSERVER
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  W
     Authentication Package: Negotiate
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    ~~~~~~~~~

    EVENT ID 342
    Source AD FS
    Log name AD FS/Admin
    Task Category Logon
    Computer ADFSSERVER
    1/26/2015 - 6:15 AM

    Token validation failed. 

    Additional Data

    Token Type:
    http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName
    %Error message:
    johndoe@company.com-The user name or password is incorrect

    Exception details:
    System.IdentityModel.Tokens.SecurityTokenValidationException: johndoe@company.com ---> System.ComponentModel.Win32Exception: The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       --- End of inner exception stack trace ---
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

    System.ComponentModel.Win32Exception (0x80004005): The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)

    Wednesday, January 27, 2016 7:03 PM

Answers

  • Have you looked at this ?

    http://blogs.technet.com/b/pie/archive/2016/02/02/track-down-the-source-of-adfs-lockouts.aspx


    __________________________________________

    Please mark as Answer if this answers your question

    Regards,

    Shane Jackson

    Blog: https://shanejacksonitpro.wordpress.com/

    Twitter: https://twitter.com/shane00jackson

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, February 3, 2016 5:09 PM

All replies

  • Have you looked at this ?

    http://blogs.technet.com/b/pie/archive/2016/02/02/track-down-the-source-of-adfs-lockouts.aspx


    __________________________________________

    Please mark as Answer if this answers your question

    Regards,

    Shane Jackson

    Blog: https://shanejacksonitpro.wordpress.com/

    Twitter: https://twitter.com/shane00jackson

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, February 3, 2016 5:09 PM
  • Try to investigate this account lockouts via Netwrix Account Lockout Examiner free tool, probably it will give you more info about your lockout.

    Best Regards,

    Jeff

    Netwrix Technical Evangelist

    Netwrix Blog  Twitter:   LinkedIn:   Facebook:

    Netwrix Auditor  is an IT audit software that maximizes visibility of IT infrastructure changes and data access. The product provides actionable audit data about who changed what, when and where and who has access to what.


    Friday, February 12, 2016 11:18 AM
  • Hello Jeff -

    It is the second time that you suggest this tool to track down ADFS lockout accounts. Looking at the online specs, it does not look like it can help at all with ADFS lockouts since those will always look like they are coming from the ADFS servers. The article mentioned by Shane gives some hints to track them down looking at ADFS events and not ADDS events. Please ensure your tool does that before suggesting it on the public forum.

    Thanks!


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, February 12, 2016 1:45 PM
  • I know this is an old thread, but it is one of the first I encountered when addressing this issue. After moving some users to Office365, we started getting a lot of account lockouts that originated with our adfs server. The event id 411 with "Activity ID: 00000000-0000-0000-0000-000000000000" represents a client using legacy authentication, think pre-Office 2013 with the May 2017 update.

    In our case, the first IP address listed under Client IP originated in China over 80% of the time. We have no users in China so this was not legitimate traffic. This was a patient brute-force password hacking attempts. They put intervals between attempts to help prevent lockouts. The second IP address is always a Microsoft IP Address. The client login attempt is being proxied through the MS system to your WAP/ADFS server, so you can't block it at your firewall or you block all MS authentication.

    If you search for how to block IP ranges from ADFS, your going to end up looking at Access Control Policies. This is good to know, but did not work for Legacy Authentication.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-w2k12
    https://technet.microsoft.com/en-us/library/dn592182.aspx
    https://www.anexinet.com/blog/adfs-restricting-client-access-for-office-365/

    The first two links show various scenarios for restricting services by IP. The last link corrects some logic errors in the second link. None of them prevented the lockouts or login attempts. It seems that ADFS claim rules do not block requests to AD on-prem, but attempts authentication against AD then decides if the token should be sent to Office365. Lockout continue.

    The next think you may be directed to is the Extranet Lockout Protection feature of ADFS. I highly recommend you enable this to reduce the number of internal lockouts from external login failures. However this reduces the number on internal lockouts but does not prevent a methodical hacker from attempting logins throughout the day.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-lockout-protection

    In mid-2017 Microsoft changed the default authentication method for Exchange/Skype/SharePoint to "Modern Authentication" by default. If your tenant predates this, all of these services are configured for "Legacy Authentication".

    If you are able to go 100% modern authentication, what finally stopped the unwanted login attempts from Legacy clients was to block the legacy login endpoints by disabling them on the proxy.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

    Primarily:

    /adfs/services/trust/2005/usernamemixed
    /adfs/services/trust/13/usernamemixed

    Since disabling all non-essential for modern authentication endpoints, the 411 errors have stopped. This may not work for every environment, but it is working for ours at this time.

    • Proposed as answer by RMC_ Wednesday, April 18, 2018 8:23 PM
    Wednesday, March 28, 2018 7:17 PM
  • Thanks Tim, this post is money.
    Wednesday, April 18, 2018 8:24 PM
  • Just wanted to say thanks for this well written post. This was exactly what fixed the same issue for me.
    Wednesday, May 30, 2018 7:04 PM
  • Would tenants using ADFS in Server 2016 with Smart Lockout resolve this issue?
    Monday, June 25, 2018 9:40 PM
  • Would I know what exactly you did to fix the issue? Since we encounter the similar issue. Thanks!!
    Saturday, August 25, 2018 12:28 AM
  • The recommendation is to use the Smart Lockout Feature: https://support.microsoft.com/en-ca/help/4096478/extranet-smart-lockout-feature-in-windows-server-2016

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, August 29, 2018 8:46 PM
  • I know this is an old thread, but it is one of the first I encountered when addressing this issue. After moving some users to Office365, we started getting a lot of account lockouts that originated with our adfs server. The event id 411 with "Activity ID: 00000000-0000-0000-0000-000000000000" represents a client using legacy authentication, think pre-Office 2013 with the May 2017 update.

    In our case, the first IP address listed under Client IP originated in China over 80% of the time. We have no users in China so this was not legitimate traffic. This was a patient brute-force password hacking attempts. They put intervals between attempts to help prevent lockouts. The second IP address is always a Microsoft IP Address. The client login attempt is being proxied through the MS system to your WAP/ADFS server, so you can't block it at your firewall or you block all MS authentication.

    If you search for how to block IP ranges from ADFS, your going to end up looking at Access Control Policies. This is good to know, but did not work for Legacy Authentication.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-w2k12
    https://technet.microsoft.com/en-us/library/dn592182.aspx
    https://www.anexinet.com/blog/adfs-restricting-client-access-for-office-365/

    The first two links show various scenarios for restricting services by IP. The last link corrects some logic errors in the second link. None of them prevented the lockouts or login attempts. It seems that ADFS claim rules do not block requests to AD on-prem, but attempts authentication against AD then decides if the token should be sent to Office365. Lockout continue.

    The next think you may be directed to is the Extranet Lockout Protection feature of ADFS. I highly recommend you enable this to reduce the number of internal lockouts from external login failures. However this reduces the number on internal lockouts but does not prevent a methodical hacker from attempting logins throughout the day.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-lockout-protection

    In mid-2017 Microsoft changed the default authentication method for Exchange/Skype/SharePoint to "Modern Authentication" by default. If your tenant predates this, all of these services are configured for "Legacy Authentication".

    If you are able to go 100% modern authentication, what finally stopped the unwanted login attempts from Legacy clients was to block the legacy login endpoints by disabling them on the proxy.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

    Primarily:

    /adfs/services/trust/2005/usernamemixed
    /adfs/services/trust/13/usernamemixed

    Since disabling all non-essential for modern authentication endpoints, the 411 errors have stopped. This may not work for every environment, but it is working for ours at this time.

    Tim - you deserve a beer for that post! Exactly our problem since last week, accounts locking out from all over the world, geo blocked but still getting through.  Removing the two legacy settings and bouncing the services stopped the 411 events immediately!!  
    Monday, October 8, 2018 8:57 PM
  • BUT you are also blocking legit users from using those. That's ok to stop the bleeding. But the Smart Extranet Lockout is a better long term solution.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, October 9, 2018 1:15 PM
  • We did need to reconfigure extranet lockout - you need to make sure the right settings are higher than AD settings - legit users do not need legacy auth, we have had a couple of issues doing this...

    1. samsung phone mail app stops working - use outlook app

    2. unpatched/2013 outlook clients stop working - patch your machines and upgrade to outlook 2016

    3. SMTP relay accounts - switch to cloud based onmicrosoft accounts

    Saturday, October 13, 2018 12:03 AM