What Makes Service Accounts Different
Service accounts are domain user accounts used by applications, services, and automated processes rather than by humans. They authenticate to network resources, run scheduled tasks, execute backup jobs, connect to databases, and perform inter-application communication. They are everywhere in an Active Directory environment, and in most organisations they are the least-governed identity type.
The security properties that distinguish service accounts from user accounts create a specific risk profile:
- No MFA. Service accounts authenticate using password credentials only. Multi-factor authentication cannot be applied to a non-interactive account that needs to authenticate autonomously. This means credential compromise is the only barrier to impersonation — and that barrier depends entirely on password quality.
- Passwords set at deployment, never changed. When a service account is created, a password is set and entered into application configuration. Changing that password later requires updating every application that uses it — a process that is operationally complex and frequently skipped. It is common to find service account passwords that have not changed in five, seven, or ten years.
- Shared across applications. To reduce the number of accounts to manage, the same service account is often used by multiple applications. A single compromised credential then grants access to everything that account is used for.
- No human monitoring their behaviour. A service account logging in at 3am on a Sunday to a system it does not normally access generates no helpdesk call and no user complaint. Anomalous behaviour by a service account is only detectable if there is monitoring specifically designed to baseline and alert on non-human identity activity.
The Privilege Problem
Service account privilege accumulation follows a predictable pattern. At deployment, the application vendor states that the account "requires admin rights" or "needs broad access to the file system." The administrator grants the requested access — often Domain Admin, local admin on all servers, or unrestricted file share access — because it is the path of least resistance and the application needs to work. The access is never reviewed because the application continues working and the account never generates a security incident.
The Domain Admin Service Account Problem
In a typical medium-sized Active Directory environment, between 5% and 15% of service accounts have Domain Admin or equivalent rights. The most common reasons are: (1) a vendor required it and the alternatives were not investigated; (2) an administrator granted it during a troubleshooting exercise and did not remove it; (3) the account was originally created by a domain admin and inherited that membership; or (4) the account needed access to a single sensitive resource and domain admin was the simplest way to provide it.
A Domain Admin service account with a five-year-old password and an SPN registered is one successful Kerberoasting attempt away from a full domain compromise. The attacker does not need to be on the network at the time. They take the ticket offline, crack the password using a GPU cluster, and return with valid domain admin credentials.
Local Admin Proliferation
Beyond Domain Admin, service accounts commonly hold local administrator rights on server groups. Backup service accounts need local admin to access all files. Monitoring agents need local admin to install and run. Deployment tools need local admin to push software. The cumulative effect is that compromising a service account with local admin across 200 servers gives the attacker the ability to harvest credentials from all 200 systems using pass-the-hash or similar techniques — without triggering domain-level alerts.
Enumerating Your Service Account Landscape
Before controls can be applied, the full service account population must be known. This is harder than it sounds — service accounts are not categorised separately from user accounts in Active Directory by default, and many organisations do not have a definitive inventory.
Identification Approaches
Service accounts can be identified through a combination of:
- SPN enumeration. Any account with a Service Principal Name registered is being used (or was used) for Kerberos service authentication.
setspn -T yourdomain -Q */* returns all SPN-bearing accounts.
- Account naming conventions. Many organisations prefix service accounts with
svc-, sa-, or similar. Querying accounts with these prefixes returns a subset of service accounts, but naming conventions are inconsistently applied.
- Non-interactive logon history. Accounts whose logon history shows exclusively service logon types (Type 5 — Service, Type 4 — Batch) without interactive logons (Type 2) are likely service accounts.
- Password age distribution. User accounts typically show passwords reset within the past 90 days due to password policy enforcement. Service accounts frequently have passwords hundreds or thousands of days old — a password age outlier analysis identifies candidates.
- Group membership audit. All members of Domain Admins, Enterprise Admins, and Backup Operators should be reviewed for non-human accounts.
Undiscovered Service Accounts
Assessment consistently finds service accounts that no one in the IT team knew existed. These typically come from: (1) legacy applications deployed years ago by personnel who have since left; (2) vendor-installed software that created its own service account during installation; (3) acquired companies whose AD was merged without a full identity review. The risk from an unknown service account with privileged access is identical to the risk from a known one — but the unknown account will not appear in any access review, off-boarding check, or periodic password rotation programme.
Controls: Moving to Managed Service Accounts
The most effective remediation for service account security is migration to Active Directory managed account types that remove the password management problem entirely.
Group Managed Service Accounts (gMSAs)
A gMSA is a managed domain account where Active Directory automatically generates and rotates the password — a 240-character random string, rotated every 30 days. The password is never known to any administrator or engineer. Applications retrieve it directly from AD via the Key Distribution Service. The result is that even if a Kerberos service ticket is extracted and an offline attack is attempted, the password will never be cracked in any useful timeframe.
gMSAs are supported by Windows services (Windows Server 2008 R2+), IIS application pools, Task Scheduler, SQL Server Agent, and most Microsoft services. They are not supported by applications that require a static credential entered into a configuration file. For those applications, Managed Service Accounts (MSAs, single-server variant) or a PAM vault with dynamic credential injection are alternatives.
Least Privilege Scoping
Parallel to gMSA migration, service account privilege should be scoped to minimum required access. This requires working with application owners to determine what the account actually needs — which is frequently less than what was granted. Common findings from privilege reduction exercises:
- SQL Server service accounts with domain admin replaced with Log on as a service right and SQL-specific permissions
- Backup accounts with domain admin replaced with local admin on backup targets only
- Monitoring agent accounts with domain admin replaced with read-only WMI and Event Log access
- Application integration accounts with broad AD read replaced with targeted LDAP query permissions via ACLs on specific OUs
Interim Controls for Accounts Not Yet Migrated
Where migration to gMSA is not immediately possible, interim controls reduce risk. Set passwords of 25+ characters with full entropy. Enforce AES-only Kerberos encryption on the account. Restrict logon rights using Group Policy to specific source systems (Log on locally and Allow log on through Remote Desktop Services denied for non-target systems). Add the account to the Protected Users security group where the application supports it — this prevents NTLM authentication and forces AES Kerberos, significantly raising the bar for credential extraction.
Monitoring Service Account Behaviour
Even with strong controls in place, behavioural monitoring of service accounts provides a detection layer for unexpected credential use.
Baseline and Alert on Anomalies
Service accounts have highly predictable authentication patterns — they log in to the same systems, at the same times, from the same source IPs. Deviations from this pattern are high-fidelity alerts: a service account authenticating to a new system it has never accessed, authenticating from a workstation rather than a server, or changing its authentication time pattern. These patterns require SIEM correlation with a baselining capability, or a dedicated IAM tool that understands non-human identity behaviour.
Event IDs to Monitor
Key Windows Security event IDs for service account monitoring: 4624 (successful logon — track Logon Type 5 for service, Type 4 for batch); 4625 (failed logon — repeated failures against service account credentials indicate credential stuffing); 4648 (logon with explicit credentials — indicates pass-the-hash or credential forwarding); 4769 (Kerberos service ticket requests — identify unexpected SPN access patterns).
Service Account Inventory and Risk Assessment
IdentityFirstMRI produces a complete service account inventory — SPN-bearing accounts, password age, privilege level, Kerberoasting exposure, and gMSA readiness — without requiring credentials beyond read-only AD access. The output is a prioritised remediation plan ordered by privilege level and attack surface.
Active Directory Security Assessment