As far as problems go, this is a bad one. Besides the obvious problem of not being able to login and do useful things, it really points to a whole series of security problems and risks for your organization.
So to keep this post to something manageable, I’m going to limit the scope – let’s assume that you have another domain admin account that you can use – maybe a recovery account of some sort.
To start with, get logged in using another admin account. Then open the event log on your DC, and start filtering in the security log for event ID “627”, and possibly your administrator user name if you anticipate a good deal of recent password changes. Here’s a link to a good resource on Security Audit events to filter for. Now, once you’re confident that you have the date/time, go back into the security log properties and disable the filtering. Browse back to the date/time of the event of interest and take a look around that line. If it happened from a workstation, you should see ID’s 680 – which will give you the machine name, 627 which is the change attempt. At the very least, it will narrow down the list of those suspected of changing the password.
What happened that prompted you to post this?
A situation that a customer reported; they had distributed the admin credentials to multiple people in the organization. In this case, the change was probably not malicious, but without a backup account, this issue might have been very time consuming to resolve
No comments:
Post a Comment