Service Accounts
What Is a Service Account?
A service account is a special user account that is created explicitly to provide a security context for services. The security context determines the service's ability to access local and network resources. That security context should have the least amount of privileges needed to do its tasks. Service accounts run automated business processes and are typically found stored in system services, scheduled tasks, COM objects, web servers, SharePoint, databases, scripts and applications. They can be created automatically when installing a program or package, or you may create one locally or request one from ITS.
Why Should I Not Use a User Account?
Excessive Privilege
Regular user accounts are not suitable replacements for service accounts. Regular user accounts often have access to many different resources, and have excessive privileges. If a user account is compromised, the bad actor now has access to the functions run by the user account. We want service accounts to be configured for lease privilege.
Credential Problems
Most services use an account name and password to run. If using a regular user account, the user must provide their credentials. Users often change their passwords, however, and the stored credentials become invalid. Also, at Western, users may be enrolled in multi-factor authentication, which could cause the credentials to fail.
Multi-Factor Authentication (MFA) Problems
To secure user credentials, all staff and faculty accounts should be enrolled in MFA. Service accounts are generally non-interactive, so are not able to respond to a MFA prompt.
Types of Service Accounts
There are several different types of service accounts, and you should choose the service account type most tailored to your needs.
Local Service Accounts
are created on a single system. Local Service Accounts are often Local service accounts created during the install of a product on a system. These are typically, but not always configured for least privilege. Some installers may ask you to choose between using an existing account or creating a new account. Often, the existing accounts are highly privileged. We recommend creating a new account for the special purpose of that program/service if that option is available.
Local system administrators or users with account creation privileges may create Local Service Accounts for several purposes including running scheduled tasks, running scripts, or for use by an application. Often application install instructions may require a service account to be created prior to installation. The system administrator should create Local Service Accounts that have the least privileges necessary for their purpose. Please keep in mind that if the entity using the service account needs to access resources on another system, you will either have to do special configuration on the other system, and/or switch to using a Domain Account or Group Managed Service Account.
Using a Windows Managed Service Account in place of a Local Service Account is an improvement in security and manageability and should be evaluated as an alternative to a local service service account on Windows systems.
Domain Service Account
If you have an application or service that needs to connect to a different system to perform a task, it is better to use an Active Directory Domain Service Account. A Domain Service Account is simply a regular AD account that is only used for a service purpose. The access can be configured with least privilege on each system. Domain Service Accounts may also be used on Linux systems that are domain joined using SAMBA. Group Managed Service Accounts are an improvement in security and manageability and should be evaluated as an alternative to a domain service account.
Windows Standalone Managed Service Accounts
A Windows standalone Managed Service Account (MSA) is an improvement on using a regular Windows Domain Service Account. It is designed to isolate Domain Service Accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.
One MSA can be used for services on a single computer. MSAs cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. See Group Managed Service Accounts below for an option that works on multiple systems.
There are five key administrative benefits associated with MSAs:
MSAs offer enhanced security that is provided by having individual accounts for critical services
You can create a class of Domain Service Accounts that can be used to manage and maintain services on local computers.
Network passwords for MSAs are automatically reset.
You do not have complex service principal name (SPN) management tasks when using Managed Service Account.
Administrative tasks for Managed Service Account can be delegated to non-administrators.
See Microsoft’s documentation for details.
Windows Group Managed Service Accounts
Group Managed Service Account (gMSAs) are an extension of the standalone MSAs. These are managed Domain Service Accounts that provide automatic password management and simplified SPN management, including delegation of management to other administrators.
A gMSA provides the same functionality as a standalone MSA within the domain, but it extends that functionality over multiple servers. For services hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When gMSAs are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.
See Microsoft’s documentation for details.
SSH Keys
SSH keys are used extensively in Linux environments to authenticate between systems without using a password. They are highly secure. A client only needs the account name and a private key to communicate to a server. SSH keys are not commonly used on Windows systems, but they are available now on Windows 10 and Windows Server 2019, and can be an excellent alternative to a Domain Service Account.
Bad Practices
Using Highly Privileged Accounts
A hacker that steals highly privileged account credentials is a severe danger to Western. They could install ransomware, corrupt or delete data, spy on our network, and install malicious code. In short, using accounts with least privilege is your best option to avoid this disaster.
Using Built-in Accounts
Operating systems, web server software, databases, and applications often have built-in accounts. If possible, avoid running services/tasks with these accounts and create a new service account. If you have a choice of built-in accounts, choose one with the lowest privileges.
Reusing Service Accounts
Never reuse a service account for multiple applications/uses. If it is compromised, the attacker has access everywhere the service account is used.
Leaving Service Account Credentials Unsecured
If you are using an account that requires a password or private key, these secrets must be kept safe. These secrets should not be stored in an unencrypted file or on a piece of paper under your keyboard! Using a password manager is a best practice.
Informational Resources
Managed Service Accounts and Group Managed Service Accounts on Windows
How to Request a Service Account
Email the ATUS help desk at atus.help@wwu.edu. They can also provide consulting if you are unsure how to proceed.