Service account security best practices

There are number of privileges and roles granted to Windows users. However, it’s often necessary to restrict roles to specialized accounts called service accounts. These Active Directory (AD) accounts have deeper access to OS infrastructure, making them both handier and higher-priority attack targets. Service accounts also handle the installation of applications and core services.  

A couple of things thus become critical: that accounts are secure, and functional scopes are well defined. How does one do this? We’ll break down the three types of AD service accounts, and dive into some best practices. 

The service account trio 

Before managing and securing service accounts in Active Directory, it’s important to familiarize yourself with each type. 

1. Local user accounts: encompassing included accounts like the System account (local, multi-privilege administration), Local Service account (credential-less access to network services), and the Network Service account (more robust, credentialed access to network services). 

2. Domain user accounts: managed via AD and harnessed by services. These may include one account per service, or an account that many services share. Password changes are periodically mandatory and accounts are limited to privileges determined by their respective services.  

3. Managed service accounts (MSAs): subject to AD rules, and each account can only have one user per computer. However, each account can access multiple services (as desired), and password resets are handled automatically.  

Managed service accounts are typically the most secure of the bunch. They benefit from the strict permissions controls possible through AD, effectively enforcing RBAC, and maintenance automations. This commonly includes password changes and PowerShell scheduled tasks.  

Additionally, managed account passwords dwarf those of domain accounts and local accounts, measuring a whopping 120 complex characters in length. Domain account passwords have a 15-character minimum, whereas local accounts include 1 to 14 characters. Local user accounts might not even require passwords at all! 

MSAs can also be standalone (since 2008), or group-related; the latter functions across multiple servers, instead of just one server or device.  

As the name implies, local user accounts are confined to running on that specific machine. Trying to access a domain-based service? This is best reserved for domain accounts and MSAs. We can create services under these connected accounts, and assign users appropriately. Local accounts aren’t identifiable to external systems, hence why they have little utility outside of their respective bubbles.  

Best practices for securing service accounts 

Opinions will always vary where security and oversight are concerned. Conversely, there are sets of principles that most professionals find useful when managing service accounts. These are necessary to boost security and streamline task management.  

Grant privileges sparingly 

We know that AD’s service accounts exist to perform certain tasks. Our job should include removing the barriers to executing those workloads, with only the minimum permissions required to do so.  

Just like employees can only access certain remote resources to do their jobs, account owners should only access key layers of an OS, filesystem, network, or service. This goes hand-in-hand with authentication and authorization.  

Luckily, AD gives us case-by-case tools to elevate and downgrade access. It’s unlikely that we want to grant remote users unfettered control over a system. This opens the door to abuse or unintended accidents.  

Even your most-trusted users mustn’t be given the proverbial master key. Should a hacker gain control of a managed service account, poor privilege delegation can increase the blast radii of breaches. Think data leaks, malicious configurations changes, and services disruptions. Additionally, disgruntled employees can sabotage systems when given deep access.  

We don’t like to believe this, but situations do arise where friction (layoffs, termination, or otherwise) causes internal users to lash out. Accordingly, AD allows us to kill services access within any account, for any reason. Furthermore, service accounts shouldn’t exist within privileged groups. This exposes credentials to all members.  

Safeguard administrative rights 

Service accounts fill a very special role. They bridge the gap between permission-starved user accounts and low-level admin accounts, offering owners control to a certain point.  

We can assign admin rights to service accounts for very limited actions, like agent installation. Accounts revolving around Data Warehouse writing, Data Reader, System Center Configuration Service, and System Center Data Access must be members of key administrator groups.  

Unfortunately, there’s a common, problematic trend in the enterprise. Teams want account owners to “get things done” efficiently while sidestepping obstacles. Consequently, many service accounts have elevated rights where there shouldn’t. Domain accounts might properly request the following:  

• Domain user access 
• Operations systems access 
• AD object rights 
• System rights 
• Install permissions 

Admins, on the other hand, need full AD rights, privileged rights, and elevated rights on start and run. Managed service accounts and domain accounts shouldn’t enjoy power over all domains and controllers. The potential for systems and services meddling is too great. Accordingly, teams should strip excessive rights away.  

Perform regular audits 

Audits directly play into the aforementioned points. It’s essential to periodically inspect all service accounts and activity logs. We want to know what users are doing, what permissions they have, and if any permissions infringe upon pre-determined security guidelines. Audits can thus uncover suspicious activities or find vulnerabilities, either passive or active.  

Password policies are also crucial. How often are passwords rotated? How many characters do they have, and how complex are they? Do these accounts abide by the Active Directory Password Policy?  

The answers to these questions will determine any need for remediation. We also want to draw relationships between users and AD objects, assessing whether associations or activities match our intentions.  

Control vendor access 

It’s possible that external vendors might need service-account access when troubleshooting issues. Additionally, we want to limit which machine(s) a service account can access. A happy medium for vendors might include setup of specialized vendor accounts, which have access to a VM intermediary. From there, they can tap into targeted systems.  

Limit login scope and time 

Service accounts shouldn’t be able to access any machine within your infrastructure. Instead, savvy admins can restrict login privileges to certain computers. This prevents a service account from accessing sensitive data, or tampering with underlying configurations.  

Additionally, local users accounts might benefit from a timeout feature. Periods of inactivity can trigger sign-off, to prevent unintended users from gaining direct hardware access. Additionally, teams can limit user access to certain daytime hours.   

This makes monitoring easier. It also helps limit the creation of any “fires” that need extinguishing at odd times of day—especially when team members aren’t on call.  

Consider using third-party management tools 

Active Directory’s native tools (like Server Manager, ADAC and ADUC, or PowerShell) are useful for creating accounts, managing user permissions, and enforcing security policies.  

However, these tools aren’t for everyone. Different users have interface preferences and proficiency levels. There might also be better options for those who prefer automation over manual configuration. Making that change can save plenty of time and effort.  

For those seeking automated password auditing, we recommend Specops Password Auditor. The solution generates informative reports on the health (and compliance) of your service account’s passwords. It helps align password policies with industry standards, and even checks active passwords against a database of leaked passwords. It’s a superb tool for quickly highlighting the deficiencies and strengths of one’s infrastructure.  

There are many best practices in the service account realm. While these are our top picks, this list isn’t exhaustive. Be sure to keep abreast of changing standards as Active Directory continues to evolve.