Ten security best practices for Active Directory service accounts

Microsoft Active Directory is arguably one of the most attacked resources that you can run on-premises. The reason for this is that it stores the “keys to the kingdom.” Everything identity related on-premises and even in hybrid-joined cloud environments comes from Active Directory. There are certain types of account in particular that attracts the attention of hackers.  

There are a 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 accounts have deeper access to OS infrastructure and handle the installation of applications and core services, making them higher-priority attack targets.   

A couple of things become critical: that accounts are secure, and functional scopes are well defined. How do we do this? We’ll break down the three types of Active Directory service accounts, and dive into ten best practices to follow.  

What are service accounts?

Active Directory service accounts are specialized accounts that unlike normal user accounts are not meant to be used to log in to servers or clients. Instead, these are used to run services on Windows Servers and used for special functions related to applications. 

In Active Directory, permissions are tied to user and computer accounts. So, the service account plays the special role of fulfilling the need to have an object that has permissions tied to it so that applications can authenticate to the Active Directory domain. 

Since they often need high-level permissions for applications to run, these are often heavily targeted by attackers who know if they can compromise a service account, they will likely have an account with very broad permissions across the board. 

The service account types 

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 Active Directory 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 Active Directory 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.   
4. Group Managed Service Accounts (gMSAs): These are similar types of objects to the MSAs, but these are designed to be used more at scale, on multiple servers or services. This makes sure you have a more scalable solution that is also secure. 

Managed service accounts are typically the most secure of the bunch. They benefit from the strict permissions controls possible through Active Directory, effectively enforcing role-based access control (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.   

Since service accounts are usually high-level accounts with a wide variety of permissions, these are a type of account that must be protected at all costs. Let’s consider some best practices that help to protect the Active Directory service accounts and tips for securing these high-target objects. 

Ten best practices for securing Active Directory 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.  

1. Grant privileges sparingly 

One of the first things to think about with service accounts is applying the principle of least privilege. Like any other user account, service accounts should only have the minimum amount of permissions that are absolutely necessary to perform the task they need to perform. If admins apply very high-level privileges and permissions to service accounts, like making these a domain administrator or enterprise admin, it can be very dangerous. If an attacker compromises a service account, they now have everything they need to “own” the domain and set up persistence across the board. 

Instead of applying potentially risky group permissions to service accounts, like domain admins, apply only very granular permissions to the required service account. This method will limit the damage if the service account were to become compromised. 

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, Active Directory 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.  

2. Use Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) 

The specialized service accounts, including managed service accounts (MSAs) and group managed service accounts (gMSAs) are much better to use than traditional user accounts. These provide added security benefits. With MSAs and gMSAs, you will have the ability to have automatic password changes and have these rotated automatically so you don’t have to take care of the changes manually. 

These are from the start better suited from a security perspective since they cannot be used for interactive logins or other non-service related purposes. 

3. Perform regular audits 

Service accounts are one of the most important objects in Active Directory to monitor since they are one of the most targeted types of accounts by an attacker. Monitoring service accounts and their use can help detect suspicious behavior, like the service account being used for RDP access or being invoked on servers it shouldn’t be used on or even from a workstation. 

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.   

Active Directory has built-in auditing that can track logon events, account changes, and other types of activities. However, these are not very user-friendly to use without some type of third-party tool that helps aggregate these audit events and provide insight into what you are seeing. Third-party tools can be configured to provide alerting on suspicious behaviors or audit events that may indicate someone is trying to compromise the environment. 

Looking for a more advanced third-party auditing tool? Specops Password Auditor is read-only and doesn’t store Active Directory data, nor does it make any changes to Active Directory. You’ll get an easy-to-understand exportable report detailing password-related vulnerabilities that could be used as entry points for attackers. Download for free here.   

4. Implement strong password policies 

