Best practices for Microsoft service accounts

Preamble

Microsoft service accounts are a necessary aspect of any Windows ecosystem because they run essential services and applications, such as web servers, mail transport agents, and databases. However, they are frequently misused and mismanaged, putting the firm in danger of business disruptions, security breaches, and compliance failures. Indeed, one of the top four vulnerabilities we find during security evaluations at Quest is concerns with service accounts.

Today, we’ll go over service accounts and the top ten best practices for properly managing them.

About Microsoft service accounts

In a Windows context, a Microsoft service account is an account that is used to operate one or more services or applications. Service accounts, for example, run Exchange, SharePoint, SQL Server, and Internet Information Services (IIS). The service account establishes the service’s security context, i.e., it decides which local and network resources the service has access to and what it may do with them. Workstations, member servers, and domain controllers can all have service accounts (DCS). 

Microsoft service accounts come in a variety of shapes and sizes, each with its own set of benefits and drawbacks:

• Built-in service account — On a local machine, you can specify which of the three built-in service accounts an application should use: LocalService, NetworkService, or LocalSystem. There are no passwords for these accounts. 
• Traditional Microsoft service account — A traditional Microsoft service account is nothing more than a regular user account. It would be a separate account created and used solely for running a particular service in an ideal world. For convenience, corporate users and administrators frequently use their regular user accounts as service accounts. Unlike the built-in service accounts, these accounts have passwords. On the other hand, managing the passwords of hundreds of thousands of users can soon become complex. The application or service may be affected if the password for a service account is changed. As a result, many companies make their service account passwords never expire or change, which isn’t much better than having no password. You may create traditional service accounts using Active Directory Users and Computers (ADUC). Or, like any other user account, your identity management solution.
• In Windows Server 2008 R2, Microsoft introduced the managed service account (MSA) or, more precisely, the standalone managed service account (MSA). It improves security by eliminating the need for an administrator to control each service account’s credentials manually. An sMSA, on the other hand, creates a problematic password and changes it regularly (by default, every 30 days). An sMSA can’t share among several computers (thus the “standalone” modifier). 
• The group managed service account (gMSA) has replaced the single managed service account (MSA).A gMSA has the same capability as a CSA but can use it to conduct scheduled activities across many servers. Only computers running Windows Server 2012 or later may configure and administer GMSAs, but they can deploy in domains with DCs running previous operating systems. There are no functional requirements at the field or forest levels. Use the PowerShell cmdlet New-ADServiceAccount to create a gMSA. (Be sure to specify the desired password change interval, as you will not be able to modify it later!) The new gMSA will store in the container Managed Service Accounts. Then, using the Install-ADServiceAccount cmdlet, install the gMSA on the host. See Microsoft’s step-by-step instructions for further information. 
• Account for virtual services — Virtual accounts, like SMSAs, was introduced in Windows Server 2008 R2. A virtual bill cannot establish or delete manually; it is created automatically when a service is installed and has the name NT SERVICE\<SERVICENAME>. The credentials of the computer account, in the format <domain_name>\<computer_name> $, will be used by a service that runs as a virtual account to access network resources.

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

1. Learn about your service accounts and how they use.

Getting a thorough and accurate inventory of all those things is the first step in efficiently managing just about anything. It’s crucial in our position to identify all service accounts, understand where and how they use, and maintain track of critical metrics like when they last changed their passwords.

Regrettably, that endeavor is significantly more complicated than it appears at first. You can find Microsoft service accounts on workstations, member servers, and DCs. They can make up several different reports, including regular user accounts. It would help use native tools to reach each computer and determine how the configure programs and services. It is not possible to do so manually. As a result, you should develop a script or use the PowerShell cmdlet Get-ADServiceAccount. You can also automate the scan using a comprehensive enterprise security reporting system.

​​
2. Administrators should not utilize their accounts as service accounts.
​
As I said previously, admins occasionally utilize their user account as a service account. It may appear innocent enough: you need to install and test a new application, and your boss needs your feedback right away, so you don’t bother requesting a separate Microsoft service account. What could go wrong?

Plenty. For starters, it adds another degree of security to the admin account. Suppose a hacker gains access to the service account. In that instance, they acquire access to all of the account’s features, including performing any task that the admin must perform across the site. It also undermines accountability because a log of what the admin’s history has done now includes activity conducted by the application itself. Finally, there’s the question of company continuity: What happens if an administrator’s account deactivates because they update your login or leave the job? All programs and services that rely on that account as the service account stop working unexpectedly.

Never enable admins to use their accounts as service accounts to avoid these problems. Provide instruction on proper practices and audit service account usage regularly for any infractions.

3. Create a Microsoft service account specifically for each service.
​
If you utilize the same service account for multiple applications, you’ll run into similar problems. Let’s begin with safety. LocalSystem and other built-in service accounts use to execute numerous services. Each of these accounts has a separate default set of permissions, but as one application or another needs greater rights, that set of permissions tends to grow over time — and those extra permissions can utilize by all of the services, not just the one that required them.

It’s also much more challenging to hold people accountable and troubleshoot problems.If the login for a cloud infrastructure user changes, for example, each effort by an app to authenticate using the old password will fail; you’ll notice that the applications aren’t working, but determining what’s wrong can be difficult. Furthermore, if a share service account deactivates or its password changes, you’ll lose not just one but several services, further exacerbating the business damage.

