The source of my account lockout is my domain controller

Article
10/02/2016

When it comes to track down account lockouts, there are plenty of tools and techniques. Looking at the event 4740 in the security event logs is the most common step:

We can read the user account and the caller computer name. Note that if you do not see this event in your event logs, ensure that the following Advanced Audit subcategory is enabled for Success:

 C:\>auditpol /get /subcategory:"User Account Management"
System audit policy
Category/Subcategory                      Setting
Account Management
  User Account Management                 Success

Note that when an account is locked out, you will see the event on two domain controllers. The local domain controller against which the user is trying to authenticate, and the ePDC (well or only the ePDC if it is also the local DC for the client). So if you want to script things, or do event forwarding, or collect the lockout with a SIEM or even with SCOM, you can just target the ePDC of the user's domain. If you are not familiar with the Account Lockout Policy and the nitty gritty details, please start here: Account Lockout Policy Technical Overview.

Caller Computer Name

First of all, this field in the event is not necessarily accurate. It works on a bet effort basis. If the authentication process is able to carry what the source is, then this source will be written in the field. We can consider it accurate when the authentication comes from Windows machines. But if the authentication is coming from a third party device, it is possible that the field will be empty or contain an arbitrarily set value. We will deal with those in a further post.
Then it is also possible that the field is showing the name of a domain controller... In that case the tracking of the actual source might be a little bit tricky. Although it is possible that it could be due to a third party device arbitrarily setting the name of a DC while it tries to authenticate, it is more likely that is comes from an authentication actually coming from the DC. And this is what we are going to have a closer look at today.

LDAP simple binds

As per the RFC, the LDAP server should support simple bind with username/password as an authentication mechanism. When an application is using a simple bind, the username (different format are possible such as the distinguishedName or the displayName) and its password is sent over the network to the LDAP server. Then the LDAP server is initiating the authentication process. So the source of the authentication is the LDAP server. But wait a minute... My domain controller is also the LDAP server... And here you have a typical example of phenomena where authentication is starting on the domain controller. As a result, if the authentication happens to lock out the account, the Caller Computer Name will show the name of the local DC.

Getting the actual IP address

The obvious way to look for the actual IP address of the actual machine is to look at the failed authentication event on the local DC receiving the authentication. This is the Audit Failure ID 4625:

It will show up only on the local domain controller processing the authentication. This also means that the following Advanced Audit Policy settings is set to audit the failure of this subcategory:

 C:\>auditpol /get /subcategory:"Logon"
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure

What about the ePDC? Well although the local domain controller talks to the ePDC at each failed authentication because of a wrong password, the ePDC will not have the event id 4625. You will still see something on the ePDC security event logs. If the following Advanced Audit subcategory is enable for failure, you will see the failure audit event ID 4776:

 C:\>auditpol /get /subcategory:"Credential Validation"
System audit policy
Category/Subcategory                      Setting
Account Logon
  Credential Validation                   Success and Failure

Then you see the following event on the ePDC:

Note that this event 4776 will also show on the local domain controller. Let's look at those two more closely:

4625 on the local DC	4776 on the local DC	4776 on the ePDC
...Account Name: pierreAccount Domain: CONTOSOFailure Information:Failure Reason: Unknown user name or bad password.Status: 0xC000006DSub Status: 0xC000006A...Network Information:Workstation Name: DC02Source Network Address: 10.0.0.7	...Logon Account: pierreSource Workstation: DC02Error Code: 0xC000006A	...Logon Account: pierreSource Workstation: DC02Error Code: 0xC000006A

You can see that some of the information is commun. Interestingly the sub status is also visible accros the board. I want to outline the 10.0.0.7 IP address that we are seeing in the 4625, in red in the table above. 10.0.0.7 is not the IPv4 address of DC2. It is the actual IPv4 address of the actual LDAP client trying to authenticate. In that case, the client for which we don't know the name, but for which we know the IPv4 address, is trying to perform a simple bind against the domain controller DC2.

It's too noisy

Enabling the logon failures audit has a major flip side. It is noisy. It will generate a lot of events. And not all of them are ultimately finishing by a locked account. If it is already enabled on your environment, then you probably have a short retention time for your security event logs or you have a SIEM that collect the event logs (that you don't care much about the retention). If you are using event forwarding you cannot forward all of the 4625 for the sole purpose of tracking down account lockout like you could do with the event 4740. That would be way too many of them. The next section presents an alternative if you want to spot the event telling you the information you want quicker.

Sound proofing your solution

There is another Advanced Audit subcategory which lack of documentation... This is the following:

 C:\>auditpol /get /subcategory:"Account Lockout"
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Account Lockout                         Failure

Note that contrary to what the documentation states, it has to be set to Failure to actually generate events. When you have this subcategory enabled on your domain controllers, when an locked account is trying to authentication it will generate an event 4625 but of a different Task Category:

This will not show up if it is the attempt of the lockout. It will show up only at Account Lockout Threshold + 1 attempt. When somebody is trying to use a locked account. And if you have a close look at the Network Information section, it also contains the actual IP of the client making the simple bind call.

This event will show up only when an authentication attempt is made for a locked out account. So enabling it will be much less noisy that enabling the all logon failure audit. And/or if you have scripts or event forwarding, you can make a filter on the event 4625 if the Task Category is: Account Lockout.

Some PowerShell

Because a post always feels incomplete if it does not have a few lines of PowerShell code, here you go:

 
#Currently under review

Comments

Anonymous
May 01, 2017
"But if the authentication is coming from a third party device, it is possible that the field will be empty or contain an arbitrarily set value. We will deal with those in a further post."Was this additional post ever made?
- Anonymous
  May 09, 2017
  It is drafted... Do you have the case? Mind sharing your input? We could co-write :)
Anonymous
June 22, 2017
“But if the authentication is coming from a third party device, it is possible that the field will be empty or contain an arbitrarily set value. We will deal with those in a further post.”It is drafted… Do you have the case?Did you ever get a case? I opened a ticket once but they couldn't resolve it.
- Anonymous
  June 29, 2017
  For SMB for example, according to [MS-SRVS]: Server Service Remote Protocol https://msdn.microsoft.com/en-us/library/cc247080.aspx the client will provide the info to the server about its name (to built a session structure). This has to be either NULL or a string starting with \. But really the client has the discretion on this. Samba clients for example have a parameter to override the smb.conf (see –netbiosname in https://www.samba.org/samba/docs/man/manpages-3/smbclient.1.html). And the DC just validate the credentials (event 4776), it just has access to whatever the NTLM security provider has access to, and in the NTLM pass-through process, the IP address of the client doesn’t seem to be a part of what the DC has available. I do not have any case I could build upon… I write my post based on what I get on my plate :) If you have more info, feel free to email me, I’ll have a look at it and see if we can build something on it.)
  - Anonymous
    March 18, 2019
    Has anyone figured out a way to track down a failed authentication from a non-windows SMB client that is not providing a valid computer name? I'm trying to track down failed authentication attempts that are reporting the computer name JCIFS20_88_73 which is a Java CIFS client.
    - Anonymous
      March 27, 2019
      Yes. As suggested, you can enable the Account Lockout audit to have the event 4625 showing the actual IP address.
Anonymous
January 24, 2018
The comment has been removed

Share via