Microsoft service accounts are an important part of any Windows ecosystem because they are used to run core services and applications, from web servers to mail transport agents and databases. But too often, they are not used or managed properly, exposing the organization to unnecessary risk of operational disruptions, breaches of security protocols, and non-compliance with regulatory requirements. Indeed, service account issues are one of the top four issues that are primarily identified during IT security analysis.

Today we will talk about the 10 best ways to effectively manage your accounts.

Microsoft Service Accounts - What are they? 

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) run under service accounts. A service account provides security context for a service—in other words, it determines what 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 their own advantages and disadvantages:

• Built-in service account. On your local computer, you can configure the application to run under one of three built-in service accounts: LocalService, NetworkService, or LocalSystem. These accounts do not have passwords.
• Traditional service account. A traditional Microsoft service account is simply a standard user account. Ideally, this should be an account created and used solely to run a specific service, but too often business users and administrators use their regular user accounts as service accounts in the name of expediency. Unlike built-in service accounts, these accounts have passwords. However, managing passwords for hundreds or thousands of service accounts can quickly become complex, and changing a service account's password creates the risk of compromise to the applications or services it is used for. So many organizations set their work account passwords to never expire and never update them, which is little better than not having a password at all. Traditional service accounts can be created just like any other user accounts, such as in 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 credentials for each service. Account. Instead, sMSA sets a complex password and changes that password regularly (every 30 days by default). sMSA cannot be shared between multiple computers (hence the "standalone" modifier).
• Group Managed Service Account (gMSA) - sMSA has been replaced by Group Managed Service Account. gMSA provides the same functionality as sMSA, but can be used across multiple servers and can be used to run scheduled tasks. GMSAs can only be configured and administered on computers running Windows Server 2012 or later, but they can be deployed in domains that still have domain controllers running earlier operating systems. There are no domain or forest functional level requirements. To create a gMSA, use the New-ADServiceAccount PowerShell cmdlet. (Be sure to set your desired password change interval because you won't be able to change it later!) The new gMSA will be located in the Managed Service Accounts container. Then install gMSA on the host using Install-ADServiceAccount. For more information, see the Microsoft walkthrough.
• Virtual service account. Like sMSA, virtual accounts were introduced in Windows Server 2008 R2. You cannot manually create or delete a virtual account; it is created automatically when installing a service with a name in the format NT SERVICE\ . The service running under the virtual account will access network resources using the computer account credentials in the format <domain name>\<computer name>$.

10 best practices for creating, using, and managing Microsoft service accounts

1. Know what service accounts you have and what they are used for.

The first step to effectively managing anything is to take a complete and accurate inventory of it all. In our case, it is critical to identify all accounts that are used as service accounts, understand exactly where and how they are used, and track key metrics such as when their passwords were last changed.

Unfortunately, this task is much more difficult than it might seem at first glance. As noted earlier, Microsoft service accounts can exist on workstations, member servers, and domain controllers, and there are many different types of accounts that can be used as service accounts, including standard user accounts. With native tools, you need to go out to each of the different machines and figure out how the applications and services are configured on it. Obviously, doing this manually is impractical. Therefore, you need to automate the scan by writing a script using the Get-ADServiceAccount PowerShell cmdlet or using a comprehensive enterprise security reporting solution.

2. Do not allow administrators to use their personal accounts as service accounts.

Administrators sometimes use their user account as a service account. This may seem quite convenient. What could go wrong?

Lots of aspects. First, this is an additional level of exposure for the administrator account. If a hacker compromises a service account, they will gain all the privileges that account has, meaning not just running a single application, but everything else an administrator can do on the domain. This also breaks accountability because the log of what the administrator account did now includes actions that are actually performed by the application. Finally, business continuity: what happens when an administrator updates their password or leaves the organization and their account is deleted? All applications and services that use this account as a service account suddenly stop working.

To avoid these problems, never allow administrators to use their personal accounts as service accounts. Provide training on proper procedures and regularly review service account usage to identify any irregularities.

3. For each service, use the Microsoft service account assigned to that service.

Similar problems occur if you use the same service account for multiple applications. Let's start with security. Built-in service accounts such as LocalSystem are often used to run multiple services. Each of these accounts has its own default set of permissions, but over time that set of permissions tends to expand as a particular application requires additional rights, and these additional permissions can be used by all services, not just one.

Liability and troubleshooting also become much more complex. For example, if the password for a shared service account is changed, every attempt by the application to authenticate using the old password will fail; you'll see apps not working, but identifying the root cause can be difficult. Moreover, if a shared service account is deleted or its password is changed, you will have more than one service disabled, exacerbating the business impact.

To ensure you're following this best practice, regularly use a solution like Enterprise Reporter to scan all your computers and generate a report on which accounts are being used as a service. If multiple services share a Microsoft service account, you can configure each service correctly with a dedicated account.

4. Strictly enforce minimum privileges.

It is also important to ensure that each service account has only the permissions it needs to perform its intended task. While strict enforcement of least privilege is never easy, things are much simpler when each service has its own dedicated Microsoft service account.

Keep in mind that vendors often say that their applications require domain administrator rights, but in reality this is not always the case. Often this level of privilege is required only for the initial installation of the service, and not for subsequent startup. By granting each service account only the permissions it actually needs (the same as any other account), you limit the damage you can suffer if the account is compromised, the application is hacked, or has a serious software bug.

5. Evaluate the need for interactive login for service accounts

Pay particular attention to whether the service should be able to log on interactively. Interactive login is typically limited to individuals who need to interact with the IT environment by creating a document, messaging a teammate, creating a support ticket, etc. Service accounts, on the other hand, typically run services behind the scenes , without the need for such interaction. In fact, some experts advise treating service accounts that perform interactive logins as a red flag. One way to implement this best practice is to place all Microsoft service accounts in a special AD security group and use Group Policy to prevent any account in that group from logging on interactively.

However, be aware that some services may require interactive sign-in. One example would be a system management tool that contacts other computers to perform an action. In these specific cases, you would want to exclude the associated service account from the group governed by Group Policy, but be sure to set other monitoring controls so that you know if the account is being used inappropriately. 

6. Use MSA whenever possible.

MSAs offer many benefits over traditional service accounts, so you should use them whenever possible. In particular, MSAs cannot perform interactive logins and cannot be locked out, and their passwords are automatically managed by the operating system, so no one ever needs to know the password or remember to change it.

7. If you cannot use MSA, be sure to change your service account passwords regularly.

If the application does not support MSA, you will need to use a regular Microsoft service account. In this case, be sure to avoid a few common mistakes:

• Never leave a service account with the default password chosen by the application vendor. Hackers can easily find these passwords online and infiltrate your network.
• Don't choose simple passwords. The phrases “1234” or “password” are easy to type, but incredibly easy to crack.
• Do not set a password that never expires. Too often, organizations leave service account passwords unchanged for years, significantly increasing the risk of account misuse or compromise.

Instead, choose a very strong password for each service account and make sure it changes constantly. Consider investing in a privileged account management (PAM) solution that can manage credentials for you; this way, no person will ever know what the password is and it can be changed automatically.

8. Make sure you can quickly recover your service account or password.

Of course, changing the password for a Microsoft service account comes with a risk: if the change is not done properly, the application or service it is associated with will no longer be able to function. In addition, the service account itself may be deleted—for example, it may be deleted during a routine account cleanup or, as mentioned above, as part of a routine deprovisioning when an administrator leaves the organization but the account is used as a service account.

If this happens, critical business processes can easily be disrupted and the clock is ticking. Therefore, it is recommended to ensure that you can quickly recover any Microsoft service account that has been deleted by mistake, as well as selectively restore account properties such as passwords, by investing in a comprehensive Active Directory backup and recovery solution.

9. Always limit delegation of service accounts.

A Microsoft service account can be configured to allow access to resources on behalf of a user without having to sign in as that other user. For example, let's say 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 directly access the database; Using delegation, you can enable it to request these resources on behalf of a user who is logged in using their own credentials.

Of course, if delegation is not checked, it opens the door to many security problems, since the account will be able to act on behalf of the user in any service, not just those that he needs. Therefore, it is important to configure service accounts with limited delegation and specifically list the services for which the service account can act on behalf of the user.

To limit Microsoft service account delegation, open Active Directory Users and Computers, go to View, and turn on Advanced Features. Right-click the service account and select Delegation. Then select "Trust this user to delegate only to specified services" and select the appropriate services in the box below. It is also wise to allow only the Kerberos protocol, as it is the most secure authentication protocol. (Note that to use Kerberos authentication, the service account must have a Service Principal Name (SPN) registered in Active Directory.)

10. Clear accounts that are no longer needed.

The proliferation of service accounts is also something you need to worry about. After all, your IT environment is a very dynamic place where software solutions are constantly being replaced by new and better technologies. But when services or applications are decommissioned, the associated service accounts are often not cleaned up. These accounts are not harmless: they clutter your directory and make it difficult for you to stay on top of permissions, and they are a security issue since a hacker could hijack them and use them to gain a foothold in your environment (especially if you haven't been strict about ensuring least privilege) .

Therefore, it is important to regularly check your Microsoft service accounts and identify those that are not in use. A solution like Enterprise Reporter makes things easier; you can simply schedule the report to run on your desired schedule and check for service accounts that are no longer active. If further investigation reveals that a particular account is truly no longer needed, you can deactivate or delete it, or use it as a trap for hackers. To remove a managed service account, use the Remove-ADServiceAccount cmdlet.

Still have questions?

Microsoft service accounts are an integral part of your IT ecosystem. Since they usually have elevated permissions, it is very important to manage them properly. Following these guidelines will help you avoid security incidents, operational disruptions, and regulatory compliance issues.

We at Fanetech will be happy to answer any questions. Just contact us.