The password is arguably the single most important aspect of an account’s security posture. Enforcing strong password policies is extremely important to make sure service accounts have passwords that are difficult to compromise. The MSAs and gMSAs take care of password management for you. However, strong password policies across the board, including user accounts helps to improve the overall security of your Active Directory Domain Services (AD DS) environment. 

Consider using password policies that enforce the following: 

• Long and complex passwords with at least 16 characters with a mix of letters, numbers, and special characters – passphrases are also a great way to provide memorable passwords that are still strong 

• Regularly rotate passwords and avoiding hard-coded or reused passwords 

• Using password manager solutions to store and manage service account credentials that are manually managed 

Below is a typical password policy that only requires 7 characters. These types of policies will allow users to create relatively weak passwords. Learn how Specops Password Policy can help enforce strong password policies across your organization. 

5. Restrict service account use and control vendor access

Service accounts should never be used for interactive logins. These are special-purpose and should only be used for services that are needed for applications. Don’t use the same service account for multiple services. Creating unique service accounts for each service makes these unique and limits the attack surface.  

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.  

6. Disable unused service accounts 

Housekeeping in terms of lifecycle management with Active Directory service accounts is extremely important. If service accounts are no longer used or needed in the environment, these should be disabled. Leaving service accounts active that are no longer needed quickly becomes a major security liability since these often have high-level access that could be exploited by attackers. Sysadmins should routinely check for and clean up stale or unused accounts. 

Querying accounts with PowerShell to find accounts that have not been used to logon in “X” number of days is a good way to find inactive or stale service accounts, in addition to normal stale accounts. Or if you want a detailed report on stale and unused accounts (as well as many other password and account related vulnerabilities) you can a read-only scan of your Active Directory with our free auditing tool: Specops Password Auditor.  

7. Separate service account roles 

Separating service account roles is a great way to separate out the roles and permissions between the different service account objects. Have service accounts that are used for application services only. Then create separate accounts for network, database, and other types of services, each with individual unique accounts. This methodology helps to reduce the risk of any single account being compromised and limits the resources associated. 

8. Use Multi-Factor Authentication (MFA) where possible 

One of the best ways to strengthen authentication security is by adding multi-factor authentication to the interactive login process. Granted, service accounts should not be used for interactive logins. However, there may be edge cases where a specific service account needs to be used for login. In this case, always make sure the account has multi-factor authentication enabled. 

Also, implementing MFA across the board for all user accounts is a great way to improve the security posture of your Active Directory environment. If the security of all users is increased, the likelihood of service account compromise goes down dramatically. 

9. Use dedicated organizational units (OUs) for service accounts 

Staying organized when it comes to service accounts is a great way to help with management and security. Creating a dedicated Organizational Unit (OU) in Active Directory for service accounts helps to make sure that you can consistently manage and apply Group Policies to all service accounts in the environment. It also helps to simplify monitoring service accounts when they are located in the same OU. 

10. Regularly review service account dependencies and access 

While the level of access for a service account might be appropriate today, these needs and access levels may change in the future. Be sure to regularly review service account dependencies and access to make sure these levels are still needed and appropriate. 

Also identify which applications, services, or scripts may need the service account and make sure these accounts are configured and secured as needed. These steps help prevent unauthorized access and reduce the risk of too many permissions or unneeded permissions. 

Keep service accounts secure 

Service accounts in Active Directory are some of the most dangerous accounts if not properly secured: Admins need to make sure these accounts are managed and secured properly. A proper security regimen for service accounts includes reviewing permissions often, auditing access and monitoring their use, implementing strong password policies, MFA, and using the special MSA and gMSA accounts for service accounts where possible. Always apply the principle of least privilege with your service accounts and use dedicated OUs and Group Policies for management and security. 

Also consider having a tool like Specops Password Policy in place that can simplify the management of fine-grained password policies in Active Directory. Continuously block over 4 billion unique compromised passwords, easily enforce compliance, and lower your support burden by giving end users a better security experience. Interested to know how Specops Password Policy could fit in with your organization? Get in touch and try it for free. 

ectory continues to evolve.