✋: Troubleshooting Lockout with no “Caller Computer”

Account lockouts on a domain controller, are part of managing a domain, and to find these events they  will be the security EventID 4740, if you filter for EventID 4740 you will see something like this:


Then event will then look like this, but if you notice the called computer is blank, this is not good:


Lets drill into that shall we, as we need the know the computer which is not listed for many reasons, these are the usual reasons
  1. Mapped Network Drive
  2. 802.1x PEAP or Enterprise connection
  3. Credential Manager
  4. Foreign Domain
  5. External website using Kerberos
You can guess where the issue is, or you can go down the rabbit hole of logs, I prefer to get proof where the issue is rather than picking one and "assuming" its that.

First thing you need to know is the PDC or the Primary Domain Controller - which is an emulated role in todays world will be the one that holds the lockout status, this can be identified  by using the command:

netdom query fsmo

This will then show you the domain based FSMO roles in the domain like this:

Schema master                       Honeybark.bear.local
Domain naming master          Honeybark.bear.local
PDC                                        Honeybark.bear.local
RID pool manager                  Honeybark.bear.local
Infrastructure master              Honeybark.bear.local
The command completed successfully.

Now you know the PDC server, so you need to run this command on the server that will put netlogon is Debug mode, which will help you to troubleshot the issue massively.

Nltest /DBFlag:2080FFFF

You will need to make sure you command prompt is elevated and you should get this, if you get access denied you command was not elevated!


Right, now you have this set you need to navigate to this folder

%systemroot%\Debug

Once you are here you are looking for the files netlogon and netlogon.bak the way this works is netlogon gets to 20MB and then the file is archived into netlogon.bak:


Now you need to right click on netlogon file with the SHIFT key held down and choose copy path as below:


Then start a PowerShell window, elevated naturally and the command you need is this:

Get-Content "C:\Windows\Debug\netlogon.log" -Tail 20

This command will get the last 20 entries of the time, and the command should look like this:



That will return the contents of the file, but that could be a lot of data, so as you have a user in mind that is being locked out you only really want to know about the problem user, so I would use this command, that will show the last 100 entries:

Get-Content "C:\Windows\Debug\netlogon.log" -Tail 100

Now you are only interested in the user being locked out, so lets say their login is naughty.bear you can then use this command, that will only return items with that "string"

Get-Content "C:\Windows\Debug\netlogon.log" -Tail 100 | findstr naughty.bear

This will then show you something like this:

11/03 14:13:54 [LOGON] [10912] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from UserDesktop (via honeyhill) Entered
11/03 14:13:54 [LOGON] [10912] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from UserDesktop (via honeyhil) Returns 0xC0000234

Excellent, so from this we can see that the "UserDesktop" server has the return code of 0xC0000234 for the user, which is locked out, but that does not mean that is where the account was locking out, that is where the account locked out.

If you notice the requests came from "honeyhill" which is another domain controller we have in our domain, that is the domain controller that will tell us why, so lets enable netlogon from that server, like we did before with this:

Nltest /DBFlag:2080FFFF

Get-Content "C:\Windows\Debug\netlogon.log" -Tail 100 | findstr naughty.bear

This then tells us, with the code 0xC000006A that we have an invalid username or password, or in other words a "bad password" which would cause a lockout, in this domain we have 5 bad passwords before a lockout event occurs:

11/03 14:04:34 [LOGON] [10352] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Entered
11/03 14:04:34 [LOGON] [10352] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Returns 0xC000006A
11/03 14:04:10 [LOGON] [10488] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Entered
11/03 14:04:10 [LOGON] [10488] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Returns 0xC000006A
11/03 14:08:20 [LOGON] [692] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Entered
11/03 14:08:20 [LOGON] [692] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via cloverleaf) Returns 0xC000006A

Right, so now the domain controller "cloverleaf" needs to be diagnosed as well which is another link in the chain, but at this stage we are on bad password attempt 3 at the moment:

Nltest /DBFlag:2080FFFF

Get-Content "C:\Windows\Debug\netlogon.log" -Tail 100 | findstr naughty.bear

This then tells us that we have another 2 bad password attempts, however this time we get the source server which is "wifi.auth" which is the 802.1x authentication server, this is the gold nugget that the event log could not retrieve.

11/03 14:07:34 [LOGON] [14508] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via wifi.auth) Returns 0xC000006A
11/03 14:07:55 [LOGON] [11012] BEAR: SamLogon: Transitive Network logon of bear\naughty.bear from  (via wifi.auth) Returns 0xC000006A

Right now we are getting somewhere, this tell us that the server named "wifi.auth" is locking the user out due to trying his password more than 5 times, this also explains why the caller computer is not in the EventID of 4740 - as we have been though 3 domain controllers to get this result.

Now you know the source, you can come up with an action plan to stop the lockouts occurring, but sometimes going down the rabbit hole is quite fun.

Now you have found the source of the issue, you can turn of netlogon debugging with this command:

Nltest /DBFlag:0x0

This is how you can tell what computer is causing the lockout when the caller computer is empty in the lockout event.
Previous Post Next Post

نموذج الاتصال