I'm trying to track down which helpdesk staff are clearing the 'Must change password at next logon' flag when they reset user passwords. We log all Domain Controller events in Log Analytics and I've discovered that when a helpdesk user resets a password (logged as EventID 4724), we also receive EventID 4738 shortly after, indicating a user account change. The important detail is that we need to find instances where the 'PasswordLastSet' timestamp coincides with a %%1794 event, which indicates that the password will expire at next login. It's a bit tricky since these events are independent, so my question is: can anyone provide a KQL query to filter for this? We're dealing with over 5,000 password resets every month, and when the Helpdesk assigns simpler passwords, users aren't utilizing self-service options effectively.
4 Answers
Have you considered changing the permissions of your helpdesk? You can configure it so they don't have the ability to clear the 'Must change password' flag at all. This way, every password reset will force users to update their credentials on the next login, which could help enforce better password practices.
Using a SIEM solution like Sentinel can help you automate this tracking. You can set alerts for specific combinations of events, which would eliminate some of the manual tracking you’re doing. Some tools have built-in reporting features that can streamline this process significantly!
Definitely check with your SIEM's documentation. Some solutions provide ready-to-use templates for such audits, which could save you hours!
Consider using PowerShell scripts to enforce policies on password resets. There’s a command that can set user accounts so the flag can't be changed when resetting passwords. I’m not sure if those changes stick across different domain controllers though, so that’s worth exploring further.
Yeah, I think they only apply to the specific OU you configure. You might need to run the command on each DC to maintain consistency.
You might want to look into using KQL with something along the lines of this:
```kql
let resetEvents = SecurityEvent | where EventID == 4724;
let changeEvents = SecurityEvent | where EventID == 4738;
resetEvents
| join kind=inner (changeEvents) on $left.TargetAccount == $right.Account
| where $right.TimeGenerated between(item1.TimeGenerated .. item2.TimeGenerated)
| project TimeGenerated, TargetAccount, Account, EventID
``` This should help you find those events in a tighter time frame!
Looks good, but make sure to adjust for your specific environment. The timestamps might need some extra handling to ensure accuracy.
This approach is solid! Just remember to test it out on a smaller dataset to make sure it returns what you expect.
That’s a good point! But be cautious, as your Active Directory schema needs to be at least 2016 to support this change. Also, many organizations still run on an older schema.