Forum Discussion
On either the DC or the LM collector, in the event log you're looking for Security:4625 and Security:4740 events.
These will contain a Status and substatus that will tell you what specifically is happening. The 4625 for the service account that occurs just before the locked is the reason it's locking out.
4624 - Auth Success4625 - Auth Failure4740 - Lockout4767 - Unlock4624 - Logon4634 - Logoff# Failed Logon Event Codes - 4625 - https://system32.eventsentry.com/codes/field/Netlogon%20Error%20Codes0xC000005E There are currently no logon servers available to service the logon request.0xC0000064 user name does not exist0xC000006A user name is correct but the password is wrong0xC0000234 user is currently locked out0xC0000072 account is currently disabled0xC000006F user tried to logon outside his day of week or time of day restrictions0xC0000070 workstation restriction, or Authentication Policy Silo violation (look for event ID 4820 on domain controller)0xC0000193 account expiration0xC0000071 expired password0xC0000133 clocks between DC and other computer too far out of sync0xC0000224 user is required to change password at next logon0xC0000225 evidently a bug in Windows and not a risk0xc000015B The user has not been granted the requested logon type (aka logon right) at this machine0xC00000DC Indicates the Sam Server was in the wrong state to perform the desired operation.0xC000018D STATUS_TRUSTED_RELATIONSHIP_FAILURE
- 19 days ago
It's getting locked out because bad username or password, and it's coming ONLY from one of the collectors. Once we unlock the account it will work fine for hours, days, or weeks. Then out of the blue, it just starts failing with bad password until the account is locked. The only way we've been able to keep LM running is to setup a cron job that checks if the account is locked out every 5 seconds and unlocks it if it is, and it has worked for several weeks now.
- Cole_McDonald18 days ago
Professor
I'm assuming the creds are stored as wmi.user and wmi.pass. Sounds like some dataSource isn't respecting those are set and using the account the collector is set to. Tracking down that culprit takes some effort going through DataSource code and evaluating how each is utilizing the credentials or not.
My first stab at that would be to pull all of the 'Sources from the RestAPI using Powershell into an array. Then Filtering for any script that doesn't -match the string "wmi.user"
Alternatively, if you can match it to a specific PID (usually needs conversion from Hex in the event logs), get-wmiobject win32_process | where processid -eq <PID> might get you at the commandline property to see which script is being called to be able to more positively match it, but that's got a short lifespan.
Tying a lockout cadence to it could allow you to sort the dataSources by run frequency to help narrow it down as well.
- 18 days ago
that's sounds awesome, how do you do any of that?