you need to create a managed service account. what should you do

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 service ship agents to databases. But all too oftentimes, they are not used and managed properly — which leaves the arrangement at unnecessary risk of business disruptions, security breaches and compliance failures. Indeed, problems with service accounts are one of the superlative four issues that nosotros at Quest uncover during security assessments.

Today, I'll explain what service accounts are and the top 10 best practices for handling them effectively.

Virtually Microsoft service accounts

A Microsoft service account is an account used to run i or more services or applications in a Windows environment. For instance, Exchange, SharePoint, SQL Server and Cyberspace Information Services (IIS) all run under service accounts. The service business relationship provides the security context for the service — in other words, it determines which local and network resources the service can access and what it tin can do with those resources. Service accounts tin 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:

• Congenital-in service account — On a local computer, you can configure an application to run nether one of the three built-in service accounts: LocalService, NetworkService or LocalSystem. These accounts do non have passwords.
• Traditional service account — A traditional Microsoft service account is just a standard user account. Ideally, it should exist an account created and used exclusively to run a particular service, merely all too often, business concern users and admins utilise their regular user accounts as service accounts in the proper name of expediency. Unlike the built-in service accounts, these accounts do take passwords. Yet, managing the passwords of hundreds or thousands of service accounts tin can get complicated very quickly, and irresolute a service account's password introduces the run a 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 improve than having no password at all.Traditional service accounts tin be created similar whatsoever other user business relationship, such every bit with Active Directory Users and Computers (ADUC) or your identity management solution.

