Audit failure 4776, blank workstation RRS feed

  • Soru

  • 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?
    24 Ocak 2012 Salı 18:17

Tüm Yanıtlar

  • Hello,

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




    Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    24 Ocak 2012 Salı 18:19
  • 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.

    24 Ocak 2012 Salı 18:25
  • 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.
    24 Ocak 2012 Salı 19:50
  • 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...
    24 Ocak 2012 Salı 19:54
  • Could you us the hole event id (Unedited)
    Gopi Kiran |Facebook| This posting is provided AS IS with no warranties,and confers no rights.
    24 Ocak 2012 Salı 20:46
  • 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 


    24 Ocak 2012 Salı 20:59
  • 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
    User:          SYSTEM
    Computer:      MYDOMAINCONTROLLER.mydomain.local
    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 :-)

    • Yanıt Olarak Öneren RobH_AU 25 Ocak 2012 Çarşamba 04:05
    • Yanıt Önerisini Geri Alan Teleute00 5 Mart 2012 Pazartesi 16:28
    • Yanıt Olarak Öneren PJ Champion 19 Ocak 2017 Perşembe 16:59
    25 Ocak 2012 Çarşamba 03:11
  • 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.





    Awinish Vishwakarma

    MY BLOG:  awinish.wordpress.com

    This posting is provided AS-IS with no warranties/guarantees and confers no rights.
    25 Ocak 2012 Çarşamba 09:49
  • 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.
    25 Ocak 2012 Çarşamba 19:53
  • 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.  :-)
    25 Ocak 2012 Çarşamba 19:54
  • 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.



    Arthur Li

    TechNet Community Support

    6 Şubat 2012 Pazartesi 05:51
  • 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!
    6 Şubat 2012 Pazartesi 16:29
  • 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.
    • Yanıt Olarak Öneren ZaxLofful 31 Ağustos 2017 Perşembe 23:46
    5 Mart 2012 Pazartesi 16:29
  • 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.


    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.

    5 Mart 2012 Pazartesi 17:15
  • 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!
    5 Mart 2012 Pazartesi 17:44
  • I am having the same issue, did you ever get to the bottom of this?

    Dave M dindenver@yahoo.com

    6 Ağustos 2013 Salı 15:59
  • Please check from the handled device perspective also.

    Devaraj G | Technical solution architect

    6 Ağustos 2013 Salı 16:43
  • Nice!
    19 Ocak 2017 Perşembe 16:59
  • Did you ever find a solution?
    17 Mart 2017 Cuma 16:47
  • 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

    14 Kasım 2017 Salı 06:11
  • 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">
    < /Select>
    < /QueryList>

    For 4740:


      <Query Id="0" Path="Security">
        <Select Path="Security">
    < /Select>
    < /QueryList>

    14 Kasım 2017 Salı 20:21
  • The account lockout tools are what provided this, there are no logs that come back from EventCombMT or from the DC's. 

    William Lee

    17 Mayıs 2019 Cuma 15:16
  • Excellent, Thaks RobH_AU, this helped us also identify blank workstations lockouts and those with MSTSC.EXE or MSTSC workstation names. 

    • Düzenleyen KingofTheNorth20 14 Şubat 2020 Cuma 00:16 mentioned The author of the solution
    14 Şubat 2020 Cuma 00:14
  • 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!  

    4 Mart 2020 Çarşamba 02:54