I'm trying to figure out how to identify helpdesk personnel who are disabling the "Must change password at next logon" flag for users. We've had instances where users were assigned simple passwords by helpdesk operators who cleared this flag. We have log data (DC events) available in Log Analytics, and I'm using event ID 4724 to track password changes made by the helpdesk, followed by event ID 4738 indicating that the user account was changed. We can also see the 'PasswordLastSet' timestamp or the code %%1794 indicating the password expired. If we receive a 4724 event, I need to check for a 4738 event within 5 seconds from the same account, with the target account matching the user whose password was reset. With over 5,000 password resets each month, I'm looking for a KQL query that could help track this efficiently, instead of manually monitoring each instance. Any thoughts or assistance would be greatly appreciated!
5 Answers
Consider adjusting the permissions for your Helpdesk staff so they can't clear that flag at all. If they reset a password, the flag will stay intact. This might require some changes to your AD schema though, so ensure you're running on a suitable version.
You could also engage with your supervisors to reinforce stronger password policies for the helpdesk. Having strict guidelines may help limit these kinds of resets and simplify your tracking.
For your SIEM, if you’re using Sentinel, you should be able to track these events without issue. Just ensure you’re capturing all changes accurately. The missing %%1794 event can definitely complicate things, though.
Yea, the independent events can throw a wrench in what you're trying to achieve. Have you considered reaching out to support for more details on configuring it correctly?
You might want to explore the option of using PowerShell to check/reset the flag. With the Get-ADUser command, you can retrieve details like PasswordLastSet. Just keep in mind it may not help if a password is still expiring, since that will override it. You could also look into automating the tracking with alerts based on your logs.
Exactly! You’ll want to account for that in your workflow, especially if passwords are expiring too soon.
True, that command won't prevent the expiration. If the reset was done correctly, it should set a new expiration date automatically.
I think there’s a specific PowerShell command to set it up so that the box can't be cleared for password resets. Just check whether it applies only to the DC you use it on or across the board, including RSAT.
Sounds good, but you’ll be surprised at how many places still run on older schemas, like 2003. Make sure your infrastructure is updated!