I've been working with Windows Events for a while now. One of the things I did to help me diagnose problems and reporting on Windows Events was to write PSEventViewer to help to parse the logs and write PSWinReporting to help monitor (with use of PSEventViewer) Domain Controllers for events that happen across the domain. It's handy and I, get those excellent daily reports of what happened while I was gone.
While the above image doesn't have the event I want to talk about today it usually contains a detailed overview of what happened each and every day. What I started to get for one of my Clients was a bunch of A user account was locked out.
As you may notice above the Computer Lockout On is empty. And it's empty not because of mistake in my PowerShell Module but because the Event in question doesn't have that value.
To double confirm we can verify that Event Viewer actually shows the same information.
Generally, in such case, relevant information should be in another Event with EventID 4625. But that event only is available on the workstation where the connection was made. In this case, I didn't even have a clue where to look for because no data was available at hand. Enabling more logging on Domain Controllers didn't help either as already all Logon / Logoff Events were enabled. In normal circumstances Computer Lockout would be shown and I wouldn't have to do any verification. For example here's the Event that actually shows Computer Lockout On data.
In ObjectAffected property, you can see a computer that had the lockout on happened. This allows you to track where your users are locking out and potentially help them out with their problem. But in this case, that value doesn't exist and I having your Administrator lockout every few hours isn't right.
The reason why Computer Lockout On field being empty is that it only shows if it happens on within Active Directory. If you're using SSO (Single Sign-on) systems or have complicated architecture value may be blank. To try and trace where the issue happens we need to enable NETLOGON logging. We can use following steps to achieve that:
Nltest /DBFlag:2080FFFF net stop netlogon net start netlogon
Nltest /DBFlag:2080FFFF Restart-Service Netlogon
Now all you have to is wait for %windir%\debug\netlogon.log to start filling up. Simply wait for the Event to happen and review it.
So we check the log file, correlate that with Event time and we've got a winner.
01/24 11:27:01 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Entered 01/24 11:27:01 [LOGON] [4988] EVOTEC: Avoid send to PDC since user administrator failed recently 01/24 11:27:01 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:02 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Entered 01/24 11:27:02 [LOGON] [4988] EVOTEC: Avoid send to PDC since user administrator failed recently 01/24 11:27:02 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:03 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Entered 01/24 11:27:03 [LOGON] [4988] EVOTEC: Avoid send to PDC since user administrator failed recently 01/24 11:27:03 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:05 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via EVOTEC-RDS1) Entered 01/24 11:27:05 [LOGON] [4988] EVOTEC: Avoid send to PDC since user ADMINISTRATOR failed recently 01/24 11:27:05 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:05 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Entered 01/24 11:27:05 [LOGON] [4988] EVOTEC: Avoid send to PDC since user administrator failed recently 01/24 11:27:05 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:06 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via EVOTEC-RDS1) Entered 01/24 11:27:06 [LOGON] [4988] EVOTEC: Avoid send to PDC since user ADMINISTRATOR failed recently 01/24 11:27:06 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via EVOTEC-RDS1) Returns 0xC000006A 01/24 11:27:06 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Entered 01/24 11:27:06 [LOGON] [4988] EVOTEC: Avoid send to PDC since user administrator failed recently 01/24 11:27:06 [LOGON] [4988] EVOTEC: SamLogon: Transitive Network logon of (null)\administrator from (via EVOTEC-RDS1) Returns 0xC000006A
As you can see above, there is some information above Administrator account being used on EVOTEC-RDS1. There is also a value 0xC000006A which is a bit cryptic, but when we double check what it means it all makes sense. For reference, I'm attaching table with an explanation for each status code below.
| Status and Sub Status Codes | Description (not checked against “Failure Reason:”) |
| 0xC0000064 | user name does not exist |
| 0xC000006A | user name is correct but the password is wrong |
| 0xC0000234 | user is currently locked out |
| 0xC0000072 | account is currently disabled |
| 0xC000006F | user tried to logon outside his day of week or time of day restrictions |
| 0xC0000070 | workstation restriction, or Authentication Policy Silo violation (look for event ID 4820 on domain controller) |
| 0xC0000193 | account expiration |
| 0xC0000071 | expired password |
| 0xC0000133 | clocks between DC and other computer too far out of sync |
| 0xC0000224 | user is required to change password at next logon |
| 0xC0000225 | evidently a bug in Windows and not a risk |
| 0xc000015b | The user has not been granted the requested logon type (aka logon right) at this machine |
Now that we know where to look for our EventID 4625 we can find out what's causing the lockouts. A quick look into Event Viewer shows that it's actually coming from outside of the network. Unfortunately, this machine has access to RDP protocol via the Internet and that's why we get those brute-force attacks.
Our investigation is done, we pass this news to the second line to fix the problem of RDS being available on 3389 port and what they do with it, is their problem now.
Now that we're done with verification we can disable enhanced logs.
Nltest /DBFlag:0x0 net stop netlogon net start netlogon
Nltest /DBFlag:0x0 Restart-Service Netlogon