Use a tool like Enterprise Reporter to scan all of your machines and provide a report of which accounts are using as a service regularly to enforce this best practice. If many benefits share a Microsoft service account, can appropriately configure each service with its performance.

4. Strictly enforce the principle of least privilege.
​
It’s also crucial to ensure that each service account only has the rights it requires to do the work at hand. While strictly enforcing least privilege is never easy, it’s a lot easier when each service has its own Microsoft service account.

Be careful that while vendors frequently claim that their apps require Domain Admin permissions, this isn’t necessarily the case. This level of access is often necessary only to install the service, not to run it afterward.It allows only each service account’s rights (like you should with any other version). You reduce the damage that could do if the account hack, the application is hijackers, or the application has a severe programming flaw.

5. Only allow interactive logins for service accounts if necessary.
​
Pay special attention to whether the service should be allowed to log in interactively when deciding what rights each service account should have. Individuals that need to interact with the IT environment by producing a document, messaging a teammate, or opening a helpdesk ticket typically use interactive login. On the other hand, service accounts use to operate services in the background without requiring any involvement. Indeed, some experts suggest seeing interactive logins by service accounts as a significant red signal. Put all your Microsoft service accounts into a specific AD security group and use Group Policy to restrict any statement in that group from logging in interactively.

Nevertheless, please remember that some services may necessitate interactive logins. A system administration tool, for example, sends commands to other computers to execute a task. In some cases, you should exclude the associates’ service account from the Group Policy-governed group, but make sure you have adequate monitoring systems to detect account misuse. Here, we go over Group Policy management tactics in further depth.

6. Whenever possible, use MSAs.
​
MSAs have many benefits over standard service accounts, so you should use them whenever available. MSAs, in particular, cannot lock out or perform interactive logons, and their passwords manage automatically by the operating system. Thus, no human ever needs to know or remember the password.

7. If MSAs aren’t an option, make sure to update service account credentials frequently.
​
You’ll have to utilize a regular Microsoft service account if a program doesn’t support MSAs. If that’s the case, make careful to avoid these typical blunders:

• Never leave a service account’s password set to the application vendor’s default. Hackers can discover these passwords on the internet and use them to access your network. 
• Should avoid simple passwords. The phrases “1234” and “password” are simple to use yet exceedingly simple to hack. 
• Don’t make the password indefinitely valid. Passwords for service accounts are routinely maintained unchanged for years, raising the risk of exploitation or breach.

Instead, choose an extremely complicated password for each service account that is changed regularly. Consider using a privileged account management (PAM) system to manage your account credentials; this way, no one will ever know your password, and it may be reset automatically.

8. Make sure you can restore a service account’s password fast.
​

Changing the password for a Microsoft service account is hazardous because if the update fails, the program or service it’s linked to will stop running. A service account can also terminate as part of routine account cleanup or, as earlier indicated, when an administrator leaves the firm and their performance utilizes as a service account.

If this happens, it might easily disrupt critical company procedures, and the clock is ticking. As a result, investing in a complete solution to back up and recover Active Directory is a recommended strategy to ensure that you can promptly restore any mistakenly lost Microsoft service account and granularly fix account information such as passwords.

9. Delegation for service accounts should always be limited.
​

Can set up a Microsoft service account to access resources on behalf of another user without requiring that user check-in. You have such a web server that wants to connect to a SQL Server database. Instead of granting the web server’s service account direct access to the database, you can use Delegation to allow it to request those resources on behalf of a user who logged in with their credentials.

The Delegation, if left unchecked, can lead to a slew of security vulnerabilities, as the account will allow acting on behalf of the user in any service, not only the ones it requires. As a result, it’s critical to set up service accounts with limited Delegation and specify which services the service account can operate on behalf of a user.

To limit Delegation for a Microsoft service account, open Active Directory Users and Computers, View, and enable Advanced Features. When you right-click the service account, choose Delegation from the context menu. Then, in the box below, choose Trust, that user for Delegation to Specific Services Only and the assistance needed. Allowing the Kerberos protocol to be used is also a good choice because it is the most secure.

10. Remove any accounts that are no longer in use.
​

You’ve probably heard the terms “sprawl” and “tenant sprawl” used in various contexts. What’s more, service account sprawl is something you should be concerned about as well. After all, your IT environment is a fast-paced setting where newer and better technologies are constantly replacing software solutions. When they stop functioning, the service accounts associated with services or apps disappear. Those accounts aren’t harmless: they clutter your directory, making it harder to keep track of permissions, and they pose a security concern because they might hack and exploit to access your system.

As a result, it’s critical to regularly monitor your Microsoft service accounts and identify those that aren’t in use. You can plan a report to run on the chosen schedule and check for service accounts that are no longer active with a solution like Enterprise Reporter. If further inquiry indicates that an account is no longer required, you can deactivate or delete it or use it as a honeypot to detect hackers. Use the Remove-ADServiceAccount cmdlet to delete a managed service account.

Final thoughts

Microsoft service accounts are a critical component of any IT infrastructure. It’s vital to manage them effectively because they often have increased permissions. Following the ten best practices outlined here will help you avoid security breaches, business disruptions, and regulatory violations.

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of RDBMS, NoSQL, and machine learning database platforms.