When “password reset” automation causes more lockouts than it fixes
A pattern I keep seeing in enterprise service desks: you automate password resets / account unlocks (Teams bot, portal flow, etc.), but a subset of users (often service accounts or users with stale cached creds on scheduled tasks) get re-locked within minutes.
The result is a nasty loop:
- User requests reset/unlock
- Automation resets password / unlocks
- Background process retries old creds → account locks again
- Service desk gets blamed, tickets bounce between IAM + app owners
- Auditors ask: “Who approved this reset? Where’s the evidence?”
This is a classic “ticket → action gap” problem: AI/chat can suggest steps, but you still need a deterministic execution layer that enforces policy, sequences actions safely, and leaves an audit trail.
Autom Mate fits well here as the execution + control layer between the request channel (Teams/portal) and identity systems, with governed orchestration, logging, and exception handling. eend-to-end)
1) Trigger
- Trigger: ServiceNow (or TOPdesk/Freshservice) request item “Reset password / Unlock account” OR a Teams chat intent (“I’m locked out”).
2) Validation (context + policy chns a validation hyperflow before touching identity:
- Confirm requester identity (e.g., MFA/OTP step in the chat experience) (implementation depends on your channel design)
- Pull user context from ITSM ticket fields (user email, affected system, urgency)
- Policy checks:
- Is this a human user vs service account?
- Is the account in a “high-risk” group (privileged / finance / production support)?
- Has this account been reset/unlocked more than N times in 24h?
If policy fails, Autom Mate routes to manual handling and records why.
3) Approval (human or rule-based)
- If standard user + low risk: auto-approve
- If privileged/service account or repeated lockouts: require approval from IAM on-call (Teams approval card) and/or CAB-style approval depending on your controls
This is where governance matters: AI should not directly take action in identity systems without guardrails, because a wrong reset/unlock can create security exposure or break production dependencies.
4) Deterministic execution across systems
Autom Mate executes a sequenced runbook (not “best effort”):
- Autom Mate library: ITSM action to update the ticket with “Validation passed / approval received / execution started” and attach execution metadata. (ITSM integrations are a core Autom Mate pattern.)
- Autom Mate library: Identity action in **Azure AD / Entr and/or unlock).
- REST/HTTP/Webhook action (fallback): Call an internal endpoint to:
- enumerources (scheduled tasks, services, app pools)
- disable or rotate credentials safely
- or open a child task to the app owner with exact remediation steps
5) Logging / audit
Autom Mate writes an auditable trail:
- Who requested it, who approved it, what policy gates were evaluated
- Exact actions executed (with timestamps)
- Ticket updates + correlation IDs
Autom Mate supports execution logs, audit logs, and monitoring/analytics for workflow performance and bottlenecks.
6) Exception handling / rollback
If the account locks again within X minutes:
- Autom Mate autens/escalates the ticket
- posts to Teams channel with “probable cached creds / scheduled task” hypothesis
- creates a linked task for the owning team
Autom Mate supports error handling rules (retry, alert, route, log) so failures don’t silently break your automation.
Why this is a real ops problem (and why it keeps recurring)
- Password resets and lockouts are a major driver ofand “automation” often fails when background processes keep retrying old credentials.
- Without a governed execution layer, teams end up with partial automation: chat/AI intake + manual identity actions + weak auditability.
Two mini examples
Mini example 1: “VIP user locked out”
- Trigger: Teams message “locked out”
- Validation: user is in a privileged group → requires IAM approval
- Execution: Autom Mate unlocks + forces password reset, updates ServiceNow, and posts confirmation back to Teams
- If relock occurs: Autom Mate escalates to Problem Management with evidence attached
Mini example 2: “Service account keeps locking after reset”
- Trigger: ServiceNow request “reset svc_sqlbackup”
- Validation: service account + repeated resets in 24h → requires approval + mandatory child task creation
- Execution: Autom Mate resets password in Entra/AD, then calls internal REST endpoint to rotate the credential in the dependent job runner
- Exception: if dependency update fails, Autom Mate rolls back by disabling the account and paging the owner (preventing repeated lockouts and noisy tickets)
Discussion questions
- Where do you draw the line between standard password resets (auto-approved) and high-risk resets (approval required)?
- If you’ve tried automating resets/unlocks before: what’s your #1 failure mode—identity verification, approvals, or downstream dependency updates?