ACTIVE DIRECTORY DEEP CORE
Service Accounts, SPNs and gMSA Deep Core
Applications need identities too. Treating every service like a person with a permanent password creates hidden operational and security risk.
Chapter purpose
Teach service identity as a lifecycle: ownership, least privilege, SPN registration, password management and retirement.
Learning objectives
- Explain service account vs user account.
- Explain the purpose of an SPN.
- Understand why managed service accounts reduce password-management risk.
- Document service identity ownership and dependencies.
Why this matters in a real company
Forgotten service accounts with old passwords and excessive rights are common hidden dependencies. Managed identities make application ownership and password rotation safer.
15.1 A service account is not an employee account
Service identities should have a named application owner, purpose, required logon rights and retirement plan. They should not be used for interactive daily administration.
Do not set 'password never expires' as a default solution to application fragility without understanding safer alternatives.
15.2 SPNs map a service name to an account
Kerberos uses Service Principal Names to identify service instances. Duplicate or missing SPNs can cause authentication fallback or failure.
SPN changes should be tied to service names and account ownership, not guessed during an outage.
setspn -L DOMAIN\svcApp
setspn -Q HTTP/app.corp.example.com15.3 Managed service accounts reduce manual secret handling
Group Managed Service Accounts can provide automatically managed passwords to supported Windows services across approved hosts. Application support must be verified before adoption.
A managed account does not remove the need for least privilege or ownership.
15.4 Operational lifecycle
- Register business/application owner.
- Choose user service account or supported managed account.
- Grant only required rights.
- Register/verify SPNs where needed.
- Monitor authentication.
- Rotate/migrate safely.
- Disable and remove when service retires.
Old application runs under Domain Admin service account
Nobody knows the password, the application has run for six years and the service account is a Domain Admin.
Decision: Treat this as a migration project. Identify required rights, test a least-privilege service identity and move the application with rollback.
What to prove: Application runs under the new identity and the old privileged account is removed/disabled after validation.
Hands-on lab
Inventory service identities in a lab, list SPNs and document which host/application owns each. Where supported, create a gMSA for a lab Windows service.
Troubleshooting exercise
- Kerberos fails only when using service DNS name. Query SPNs.
- Service fails after password change. Check stored credentials and dependent scheduled tasks/services.
- gMSA works on one host but not another. Check allowed principals and installation.
Field checklist
- Every service identity has owner.
- Interactive logon restricted where appropriate.
- Privilege minimized.
- SPNs inventoried.
- Password/managed-account strategy documented.
- Retirement process exists.
Chapter summary
Service accounts are infrastructure identities. Manage them with the same discipline as privileged users, but design around application requirements and automated credential management where supported.
Current technical references
The supplied historical books are used as curriculum and operational context. Current implementation details are checked against current Microsoft documentation.