Microsoft service accounts are a critical part of any Windows ecosystem because they are used to run essential services and applications, from web servers to mail transport agents to databases. But all too often, they are not used and managed properly — which leaves the organization at unnecessary risk of business disruptions, security breaches and compliance failures. Indeed, problems with service accounts are one of the top four issues that we at Quest uncover during security assessments.
Today, I’ll explain what service accounts are and the top 10 best practices for handling them effectively.
About Microsoft service accounts
A Microsoft service account is an account used to run one or more services or applications in a Windows environment. For example, Exchange, SharePoint, SQL Server and Internet Information Services (IIS) all run under service accounts. The service account provides the security context for the service — in other words, it determines which local and network resources the service can access and what it can do with those resources. Service accounts can exist on workstations, member servers and domain controllers (DCs).
There are several types of Microsoft service accounts, each with its own advantages and disadvantages:
- Built-in service account — On a local computer, you can configure an application to run under one of the three built-in service accounts: LocalService, NetworkService or LocalSystem. These accounts do not have passwords.
- Traditional service account — A traditional Microsoft service account is just a standard user account. Ideally, it should be an account created and used exclusively to run a particular service, but all too often, business users and admins use their regular user accounts as service accounts in the name of expediency. Unlike the built-in service accounts, these accounts do have passwords. However, managing the passwords of hundreds or thousands of service accounts can get complicated very quickly, and changing a service account’s password introduces the risk of breaking the applications or services it is used to run. Therefore, many organizations set their service account passwords to never expire and never update them, which is not much better than having no password at all.Traditional service accounts can be created like any other user account, such as with Active Directory Users and Computers (ADUC) or your identity management solution.
- Managed service account (MSA) or, more precisely, standalone managed service account (sMSA) — In Windows Server 2008 R2, Microsoft introduced the managed service account, which improves security by eliminating the need for an administrator to manually manage the credentials for each service account. Instead, an sMSA establishes a complex password and changes that password on a regular basis (by default, every 30 days). An sMSA cannot be shared between multiple computers (hence the modifier “standalone”).
- Group managed service account (gMSA) — The sMSA has been superseded by the group managed service account. A gMSA provides the same functionality as an sMSA but can be used across multiple servers and can be used to run scheduled tasks. GMSAs can be configured and administered only on computers running Windows Server 2012 or later, but they can be deployed in domains that still have DCs running earlier operating systems. There are no domain or forest functional level requirements.To create a gMSA, use the PowerShell cmdlet New-ADServiceAccount. (Be sure to set the desired password change interval because you cannot change it later!) The new gMSA will be located in the Managed Service Accounts container. Then install the gMSA on the host using the Install-ADServiceAccount For more details, see Microsoft’s step-by-step guide.
- Virtual service account — Like sMSAs, virtual accounts were introduced in Windows Server 2008 R2. You cannot manually create or delete a virtual account; it is created automatically when a service is installed, with a name in the format NT SERVICE\<SERVICENAME>. A service that runs as a virtual account will access network resources using the credentials of the computer account, in the format <domain_name>\<computer_name>$.
Top 10 best practices for creating, using and managing Microsoft service accounts
1. Know what service accounts you have and what they are being used for.
The first step in effectively managing just about anything is to get a complete and accurate inventory of all those things. In our case, it’s vital to identify all accounts that are being used as service accounts, understand exactly where and how they are being used, and track key metrics such as when their passwords were last changed.
Unfortunately, that task is far more difficult than it might initially seem. As noted earlier, Microsoft service accounts can exist on workstations, member servers and DCs, and there are many different types of accounts that can be used as service accounts, including regular user accounts. With native tools, you have to go out to each of the different machines and figure out how the applications and services on it have been configured. Doing that manually clearly is not a feasible approach. Therefore, you’ll want to automate the scan by writing a script using the Get-ADServiceAccount PowerShell cmdlet or by using a comprehensive enterprise security reporting solution.
Figure 1. Quest Enterprise Reporter displaying a comprehensive view of an organization’s Microsoft service accounts
2. Don’t allow admins to use their personal accounts as service accounts.
I noted earlier that admins sometimes use their own user account as a service account. It might seem innocent enough: You need to install and test a new application, for instance, and your boss wants your evaluation of it today, so you don’t go to the trouble of requesting a separate Microsoft service account. What could go wrong?
Plenty. For one thing, it’s an extra layer of exposure for the admin account. If a hacker compromises the service account, they get all the privileges that account has — which would be not just running one application, but everything else the admin is authorized to do across the domain. It also destroys accountability, since a log of what the admin’s account has done now includes activity that is actually being performed by the application. Finally, there’s business continuity: What happens when the admin updates their password, or leaves the organization and their account is deleted? All applications and services that rely on that account as the service account abruptly stop working.
To avoid these issues, never allow admins to use their personal accounts as service accounts. Provide training on the proper procedures and regularly audit service account usage to spot any violations.
3. For each service, use a Microsoft service account dedicated to that
service.
Similar issues arise if you use the same service account for more than one application. Let’s start with security. Built-in service accounts like LocalSystem are often used to run multiple services. Each of these accounts comes with a different default set of permissions, but over time, that set of permissions tends to get expanded as one application or another needs additional rights — and those extra permissions can be used by all the services, not just the one that needed them.
Accountability and troubleshooting are also far more difficult. For instance, if the password for a shared service account is changed, every attempt by an application to authenticate using the old password will fail; you’ll see that the applications aren’t working, but it can be a challenge to identify the root cause. Moreover, if a shared service account is removed or its password is changed, you’ll have not just one service that’s down, but lots of them, compounding the impact on the business.
To enforce this best practice, regularly use a solution like Enterprise Reporter to scan all your machines and generate a report of what accounts are being used as a service. If multiple services are sharing a Microsoft service account, you can then properly configure each service with a dedicated account.
4. Rigorously enforce least privilege.
It’s also critical to ensure that each service account has only the permissions it needs to do the job it’s tasked with. While rigorously enforcing least privilege isn’t ever simple, it’s a whole lot easier when each service has its own dedicated Microsoft service account.
Be aware that vendors often say that their applications require Domain Admin rights — but that’s not always actually true. Often, this level of privilege is required only to install the service initially, not to run it afterward. By granting each service account only the permissions it actually needs (just as you should with every other account), you limit the damage that you could suffer if the account is compromised, or the application is hijacked or has a serious programming flaw.
5. In particular, don’t allow interactive logins for service accounts unless
it’s truly required.
While you’re assessing what rights each service account should be granted, pay particular attention to whether the service should be able to log in interactively. Interactive login is normally limited to individuals, who need to interact with the IT environment by creating a document, messaging a teammate, creating a helpdesk ticket and so on. Service accounts, on the other hand, normally run services behind the scenes, without any need for that kind of interaction. Indeed, some experts advise treating service accounts performing interactive logins as a blazing red flag. One way to enforce this best practice is to put all your Microsoft service account into a special AD security group and use Group Policy to prevent any account in that group from logging in interactively.
Keep in mind, however, that some services might actually need to perform interactive logins. One example might be a system management tool that goes out to other computers to perform an action. For those specific cases, you would want to exclude the associated service account from the group governed by the Group Policy — but be sure to put other monitoring controls in place so you’ll know if that account is used improperly. We go into more detail about Group Policy management strategies here.
6. Use MSAs whenever possible.
MSAs offer a wealth of advantages over traditional service accounts, so you should use them whenever possible. In particular, MSAs cannot perform interactive logons and cannot be locked out, and their passwords are managed automatically by the operating system, so no human being ever needs to know the password or remember to change it.
7. When you can’t use MSAs, be sure to change service account passwords
regularly.
If an application does not support MSAs, you’ll need to use a traditional Microsoft service account. In that case, be sure to avoid several common mistakes:
- Never leave a service account set to the default password chosen by the application vendor. Hackers can easily find these passwords on the internet and slip into your network.
- Don’t pick simple passwords. Phrases “1234” or “password” are easy to apply — but incredibly easy to hack.
- Don’t set the password to never expire. All too often, organizations leave service account passwords unchanged for years, which dramatically increases the risk of the account being misused or compromised.
Instead, pick a very complex password for each service account and ensure it is changed on an ongoing basis. Consider investing in a privileged account management (PAM) solution that can manage the account credentials for you; that way, no human will ever know what the password is, and it can be automatically changed.
8. Be sure you can quickly recover a service account or its password.
Of course, changing the password for a Microsoft service account comes with risk: If the change is not done properly, the application or service it’s associated with will no longer be able to function. In addition, a service account itself might be deleted — for example, it might get swept away during routine account cleanup or, as mentioned above, as part of normal de-provisioning when an admin leaves the organization but their account was being used (improperly!) as a service account.
If that happens, critical business processes could easily be disrupted, and the clock is ticking. Therefore, it’s a best practice to ensure that you can promptly restore any Microsoft service account that is deleted by mistake, as well as granularly restore account properties such as passwords, by investing in a comprehensive solution to back up and recover Active Directory.
9. Always constrain delegation for service accounts.
A Microsoft service account can be configured so that it is permitted to access resources on behalf of a user, without the need to sign in as that other user. For example, suppose you have a web server that needs to access data in a SQL Server database, You probably don’t want to grant the service account that runs the web server permissions to access the database directly; using delegation, you can enable it to request those resources on behalf of a user who logged in using their own credentials.
Of course, if delegation is left unchecked, it opens the door to a lot of security issues, since the account will be able to act on behalf of the user in any service, not just the ones it needs. Therefore, it’s important to configure service accounts with constrained delegation, and specifically enumerate the services for which the service account can act on behalf of a user.
To constrain delegation for a Microsoft service account, open Active Directory Users and Computers, navigate to View and enable Advanced Features. Right-click the service account, and select Delegation. Then choose Trust this user for delegation to specified services only and select the appropriate services in the box below. It’s also wise to allow the use of the Kerberos protocol only, since it is the most secure authentication protocol. (Note that to use Kerberos authentication, a service account must have a Service Principal Name (SPN) that is registered with Active Directory.)
Reduce your AD attack surface.
Figure 2. Be sure to constrain delegation for all of your Microsoft service accounts.
10. Clean up accounts that are no longer needed.
You’ve undoubtedly heard about sprawl in a lot of context, including group sprawl and tenant sprawl. Guess what — service account sprawl is also something you need to be concerned about. After all, your IT environment is a highly dynamic place, with software solutions being replaced by newer and better technologies all the time. But when services or applications are decommissioned, the associated service accounts are often not cleaned up. Those accounts aren’t harmless: They clutter up your directory and make it harder for you to stay on top of permissions, and they are a security issue because they could be taken over by a hacker and used to gain a foothold in your environment (especially if you weren’t rigorous about enforcing least privilege).
Therefore, it’s important to regularly review your Microsoft service accounts and identify ones that are not being used. A solution like Enterprise Reporter makes the job easy; you can simply schedule a report to run on the desired schedule and check for service accounts that are no longer active. If further investigation reveals that a particular account is indeed no longer needed, you can deactivate or delete it, or you can use it as a honeypot to trap hackers. To remove a managed service account, use the Remove-ADServiceAccount cmdlet.
Final thoughts
Microsoft service accounts are an essential part of your IT ecosystem. Because they typically have elevated permissions, it’s critical to manage them properly. Following the 10 best practices here will help you avoid security incidents, business disruptions and compliance failures.
