This message was deleted.
# _general
s
This message was deleted.
j
How do you know? Is the user account getting locked out and the source is one particular device? If so, what sort of "logon type" is shown?
n
Yep, getting locked out, with this box being the source.
n
Don't know, because the report I'm being given doesn't have that. I'll see if I can find out, though.
The password stored in Credential Manager is invalid. This might be caused by the logged on user changing the password from this computer or a different computer. Not once have I ever seen this happen. I have nothing even attempting to hit the box this was referring to.
t
We had that a number of times...needed to open credential manager and clear out everything. Occasionally we would have to do a profile reset to resolve.
n
That's crazy. This is a first for me, and I have always had hundreds of entries in there - mostly VDAs, which this was.
I can't wrap my head around why that one in particular would be an issue, given that dozens of others have the wrong password stored right now, too.
t
For that I do not have an answer. It's a great question though! We couldn't figure it out either, and eventually just instructed our help desk to do a profile reset. It was easier for everyone.
n
Our InfoSec team is being less than helpful by not giving some of us access to actually check the logs ourselves (no Domain Admin rights for me), and when I ask, they just give me tidbits of info which are only so helpful.
Probably why they're still on our small XenDesktop image... 😄
t
what if you run TCPIPview from sysinternals and save it as a log and it will show all the connections made from the computer
n
Hard to narrow down without usernames associated with the processes, and ProcMon should get most of the same info. In my case, it looked like the authentication was happening as part of the boot process - at least, initially. No bad password attempts since killing that one entry in Credential Manager, so I think I have my culprit.
👍 1
✅ 1
a
For future, try sysinternals sysmon Nick - it'll log what processes started, what parameters, usernames that called them, parent processes etc, to match alongside your security event. The best bit is, you can leave sysmon running forever, it's a service, and isn't as heavy as procmon.
d
Enable account auditing in a policy (cannot remember the exact setting) and check the security eventlog on a Domain Controller.
n
Account auditing on the box in question was my ultimate source. I have no access to the DCs.