Overview
Service Accounts are non-human identities used by applications, scripts, and services to talk to each other. They are the "silent majority" of privileged accounts and often the weakest link.
Why?
- Over-privileged: "Just make it Domain Admin so it works."
- Static Passwords: "Don't change the password, it might break the app."
- No Ownership: "The guy who set this up left 5 years ago."
- Hardcoded: The password is in the config file in cleartext.
Service Account Management (SAM) aims to discover, secure, and rotate these credentials without causing outages.
Architecture
Reference Pattern: Application Identity
We want to move from Static Passwords to Dynamic/Managed Identities.
Diagram
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Identity Type | Domain User, gMSA, Managed Identity | Managed Identity / gMSA | Use Azure Managed Identity or Windows gMSA (Group Managed Service Account) where possible. No passwords to manage! |
| Rotation Strategy | Manual, Agent-based, Restart | Agent/Restart | Most apps need a restart to pick up a new password. Coordinate rotation with maintenance windows. |
| Discovery | Scan, Declare | Scan + Analyze | Scan the network to find where accounts are used (Scheduled Tasks, Services, IIS Pools). |
| Ownership | IT, App Owner | App Owner | IT cannot own the risk of the application breaking. The App Owner must approve rotation. |
| Interactive Login | Allow, Deny | Deny | Service accounts should NEVER log in interactively. Deny this via GPO. |
Implementation
Phase 1: Discovery & Triage
- Find all Service Accounts (SPNs, Services).
- Identify owners. If no owner, disable (scream test) and decommission.
- Goal: Know what you have.
Phase 2: Hardening
- Remove "Domain Admin" rights. Grant least privilege.
- Enable "Logon as Service" only. Deny interactive login.
- Set up alerting for any interactive use.
- Goal: Reduce the blast radius.
Phase 3: Vaulting & Rotation
- Move static credentials to the Vault.
- Update apps to retrieve credentials via API (or sidecar).
- Enable automated rotation (e.g., every 30 days).
- Goal: Eliminate static, long-lived secrets.
Risks
- Outages: Rotating a password while the app is running can cause connection failures.
- Dependency Hell: One service account is used by 50 different scripts. Rotating it breaks 49 of them. You must map dependencies first!
- Hardcoding: Even if you rotate the AD password, the app might have the old password hardcoded and will lock out the account by retrying.
- Legacy Apps: Some old apps simply do not support API calls or dynamic secrets.
KPIs
- Rotation Frequency: Average age of service account passwords (Target: < 90 days or Managed/Daily).
- Interactive Logon Rate: Number of service accounts with "Interactive Logon" enabled (Target: 0).
- Hardcoded Secret Reduction: Number of applications migrated from config files to Vault/API retrieval.
- Ownership Coverage: Percentage of service accounts with a valid, active business owner.