Service accounts are a special type of non-human privileged account used to execute applications and run automated services, virtual machine instances, and other processes. Service accounts can be privileged local or domain accounts, and in some cases, they may have domain administrative privileges. This high level of privilege facilitates the smooth operation of many IT workflows, but a single service account can easily be referenced in many applications or processes. This interconnection, along with the critical nature of their usage, makes them very difficult to manage.
In this post we will explore how service accounts work, some common use cases and account types across different environments, challenges in managing service accounts, and best practices and solutions for managing and securing service accounts.
What is a Service Account?
Service accounts run automated business processes and are used by applications, not people. They can be stored in services, tasks, COM objects, Internet Information Services (IIS), SharePoint, databases, and applications. A single service or process account may be referenced in multiple places.
Many servers use local accounts - like root on Linux and administrator on Windows - to run persistent applications, whether or not someone logs into the machine. For example, a web site would be an example of a persistent application , as would a database or other line-of-business application.
Service accounts are needed for these persistent applications so that they can perform actions on behalf of the users of the application. In other words, service accounts are proxies for performing limited actions for users that have no access to sensitive data and systems.
In many cases, the mechanics of service accounts means that an account must be known and verifiable to, not only the application, but also everything that the application interacts with. Consequently, the service account is generally a powerful access credential.
Generally, service accounts are created and configured by the package manager during installation of the service software. So, even as an administrator, humans are not (and should not) be directly in charge of the creation of service accounts.
Examples of Service Accounts in Windows, Unix, Linux, & the Cloud
Depending on the systems, service accounts are named differently. For example:
In UNIX and Linux: Service accounts are known as init or inetd and can execute applications.
In the cloud: Service accounts are referred to as cloud service account, cloud compute service accounts, or virtual service accounts.
Microsoft defines a service account as, “a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service’s ability to access local and network resources.” These service accounts often connect with mission-critical applications that have elevated privileges.
In Windows: Service accounts are known by the most common types listed here:
- LocalSystem
- NetworkService
- Local user account
- Domain user account
Challenges of Managing & Securing Service Accounts
Proper system functioning and business continuity depend on the functioning of the underlying services. The compromise or malfunction of a service account can potentially cause widespread system outages, particularly if an account is associated with multiple services.
The Password Challenge: The consequence of the service account structure means that any password change of a superuser credential must not only be performed in the authentication system (i.e. Active Directory), but also in every service/application that stores the password for that same credential. So, not only must you update the authenticator, but also all references. Updating all the places where a service account is stored is known as propagation.
If you miss any of the places that have a stored password, the wrong password will be used and that could spur cascading system failures. The use of an incorrect password by a service could even cause the operating system to think that the account is under attack and, consequently, lock out the account. This means that every service that uses that locked out account will now fail too.
Because of the implications of passwords that don’t correctly sync, many organizations simply choose to ignore the issue, rather than risk downtime. Consequently, service accounts are often configured with non-expiring credentials that remain unchanged for years!
The Access Challenge: Service accounts have privileged access on the local system and, in some cases (i.e. Windows domain accounts,) access to off-system resources. While a service account rarely requires Domain Admin level rights, they often are over-privileged as an easy way to overcome any potentially unforeseen operation challenges that may impact service continuity.
The Administration Challenge: Since service accounts are not directly associated with a human identity, access of service accounts requires sharing of the credentials for those accounts. This sharing of credentials dilutes accountability and makes oversight of service accounts difficult. For instance, while an asset or system associated with a service account may no longer be needed, the service account often remains because no human is directly responsible for it. Likewise, temporary service accounts, often used for software installation or maintenance, can be left in place long after their initial use, far too often with default passwords still in place.
Centralized provisioning of service accounts has traditionally posed a challenge due to the disparate origin of these accounts (Windows, Unix, Linux and the Cloud have separate accounts, provisioned individually when the software they manage is installed). As a consequence, many organizations manually provision service accounts.
Given the complexities around service account management, some IT teams take the approach of manually managing service account credentials. This is a tedious, error-prone, and potentially disastrous, process. Manual rotation requires identifying everywhere the credentials exist and executing a change whenever the credential is used. As mentioned earlier, an errant credential change can disrupt services and cause critical systems to go down. Additionally, just as with other instances of password management, humans invariably fall into the trap of using easy to remember credentials, or reuse credentials across multiple accounts. When credentials are re-used, the exploit of one instance can potentially lead to the compromise of all the accounts that share the same password.
The Visibility and Auditing Challenge: Service accounts create some visibility issues that are common to all types of machine/non-human accounts. Since they typically run in the background without the interaction a human user, they may avoid scrutiny and oversight, so long as services seem to be operating smoothly. Additionally, most organizations suffer from a sprawl of service accounts, including orphaned accounts that are forgotten and/or no longer used. It’s possible that multiple identities (users) have access to a service account, and share the same login details. This means it may be impossible to connect a single user’s actions to any changes to the service account.
Put simply, most organizations have serious service account lifecycle management deficiencies when it comes to addressing provisioning, onboarding, enforcement of security best practices, session auditing, and de-provisioning, etc.) of service credentials.
The management challenges of service accounts also encapsulate why the accounts are prized and sought after by hackers.
Best Practices for Effective Service Account Management
Service accounts should be carefully managed, controlled, and audited. In most cases, they can also be associated back to an identity as an owner. However, service accounts should not have the same characteristics as a person logging on to a system. They should not have interactive user interface privileges, nor the capability to operate as a normal account or user. Depending on the operating system or infrastructure, this could encompass restricting everything from executing a batch process, to not having a proper shell assigned to the account. Service accounts should also not be delegated to any form of just-in-time (JIT) access model.
What is the most effective and secure way to tackle this service account management challenge? The best approach is two-fold. The first element requires an immediate plan to identify and bring all accounts under centralized management. The second element entails implementing an ongoing program based on automated onboarding and management of new accounts.
Phase I: Identify and bring all accounts under centralized management
Discover and Onboard All Service Accounts via Automation
If you do not know where all your privileged service accounts are, you cannot fully control and audit their usage. The first priority, as with all other types of accounts, is to deploy a method of continuous identification and cataloging so they can all be brought under centralized management.
BeyondTrust’s solution can discover every location throughout the network where a service account is referenced. Once profiled and classified, the solution can automatically bring accounts under management through simple, out-of-the-box configuration that helps organizations accelerate account onboarding and risk mitigation.
Phase II: Automate onboarding and management of new accounts
Automate New Service Account Onboarding
Given the dynamic nature of IT environments, auto-discovery capabilities save time and ensure that no account is left unmanaged. Automatically profiling and classifying accounts ensures that new service accounts are immediately brought under control, removing the complexity and risk of manual administration. This enables complete visibility over all privileges in an environment. BeyondTrust Password Safe continuously brings new accounts under management through Smart Rules. The product helps organizations control service accounts control via centralized management and a full audit trail.
Secure and Monitor Access to Service Accounts
Privileged credentials (passwords, SSH keys) associated with service accounts need to be centrally secured within an encrypted credential safe. Access to these credentials should be controlled and monitored to mitigate the risk of misuse.
Password Safe automates privileged credential and privileged session management, providing secure access control, auditing, alerting, and recording for any privileged account, including service accounts.
Effectively Propagate Credentials
As service account credentials are changed, the automatic propagation of credentials to all places where they are referenced is a critical factor in preventing systems failures and downtime.
Password Safe can dynamically discover service account enumeration before changing service account passwords every time it executes a credential change. The product can also propagate the credentials with speed and accuracy to prevent application downtime due to credentials being out of sync.
Additional Best Practices around Service Account Provisioning
Apply the Principle of Least Privilege (PolP): When creating a service account, it is advisable to create accounts with the minimum privilege required to complete the target tasks. For example, a few additional privileges that can generally be removed include remote access functionality, internet, and email access and remote-control rights. Access control lists (ACLs) can be used to define resources to assets. As part of this process, you should identify all the resources a service account can access, determine the appropriateness of that access, and make any necessary changes to ensure least privilege is enforced. As part of least privilege, you should also strive to minimize the number of service accounts associated with an identity.
Avoid Putting Service Accounts in Built-in Privileged Groups: Assigning service accounts in built-in privileged groups, such as the local Administrators or Domain Admins group, can be risky. All users in the group will know the service account’s credentials, and those credentials can be misused or compromised.
Have a Break Glass Plan for Service Accounts: At some point—whether due to a network outage, a broken application, or a natural disaster—your organization may need re-establish secure access to your critical systems. You need to have a plan for outage scenarios that may disrupt the availability of your service account password management solution. In these instances, when the password of a service account may not be known, so a service will no longer start, try to initiate these troubleshooting steps to re-establish a service:
- Randomize the password of the service using the functional account.
- Establish a privileged connection to the system using a stored credential and manually set the service account password before automating password management.
For more information on accessing privileged credentials during break glass scenarios, check out this white paper.
Solutions for Securing & Managing Service Accounts
Service accounts are critical to the smooth operation of most IT systems. Manual management of these critical accounts simply won’t scale or meet the security and auditing requirements of modern enterprises.
Today, organizations can leverage solutions to help them automate the discovery and management of service accounts, while securing, controlling, and auditing access to them. Automation is essential to mitigating the risk of service account sprawl and protecting your enterprise from the risks of compromised privileged credentials.
BeyondTrust Password Safe combines privileged password and session management to discover, manage, and audit all privileged credential activity. With BeyondTrust, you can easily control privileged user accounts, service accounts, applications, and more, with a searchable audit trail for compliance and forensics.
Related Resources
Download BeyondTrust's FREE Discovery Tool
Privileged Password Management Explained (white paper)
How to Access Privileged Passwords in ‘Break Glass’ Scenarios (white paper)
Alex Leemon, Director, Product Marketing
Alex Leemon is Director, Product Marketing at BeyondTrust. She has over fifteen years of experience working with enterprise-level and Critical Infrastructure organizations solving safety and security challenges. Before joining BeyondTrust, Alex served in various roles related to the development of operational technology (OT) products and the Industrial Internet of Things (IIoT).
