I'm rotating service account passwords in a large organization, and a process still using the old password locked an account. Unlocking it and finding the source require separate tickets and a long wait. How can this process work better when access to lockout information is restricted?
How do you handle service account lockouts during password rotation?
Asked by
_q6!fusebasket.31
Answers
Build a rotation checklist for each account, including where it's used and who owns those systems. Before changing the password, stop the relevant processes or sessions, then update the stored credentials and bring things back up in a controlled order. Check that the services authenticate successfully afterward.
If you have access to security activity reports, look for computers that used the account recently and attach that information to the change ticket. It won't necessarily catch every dependency, but it gives you a starting point if something keeps retrying an old password.
Reply to this answer
For Windows domain accounts, ask the team with access to check event 4740 on the PDC emulator. The calling computer can point you toward the machine making the bad attempts. From there, check things like services, scheduled tasks and IIS app pools for stale credentials.
The computer name is a lead, not necessarily the whole answer. Someone still has to find which process or stored credential on that machine is responsible.
_q6!fusebasket.31:
That would help with the source lookup. I can't access the logs directly, though.
8n!sugarcube_274:
See if the security team can provide a limited report from their existing tool, rather than access to the domain controllers themselves.
Reply to this answer
Look into group managed service accounts where the applications support them. Windows manages the password, so you can avoid manual password rotation for those accounts. It won't cover every service, and migrating them is a separate project, but it could reduce how often you run into this.
Reply to this answer
Take the ticket delays to the team responsible for lockouts and ask them to help redesign the handoff. Maybe one request can cover both the unlock and the source lookup, or a designated group can get limited access to the information needed for troubleshooting.
The current permissions may be deliberate, so frame it around reducing downtime rather than asking for broad admin access. A shared password safe and clear account ownership can help with the rotation side too.
Reply to this answer
Ask whether the lockout policy has to require a manual unlock every time. A timed unlock might reduce delays, though the security team would need to weigh that against its reasons for the current policy. It also won't fix a process that's still retrying an old password.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Mivra-7q:
Also keep the account's known quirks in the checklist. A scheduled task or app pool can be easy to miss when you're focused on the main service.