Get a grasp on using group managed service accounts
When you create a group managed service account, it relieves some administrative duties and bolsters the security related to passwords for services in a Windows environment.
Service accounts have long been used in the enterprise as a tool to grant required permissions to applications or to services. However, these service accounts can also pose several challenges.
It's easy to accidentally grant excessive permissions to a service account. Password use can also be problematic. If you configure service account passwords to periodically expire, then applications that depend on a functioning service account can grind to a halt when the expiration date hits. You have to assign a new password to the service account and then update the application to use that password. For the sake of convenience, an organization might avoid an expiration policy with service account passwords, but that also poses security challenges.
Microsoft introduced managed service accounts -- also called standalone managed service accounts -- in in Windows Server 2008 R2 and then group managed service accounts in Windows Server 2012 to address the administrative challenges and potential security risks posed by traditional service accounts.
Uncover the advantages of the managed service account types
One of the benefits to use either type of managed service account is automated password management. Once you set it up, Windows Server provisions the account with a secure password and automatically changes the password on a periodic basis.
If this sounds strange, then consider the way the Active Directory handles other accounts. User and computer accounts have passwords. The user creates and maintains their password, while Windows automatically creates and maintains the password for a computer account.
The screenshot shows a group policy setting named Domain member: Maximum machine password age that controls how frequently Windows changes the passwords for computer accounts. This Group Policy setting is undefined by default, and passwords will change every 30 days. You can adjust the value to meet your needs.
How managed service accounts differ from computer accounts
Managed service accounts work in a similar manner to Active Directory computer accounts with regard to passwords. However, there are some key differences.
A standalone managed service account handles passwords in a similar way to how Active Directory handles computer accounts. Microsoft refers to these accounts as standalone managed service accounts because they only work on a specific server. They provide credentials to one or more services on that designated server. A standalone managed service account can support multiple services, but best practices stipulate it is best to create a separate service account for each service.
A group managed service account is comparable to a standalone managed service account with the difference being it works across multiple servers. However, this does not mean you should use a single group managed service account across all servers within an entire organization. Microsoft defines some very specific use cases for group managed service accounts.
All of this raises two very important questions: What are the benefits of a managed service account rather than a user account configured as a service account and how do you know which type of managed service account to use?
Understand the managed service account requirements
In addition to the automatic password change every 30 days, a managed service account frees you from creating strong passwords. A managed service account gets a randomly generated password that is 240 bytes long. Perhaps, more importantly, Windows never exposes the password to the IT staff.
Also, as long as the Active Directory domain functional level is set to Windows Server 2008 R2 or higher, the account will automatically adapt to service principal name changes. If you rename the server or change the server's DNS name, the managed service account will adapt accordingly.
There are three main things to consider when you decide on the type of service account. These include your Windows Server operating system version, how you plan to use the service account and what types of service accounts your service or application will support. Application support is an especially important consideration, because not every application will work with a managed service account.
Similarly, you must consider the types of managed service accounts the server operating system supports. Standalone managed service accounts were introduced in Windows Server 2008 R2 and require the Active Directory on Windows Server 2008 R2 or higher schema level. If you want the account to automatically recognize service principal name changes, the Active Directory functional level must be set to Windows Server 2008 R2 or higher.
Microsoft introduced group managed service accounts in Windows Server 2012. To use this feature, the Active Directory schema needs to be set to Windows Server 2012 or higher. The domain can run a mix of Windows Server 2012 and older domain controllers if necessary.
What are some group managed service account limitations?
A standalone managed service account is for running services on an individual server. Group managed service accounts work across multiple servers, but only if those systems belong to a common server farm or are behind a load balancer. Other use cases are not supported.
For example, you cannot use a group managed service account to support the nodes in a failover cluster, but it can work on top of a cluster, particularly if the service account supports a Windows service, an application pool or a scheduled task. Some applications also natively support group managed service accounts.