• Managed service business relationship (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 demand for an ambassador to manually manage the credentials for each service account. Instead, an sMSA establishes a circuitous password and changes that countersign on a regular basis (by default, every xxx days). An sMSA cannot be shared between multiple computers (hence the modifier "standalone").
• Group managed service business relationship (gMSA) —The sMSA has been superseded by the group managed service account. A gMSA provides the same functionality every bit an sMSA but can be used across multiple servers and tin exist used to run scheduled tasks. GMSAs can be configured and administered merely on computers running Windows Server 2012 or subsequently, but they tin 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, utilise the PowerShell cmdlet New-ADServiceAccount. (Be sure to prepare the desired password change interval because you cannot change information technology after!) The new gMSA will exist located in the Managed Service Accounts container. Then install the gMSA on the host using theInstall-ADServiceAccount For more than details, come across Microsoft'southward step-by-stride guide.
• Virtual service account —Like sMSAs, virtual accounts were introduced in Windows Server 2008 R2. Yous cannot manually create or delete a virtual account; information technology is created automatically when a service is installed, with a name in the formatNT 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 all-time practices for creating, using and managing Microsoft service accounts

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

The first step in effectively managing just well-nigh anything is to get a complete and accurate inventory of all those things. In our case, it'south vital to identify all accounts that are being used as service accounts, understand exactly where and how they are being used, and runway fundamental metrics such as when their passwords were last changed.

Unfortunately, that task is far more than difficult than it might initially seem. As noted earlier, Microsoft service accounts can be on workstations, fellow 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 become out to each of the different machines and figure out how the applications and services on it take been configured. Doing that manually conspicuously is non a feasible approach. Therefore, you lot'll want to automate the scan by writing a script using the Get-ADServiceAccountPowerShell cmdlet or by using a comprehensive enterprise security reporting solution.

Effigy 1 . Quest Enterprise Reporter displaying a comprehensive view of an organization'due southMicrosoft 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 business relationship 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, then you lot don't become to the trouble of requesting a dissever Microsoft service account. What could go wrong?

Enough. For 1 thing, it'south an extra layer of exposure for the admin account. If a hacker compromises the service account, they go all the privileges that account has — which would be non just running i awarding, simply everything else the admin is authorized to do across the domain. Information technology too destroys accountability, since a log of what the admin's business relationship has done now includes activity that is actually being performed past the awarding. Finally, there's business organization continuity: What happens when the admin updates their password, or leaves the organization and their business relationship is deleted? All applications and services that rely on that business relationship as the service account abruptly stop working.

To avert 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 whatsoever violations.

3.     For each service, use a Microsoft service account defended to that
service.

Similar problems arise if y'all utilise the aforementioned service account for more than ane application. Permit's beginning with security. Built-in service accounts like LocalSystem are ofttimes used to run multiple services. Each of these accounts comes with a dissimilar default set of permissions, only over fourth dimension, that gear up of permissions tends to go expanded as i application or another needs additional rights — and those extra permissions tin can be used by all the services, not only the ane that needed them.

Accountability and troubleshooting are too far more difficult. For instance, if the countersign for a shared service business relationship is changed, every attempt by an application to cosign using the old countersign will fail; you'll see that the applications aren't working, merely information technology can be a challenge to identify the root cause. Moreover, if a shared service business relationship is removed or its password is changed, you'll have not just one service that'south down, but lots of them, compounding the touch on on the business organisation.

To enforce this all-time practice, regularly utilise a solution like Enterprise Reporter to scan all your machines and generate a written report of what accounts are being used equally a service. If multiple services are sharing a Microsoft service account, you lot tin can and so properly configure each service with a dedicated account.

four.     Rigorously enforce least privilege.

It'south also disquisitional to ensure that each service business relationship has only the permissions it needs to practise the chore information technology'southward tasked with. While rigorously enforcing to the lowest degree privilege isn't ever simple, information technology's a whole lot easier when each service has its own dedicated Microsoft service business relationship.

Be aware that vendors oftentimes say that their applications crave Domain Admin rights — only that's not always actually truthful. Often, this level of privilege is required simply to install the service initially, not to run it after. Past granting each service account only the permissions it actually needs (only as you should with every other account), you limit the damage that yous could endure if the business relationship is compromised, or the application is hijacked or has a serious programming flaw.

5.     In item, don't let interactive logins for service accounts unless
it's truly required.

While y'all're assessing what rights each service account should be granted, pay particular attention to whether the service should exist able to log in interactively. Interactive login is normally limited to individuals, who need to collaborate with the IT environment by creating a document, messaging a teammate, creating a helpdesk ticket and so on. Service accounts, on the other hand, usually run services behind the scenes, without whatever need for that kind of interaction. Indeed, some experts advise treating service accounts performing interactive logins as a blazing red flag. One mode to enforce this best practice is to put all your Microsoft service account into a special AD security grouping and use Group Policy to prevent any account in that group from logging in interactively.

Proceed in mind, however, that some services might actually demand to perform interactive logins. Ane example might be a arrangement management tool that goes out to other computers to perform an activity. For those specific cases, you would want to exclude the associated service account from the grouping governed past the Grouping Policy — just be sure to put other monitoring controls in place so you'll know if that account is used improperly. We go into more than detail virtually Group Policy direction strategies hither.

6.     Employ MSAs whenever possible.

MSAs offering 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 past the operating arrangement, so no human being ever needs to know the countersign or remember to change it.

7.     When you can't apply MSAs, be sure to change service account passwords
regularly.

If an application does non support MSAs, you'll demand to use a traditional Microsoft service account. In that case, be sure to avoid several common mistakes:

• Never leave a service account gear up to the default password chosen by the application vendor. Hackers tin can hands find these passwords on the internet and slip into your network.
• Don't pick elementary passwords. Phrases "1234" or "countersign" are easy to apply — but incredibly easy to hack.
• Don't set the password to never elapse. All too frequently, organizations leave service account passwords unchanged for years, which dramatically increases the take chances of the account being misused or compromised.

Instead, choice a very complex password for each service account and ensure it is changed on an ongoing footing. Consider investing in a privileged account management (PAM) solution that can manage the account credentials for you lot; that way, no human will ever know what the countersign is, and information technology can be automatically inverse.

eight.     Be sure you tin quickly recover a service account or its password.

Of course, irresolute the password for a Microsoft service business relationship comes with risk: If the modify is non washed properly, the application or service it's associated with volition no longer be able to function. In add-on, a service account itself might be deleted — for example, it might go swept away during routine account cleanup or, equally mentioned above, equally office of normal de-provisioning when an admin leaves the organization but their business relationship was being used (improperly!) as a service account.

If that happens, disquisitional business processes could easily be disrupted, and the clock is ticking. Therefore, information technology'southward a all-time practice to ensure that you can promptly restore whatever Microsoft service account that is deleted past mistake, as well as granularly restore account properties such as passwords, by investing in a comprehensive solution to back up and recover Agile 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 demand to sign in as that other user. For example, suppose you have a web server that needs to admission information in a SQL Server database, You probably don't want to grant the service account that runs the spider web server permissions to access the database straight; using delegation, you can enable it to asking 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 volition be able to deed on behalf of the user in whatever service, not merely the ones it needs. Therefore, it's of import to configure service accounts with constrained delegation, and specifically enumerate the services for which the service business relationship tin can act on behalf of a user.

To constrain delegation for a Microsoft service account, open Active Directory Users and Computers, navigate toView and enableAvant-garde Features. Correct-click the service account, and selectDelegation. And then chooseTrust this user for delegation to specified services only and select the appropriate services in the box below. It's besides wise to allow apply of the Kerberos protocol merely, since it is the most secure hallmark protocol. (Note that to use Kerberos authentication, a service account must accept a Service Principal Name (SPN) that is registered with Active Directory.)

Figure two . Be sure to constrain delegation for all of yourMicrosoft service accounts.

ten. Clean up accounts that are no longer needed.

You've undoubtedly heard virtually sprawl in a lot of context, including grouping sprawl and tenant sprawl. Estimate what — service account sprawl is also something you need to be concerned about. After all, your Information technology environment is a highly dynamic identify, with software solutions being replaced by newer and better technologies all the fourth dimension. But when services or applications are decommissioned, the associated service accounts are often non cleaned up. Those accounts aren't harmless: They clutter up your directory and make it harder for you lot to stay on height of permissions, and they are a security result because they could be taken over by a hacker and used to gain a foothold in your environs (specially if you weren't rigorous about enforcing least privilege).

Therefore, information technology's important to regularly review your Microsoft service accounts and place ones that are not being used. A solution like Enterprise Reporter makes the task easy; you can simply schedule a written 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 tin deactivate or delete it, or you lot can use it as a honeypot to trap hackers. To remove a managed service account, employ the Remove-ADServiceAccount cmdlet.

Final thoughts

Microsoft service accounts are an essential role of your IT ecosystem. Because they typically have elevated permissions, information technology'due south critical to manage them properly. Post-obit the ten best practices here will help you avoid security incidents, business disruptions and compliance failures.

reesesawley.blogspot.com

Source: https://blog.quest.com/10-microsoft-service-account-best-practices/

Share this post