Performing Service Account Audit
Overview
Audit service accounts across enterprise infrastructure to identify orphaned, over-privileged, and non-compliant accounts. This guide covers discovery of service accounts in Active Directory, cloud platforms, databases, and applications, assessing privilege levels, identifying missing owners, and enforcing lifecycle policies.
Objectives
- Discover all service accounts across AD, cloud, databases, and applications
- Identify orphaned accounts with no valid owner or associated application
- Assess privilege levels and flag over-privileged service accounts
- Check for non-rotating passwords and weak authentication
- Map service account dependencies for safe remediation
- Generate compliance reports for SOX, PCI DSS, and HIPAA audits
Key Concepts
Service Account Types
- AD Service Accounts: Windows services, scheduled tasks, IIS app pools
- Managed Service Accounts (gMSA): AD-managed automatic password rotation
- Cloud IAM Service Accounts: AWS IAM roles/users, Azure service principals, GCP service accounts
- Database Service Accounts: Application connection accounts, replication accounts
- Application Service Accounts: API keys, bot accounts, integration accounts
Audit Dimensions
- Ownership: Who is responsible for this account?
- Purpose: What application/service uses this account?
- Privileges: What permissions does this account have?
- Authentication: How does this account authenticate (password, key, certificate)?
- Rotation: When was the credential last changed?
- Activity: When was this account last used?
Implementation Steps
Step 1: Discovery - Active Directory
- Query AD for all service accounts (filter by description, OU, naming convention)
- Identify accounts with
ServicePrincipalNameset - List accounts in privileged groups (Domain Admins, Enterprise Admins)
- Check for gMSA vs traditional service accounts
- Identify accounts with
PasswordNeverExpiresflag
Step 2: Discovery - Cloud Platforms
- AWS: List IAM users with access keys, check last used date, identify unused roles
- Azure: Enumerate service principals, app registrations, managed identities
- GCP: List service accounts, check key age, identify unused permissions
Step 3: Assessment
- Flag accounts with admin/privileged group membership
- Check password age against rotation policy (90 days max)
- Identify accounts with no login activity in 90+ days
- Verify account ownership against CMDB/asset inventory
- Check for shared credentials (same password hash across accounts)
Step 4: Risk Classification
- Critical: Domain/cloud admin privileges, no password rotation
- High: Access to sensitive data, no identified owner
- Medium: Standard service permissions, password older than 90 days
- Low: Read-only access, managed credentials (gMSA, managed identity)
Step 5: Remediation
- Disable orphaned accounts after validation with application teams
- Convert traditional service accounts to gMSA where possible
- Rotate credentials older than policy threshold
- Reduce privileges to minimum required
- Assign owners and document dependencies
Security Controls
| Control | NIST 800-53 | Description |
|---|---|---|
| Account Management | AC-2 | Service account lifecycle |
| Account Review | AC-2(3) | Periodic review of accounts |
| Least Privilege | AC-6 | Minimum service account permissions |
| Authenticator Management | IA-5 | Service credential rotation |
| Audit Review | AU-6 | Review service account activity |
Common Pitfalls
- Disabling service accounts without verifying application dependencies first
- Not discovering service accounts outside of Active Directory
- Missing cloud service principals and managed identities
- Not checking for interactive logon rights on service accounts
- Failing to document dependencies before remediation
Verification
- [ ] Service accounts inventoried across all platforms
- [ ] Each account has assigned owner
- [ ] Privileged service accounts documented with justification
- [ ] Password rotation compliance checked
- [ ] Orphaned accounts flagged for remediation
- [ ] gMSA migration candidates identified
- [ ] Compliance report generated
Compliance Framework Mapping
This skill supports compliance evidence collection across multiple frameworks:
- SOC 2: CC6.1 (Logical Access), CC6.2 (Credentials), CC6.3 (Provisioning)
- ISO 27001: A.9.1 (Access Control), A.9.2 (User Access Management), A.9.4 (System Access Control)
- NIST 800-53: AC-2 (Account Management), IA-2 (Identification), AC-6 (Least Privilege)
- NIST CSF: PR.AC (Access Control)
Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.
Deploying This Skill with Claw GRC
Agent Execution
Register this skill with your Claw GRC agent for automated execution:
# Install via CLI
npx claw-grc skills add performing-service-account-audit
# Or load dynamically via MCP
grc.load_skill("performing-service-account-audit")
Audit Trail Integration
When executed through Claw GRC, every step of this skill generates tamper-evident audit records:
- SHA-256 chain hashing ensures no step can be modified after execution
- Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
- Trust score impact — successful execution increases your agent's trust score
Continuous Compliance
Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.