ProfessorDeep Dive troubleshooting question
I'm having difficulties tracking down the source of a Service Account Lockout occuring in a fairly complex domain structure.
I've found it necessary to set WMI creds at the top of the heirarchy, with sub-groups having different WMI creds, as well as individual devices with their own.
On the domain controller that would be targeted with a sub-group WMI cred set, I see most 'Sources collecting correctly, but a few times a day, the SA is locking out. I find the 4740 on the DC, but can't quite track down the specific event (should be a 4625) causing the lockout. The only 4625 I'm finding show the Main group WMI creds... which are in a different domain.
Seems as though some 'Sources are using the wrong WMI creds (or defaults based on the Collector's SA).
The question: Is there a way to get a !TLIST showing the WMI.USER being leveraged in the debug console for each job?
We struggled with something similar recently... In our case, we had a single WMI account across all hosts in a group and we knew it was correct, but we would see accounts logouts happening almost constantly.
We thought the same as you - that there is a credential cached somewhere, or a credential set wrong on a host or a credential hard coded somewhere. We didn't come across a way of troubleshooting it, one of my colleagues did find the root cause though.
In our case, the issue was due to currency chars in the password - specifically the $ sign. This was causing some of our PowerShell based property/data sources to do handle parts of the password as if we wanted it to do string interpolation. Of course, the variable it was replacing portions of our password with didn't exist, so it had the effect of removing a portion of the password at runtime. We were using double quotes rather than single quotes in a PowerShell script.
Dave
