Audit failure 4776, blank workstation RRS feed

  • Pytanie

  • 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?
    wtorek, 24 stycznia 2012 18:17

Wszystkie odpowiedzi

  • 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.
    wtorek, 24 stycznia 2012 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.

    wtorek, 24 stycznia 2012 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.
    wtorek, 24 stycznia 2012 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...
    wtorek, 24 stycznia 2012 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.
    wtorek, 24 stycznia 2012 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 


    wtorek, 24 stycznia 2012 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 :-)

    • Zaproponowany jako odpowiedź przez RobH_AU środa, 25 stycznia 2012 04:05
    • Cofnięcie jako propozycji odpowiedzi przez Teleute00 poniedziałek, 5 marca 2012 16:28
    • Zaproponowany jako odpowiedź przez PJ Champion czwartek, 19 stycznia 2017 16:59
    środa, 25 stycznia 2012 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.
    środa, 25 stycznia 2012 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.
    środa, 25 stycznia 2012 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.  :-)
    środa, 25 stycznia 2012 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

    poniedziałek, 6 lutego 2012 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!
    poniedziałek, 6 lutego 2012 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.
    • Zaproponowany jako odpowiedź przez ZaxLofful czwartek, 31 sierpnia 2017 23:46
    poniedziałek, 5 marca 2012 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.

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

    Dave M dindenver@yahoo.com

    wtorek, 6 sierpnia 2013 15:59
  • Please check from the handled device perspective also.

    Devaraj G | Technical solution architect

    wtorek, 6 sierpnia 2013 16:43
  • Nice!
    czwartek, 19 stycznia 2017 16:59
  • Did you ever find a solution?
    piątek, 17 marca 2017 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

    wtorek, 14 listopada 2017 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>

    wtorek, 14 listopada 2017 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

    piątek, 17 maja 2019 15:16
  • Excellent, Thaks RobH_AU, this helped us also identify blank workstations lockouts and those with MSTSC.EXE or MSTSC workstation names. 

    • Zmodyfikowany przez KingofTheNorth20 piątek, 14 lutego 2020 00:16 mentioned The author of the solution
    piątek, 14 lutego 2020 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!  

    środa, 4 marca 2020 02:54