We recently needed to terminate a user quickly, which led me to build a script for the first-response steps instead of handling everything manually. It can revoke sessions and MFA, reset credentials, block sign-in, and perform other actions while keeping the process reasonably reversible.
I'm interested in what other administrators include when responding to a termination, suspected insider threat, or compromised credentials. Our environment uses a hybrid on-premises directory and Microsoft cloud services, with Azure Virtual Desktop and several applications that do not support single sign-on.
Our current process is to revoke sessions, revoke MFA registrations, reset the password, block sign-in, disable the on-premises directory account, and then check Azure Virtual Desktop for active sessions and remove the user manually. Revoking sessions alone does not reliably disconnect an active AVD session, so that has become an important separate step.
What else should be disabled, revoked, reset, or checked to make sure access is removed as quickly and thoroughly as possible? I'm also interested in script design, verification, rollback safety, VPN handling, application-specific sessions, and credentials or API keys the user may have created.
5 Answers
Do not assume session revocation disconnects every active session. Azure Virtual Desktop is a good example: an active session may remain usable, so it needs to be located and terminated separately. The same can apply to conferencing tools, VPN clients, SaaS applications, and other services that maintain their own sessions. If the person has a managed laptop, forcing a reboot or applying a device lock or wipe policy may also be appropriate, depending on the circumstances.
The technical procedure should be coordinated with HR and the manager, with a clear trigger and authorization path. Ideally HR automation starts the identity shutdown, while the emergency script handles the remaining systems and produces an audit record. If advance notice is impossible, having a rehearsed runbook, named owners for non-SSO applications, and a post-lockdown verification checklist is more valuable than relying on a single large script.
Make the script report results per system rather than returning one overall success message. For every action, record whether it was requested, accepted by the service, verified afterward, or left for manual follow-up. An unavailable legacy application should remain clearly marked as incomplete. For reversibility, save the relevant pre-change state and use a separately approved restoration process instead of blindly reversing every command; otherwise you could restore access that was already disabled before the incident. Keep passwords, tokens, and other secrets out of the logs.
A test account with active sessions in the real mix of applications is useful for validating this. Deliberately make one step fail and confirm the operator can immediately see what access remains.
Also look beyond the user’s named account. Rotate or revoke API keys, personal access tokens, SSH keys, certificates, service credentials, shared passwords, and cloud resources the person created or knew about. Check for delegated mailbox access, shared accounts, scheduled jobs, automation tokens, and administrative roles. Those are easy to miss and can provide access for a long time after the directory account is disabled.
Start with the identity provider: disable the on-premises and cloud directory accounts, block sign-in, reset the password, and revoke all active sessions and refresh tokens. Disable VPN access, building access, and any other centrally managed access tied to the identity. Applications without SSO still need to be handled directly, since their sessions may continue after the main account is disabled.
That covers most of our environment too, but legacy applications and third-party services are the gaps. We keep a separate checklist of those systems so they do not get forgotten during an urgent event.
We also check whether the user sent anything during the incident. In one case, messages had to be removed from recipients’ mailboxes after the account was locked, so mail and collaboration tools should be part of the response plan.