locked
Audit failure 4776, blank workstation RRS feed

  • Question

  • I have a user who gets locked out occasionally (been a few weeks since the last time).  The bad password attempts show as a time where he was successfully logged into his computer and working.  I looked in the event logs on the DC and see some 4776 Audit failures for this user, with the error code 0xc000006a, which I believe means bad password.  However, the "Source Workstation" field is blank.  How can I track down where these bad attempts are coming from?
    Tuesday, January 24, 2012 6:17 PM

All replies

  • Hello,

    the account lockout tools should help you: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465

    http://technet.microsoft.com/en-us/library/cc738772(WS.10).aspx

    http://www.pbbergs.com/windows/articles/UserAccountLockoutTroubleshooting.html

    http://support.microsoft.com/kb/109626


    Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    Tuesday, January 24, 2012 6:19 PM
  • I have that package, and I used the EventComb tool to find the entries in the event log.  But I'm still showing the source workstation as blank, and it's not giving me any more info...

    It's my understanding that Alockout.dll finds the process/application, but you have to install it on the trouble workstation (and I don't know which computer is causing the problem, which is the issue in the first place).

    Beyond that, I'm not sure how to collect more information.

    Tuesday, January 24, 2012 6:25 PM
  • Allison,

    Could you us the hole event id (Unedited)

    Event ID: 4776 : The domain controller attempted to validate the credentials for an account.

    in the event log : u can find: Logon Account : please check do you have that account in ur domain.

    and also post us some more info on  DC(2003/2008) workstation: win7/win xp ?


    Gopi Kiran |Facebook| This posting is provided AS IS with no warranties,and confers no rights.
    Tuesday, January 24, 2012 7:50 PM
  • The Logon Account does exist, and it's the user in question (the one who's locked out - see original post).  The DC is 2008 R2, and the user's workstation is Windows 7.  But again, I have absolutely no idea if it's his workstation that the logon attemps are coming from, or a VM, or a server, or...
    Tuesday, January 24, 2012 7:54 PM
  • Could you us the hole event id (Unedited)
    Gopi Kiran |Facebook| This posting is provided AS IS with no warranties,and confers no rights.
    Tuesday, January 24, 2012 8:46 PM
  • I don't think there's any additional info here, but sure:

    4776,AUDIT FAILURE,Microsoft-Windows-Security-Auditing,Mon Jan 23 14:08:17 2012,No User,The computer attempted to validate the credentials for an account.    Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0  Logon Account: john  Source Workstation:   Error Code: 0xc000006a 

     

    Tuesday, January 24, 2012 8:59 PM
  • I believe that the Source Workstation is left blank because the name of the workstation or device cannot be verified, and therefore has the potential to have been spoofed.

    I found that turning on NTLM auditing helped me track down the source of these events.

    On the domain controller that is logging these events go into -

          Local Security Policy\Local Policies\Security Options

         I set the following:

               "Network Security: Restrict NTLM: Audit Incoming NTLM Traffic"  -  Enable Auditing for all accounts

               "Network Security: Restrict NTLM: Audit Incoming NTLM in this domain."   - Enable all

    In the Event Viewer you can view these events under:

         Applications and Services Logs\Microsoft\Windows\NTLM\Operational

    I look for events that match the time and username of the 4776 event.

    Often I find that the NTLM event shows me something like this:

    -----------------------------------------------------------------------------------------------------------------------------------

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-Security-Netlogon
    Date:          25/01/2012 2:03:24 PM
    Event ID:      8004
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      MYDOMAINCONTROLLER.mydomain.local
    Description:
    Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
    Secure Channel name: MYSERVER14
    User name: john
    Domain name: MYDOMAIN
    Workstation name: (NULL)
    Secure Channel type: 2

    Audit NTLM authentication requests within the domain MYDOMAIN that would be blocked if the security policy Network Security: Restrict NTLM: NTLM authentication in this domain is set to any of the Deny options.

    If you want to allow NTLM authentication requests in the domain MYDOMAIN, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled.

    If you want to allow NTLM authentication requests to specific servers in the domain MYDOMAIN, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in the domain MYDOMAIN to which clients are allowed to use NTLM authentication.
    -----------------------------------------------------------------------------------------------------------------------------------

    I can see the Workstation name is still (NULL) .. but the secure channel name points me to our NPS/Radius server (MYSERVER14) which is used for authentication of wireless devices ... usually it turns out to be an iPhone :-)

    • Proposed as answer by RobH_AU Wednesday, January 25, 2012 4:05 AM
    • Unproposed as answer by Teleute00 Monday, March 5, 2012 4:28 PM
    • Proposed as answer by PJ Champion Thursday, January 19, 2017 4:59 PM
    Wednesday, January 25, 2012 3:11 AM
  • Is your DC's are updated with latest SP and patches. In windows 2008 SP1 alone 800 fixes has been released and if you see below article like this there are number of hotfixes released which needs to be applied on the DC as well as client machine to segregate the issue.

    http://support.microsoft.com/kb/2549079

    http://support.microsoft.com/kb/2548120

     

    Regards


    Awinish Vishwakarma

    MY BLOG:  awinish.wordpress.com


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.
    Wednesday, January 25, 2012 9:49 AM
  • It is a brand new DC that is completely up to date.  I did review the text of the two articles you posted, though, to be sure - they definitely don't apply in the current situation.  Thanks, though!  Definitely something I'll keep in mind if that scenario does come up.
    Wednesday, January 25, 2012 7:53 PM
  • Oooh....very interesting.  I've just turned that on, and I'll see what comes back.  Problem is, it could be days or weeks before the issue arises again, which makes instant gratification somewhat difficult.  :-)
    Wednesday, January 25, 2012 7:54 PM
  • Hi,

     

    I just want to touch base and check if there is anything that I can do for you on this thread. If so, please do not hesitate to let me know and I will be happy to help.

     

    Regards,


    Arthur Li

    TechNet Community Support

    Monday, February 6, 2012 5:51 AM
  • No, thank you - I've put the above suggestions into place, but the lockout hasn't happened again yet so I don't know if this is a solution for me or not.  When I know, I'll post back.  Thanks!
    Monday, February 6, 2012 4:29 PM
  • He was finally locked out again today.  I looked at the NTLM logging as implemented above, and there's no information for him.  Lots of events, but nothing with his logon name.  So sadly, I still have no solution.
    • Proposed as answer by ZaxLofful Thursday, August 31, 2017 11:46 PM
    Monday, March 5, 2012 4:29 PM
  • Hi Teleute00,

    Can you check the event id 4740 on the DC,will occur if the account is getting locked.If it is logged open the event and check the caller Machine name.

    If the event id 4740 has not occured then this mean that in audit policy user account management policy is not configured.Configure the same and check if the events are occuring.

    Also refer below link  for more step on trroubleshooting accout lockout.

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/94a7399f-7e7b-4404-9509-1e9ac08690a8/
    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/1c7e66a4-6a81-4118-89df-2e290852c3cc/

    Hope this helps.


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Monday, March 5, 2012 5:15 PM
  • You're correct - there were no 4740 events, and account management policy was undefined.  I set it to log failures, so I'll see what happens next time.  Thanks!
    Monday, March 5, 2012 5:44 PM
  • I am having the same issue, did you ever get to the bottom of this?


    Dave M dindenver@yahoo.com

    Tuesday, August 6, 2013 3:59 PM
  • Please check from the handled device perspective also.



    Devaraj G | Technical solution architect

    Tuesday, August 6, 2013 4:43 PM
  • Nice!
    Thursday, January 19, 2017 4:59 PM
  • Did you ever find a solution?
    Friday, March 17, 2017 4:47 PM
  • In my case it was a Linux server with a CIFS Mount point to a Windows File Server, which was kinda of stuck and connected using the user account. We managed to forcibly umount the share ( umount -f) and the lockouts on the AD account stopped.

    Diego de Azevedo IT Analyst - MCSE, MCITP

    Tuesday, November 14, 2017 6:11 AM
  • Tuesday, November 14, 2017 5:40 PM
  • EventComb does not work well with Windows 2008 R2 because the structure of events has changed.

    For troubleshooting failed logons you should monitor events 4740 (lockout) and 4625 (An account failed to log on) . 4776 can appear in normal operations and is not an indication of bad logons. 

    You can use these queries as an XML filter in your security logs if you want to find only the above events for a particular user ("myusername"):

    For 4625:

    ------

      <Query Id="0" Path="Security">
        <Select Path="Security">
           *[EventData[Data[@Name='TargetUserName']='myusername']
             ]
    and
           *[System[
                            (EventID=4625)
                          ]
            ]
    < /Select>
      </Query>
    < /QueryList>

    For 4740:

    ------

      <Query Id="0" Path="Security">
        <Select Path="Security">
           *[EventData[Data[@Name='TargetUserName']='myusername']
             ]
    and
           *[System[
                            (EventID=4740)
                          ]
            ]
    < /Select>
      </Query>
    < /QueryList>

    Tuesday, November 14, 2017 8:21 PM
  • The account lockout tools are what provided this, there are no logs that come back from EventCombMT or from the DC's. 

    William Lee

    Friday, May 17, 2019 3:16 PM
  • Excellent, Thaks RobH_AU, this helped us also identify blank workstations lockouts and those with MSTSC.EXE or MSTSC workstation names. 


    • Edited by KingofTheNorth20 Friday, February 14, 2020 12:16 AM mentioned The author of the solution
    Friday, February 14, 2020 12:14 AM
  • This worked for me. 

    Although the operational event log returned a WorkstationName value of Null, it showed the workstation name under the SChannelName value.  This information was enough to bread crumb my way back to the source via wireshark, which in this case was a poorly configured forwarding rule at the firewall. All good!

    Thanks for the post RobH_AU much appreciated!  

    Wednesday, March 4, 2020 2:54 AM