Automate credential rotation for service accounts across Active Directory, cloud platforms, and application databases to eliminate stale secrets and reduce compromise risk.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
performing-service-account-credential-rotation
description
Automate credential rotation for service accounts across Active Directory, cloud platforms, and application databases to eliminate stale secrets and reduce compromise risk.
Service accounts are non-human identities used by applications, daemons, CI/CD pipelines, and automated processes to authenticate to systems and APIs. These accounts often have elevated privileges and their credentials (passwords, API keys, certificates, tokens) are frequently long-lived and shared across teams, making them prime targets for attackers. Credential rotation is the systematic process of replacing these secrets on a scheduled basis, propagating new credentials to all dependent systems, and verifying service continuity after rotation.
When to Use
When conducting security assessments that involve performing service account credential rotation
When following incident response procedures for related security events
When performing scheduled security testing or auditing activities
When validating security controls through hands-on testing
Common Misconfigurations & Verification
Incomplete consumer propagation: rotation breaks services when the new secret is updated at the source (AD/IAM/DB) but not in every consumer — app config, CI/CD pipeline secrets, Kubernetes secrets, scheduled tasks, connection pools. Map dependencies first; an unmapped consumer is an outage waiting to happen.
Old credential never revoked: deactivating is not deleting. After the grace period, confirm the prior AWS access key is deleted (not merely set Inactive), the old AD password no longer authenticates, and superseded GCP/Azure keys are removed — a stale-but-valid key defeats the rotation.
gMSA eligibility assumed: gMSA only fits Windows services that support it; SQL linked servers, DCOM identities, and some third-party agents do not. Verify with Test-ADServiceAccount before cutover.
No post-rotation verification: rotating without a health check hides breakage until the next business cycle. Run authentication and functional smoke tests against each dependent service after rotation.
Verify: confirm rotation events are logged and auditable, alerting fires on rotation failure, the rollback procedure is tested, and credential age now sits within the 30–90 day policy window.
Prerequisites
Inventory of all service accounts across AD, cloud, and applications