A user (we'll call them 'username') keeps getting locked out and I don't know why. Another bad password is logged every 20 minutes on the dot.

The PDC Emulator DC is running Server 2008 R2 Std. Event ID 4740 is logged for the lockout but the Caller Computer Name is blank:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          5/29/2015 4:18:14 PM
Event ID:      4740
Task Category: User Account Management
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      FQDNofMyPDCemulatorDC
A user account was locked out.

    Security ID:        SYSTEM
    Account Name:       MyPDCemulatorDC$
    Account Domain:     MYDOMAIN
    Logon ID:       0x3e7

Account That Was Locked Out:
    Security ID:        MYDOMAIN\username
    Account Name:       username

Additional Information:
    Caller Computer Name:   

The lockout origin DC is running Server 2003 running IAS (RADIUS). Its security log contains a corresponding event for the account lockout, but of course it is also missing the source (Caller Machine Name):

Event Type: Success Audit
Event Source:   Security
Event Category: Account Management 
Event ID:   644
Date:       5/29/2015
Time:       4:18:14 PM
Computer:   MyRadiusDC
User Account Locked Out:
    Target Account Name:    username
    Target Account ID:  MYDOMAIN\username
    Caller Machine Name:    
    Caller User Name:   MyRadiusDC$
    Caller Domain:      MYDOMAIN
    Caller Logon ID:    (0x0,0x3E7)

NetLogon Debug Logging is enabled on the lockout origin DC, and the log (C:\WINDOWS\debug\Netlogon.log) shows the failed logins due to bad password, but not the source (you can see where it says 'from' followed by two spaces, in between the spaces should be the source of the logon attempt):

05/29 16:18:14 [LOGON] MYDOMAIN: SamLogon: Network logon of MYDOMAIN\username from  Entered
05/29 16:18:14 [LOGON] MYDOMAIN: SamLogon: Network logon of MYDOMAIN\username from  Returns 0xC000006A

IAS logs (C:\WINDOWS\system32\LogFiles\IN######.log) do not show any RADIUS connections from this user in the past 2 days.

I don't know where the heck to go from here is except to curse Microsoft until I'm out of breath. Does anyone have any ideas that might be more productive? :-D

  • 1
    Can you turn on failure auditing for authentication attempts? The full event will have a little more detail than the netlogon debug log, but still might not help. This has always been RADIUS when I've run into a missing source, for what it's worth. May 29 '15 at 23:58
  • Thanks! I swear I have checked this a while back but maybe someone changed it (too many Domain Admins). Sure enough, failure auditing was disabled in our Default Domain Controllers GPO. I will enable it (after the appropriate change management process) and hopefully get some additional info.
    – Fëanor
    May 30 '15 at 0:31
  • 1
    Does he have any mobile device (phone, tablet) configured with his account, that keeps trying to log it?
    – Dan
    May 30 '15 at 6:56
  • I did check and confirm that he has 0 Exchange ActiveSync devices. However this is a very common cause of the lockouts so I am confident that such a device would cause the account lockout to come from an Exchange Client Access Server, rather than the source being blank. I automatically identify those ones and tell the help desk which devices(s) show unauthorized access attempts in the Exchange CAS IIS logs.
    – Fëanor
    Jun 9 '15 at 14:25
  • Apparently there is a trick to getting the right information logged: jackstromberg.com/2013/03/… specifically: support.microsoft.com/en-us/kb/109626/en-us
    – Mary
    Jun 14 '15 at 20:56

I have only just finished a call with Microsoft about exactly this, so hopefully the following information will help :)

Authentication attempts can happen at a couple of spots, and notably if you are using PEAP authentication for wireless connections, authentication negotiation also occurs through the EAPHost service.

The EAPHost service I find doesn't have fantastic authentication logging (it's miserable actually - trace file), so if for whatever reason authentication fails in EAPHost, the authentication failure attempt is logged using the somewhat generic authentication eventIDs in the event log and nothing at all in IAS Logs.

What we did discover was that a newly built RADIUS server was logging far more information in the IAS logs than our in production system. I went through an reconfigured logging through the configuration log to include accounting information (tick all the boxes in the wizard!), restarted the service and found all that missing IAS events were now being logged including MAC Addresses and SSIDs into the IAS Log files.

Hope this may help :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.