Creating and Associating A Group Managed Service Account
Managed Service Accounts are Active Directory accounts that are assigned to certain computers. The passwords on these accounts are long and complex and are maintained automatically. This means that the passwords are generated on their own every 30 days. Having long, complex, and self generated passwords makes the accounts more secure. Group Managed Service Account (gMSA) was first introduced in Windows Server 2012 and takes the same functionality as Managed Service Accounts and extends its functionality into multiple servers. The service accounts can be used for scheduled tasks, Internet Information Services (IIS) application pools, SQL 2012, and Microsoft Exchange. The Group Managed Service Account can configure multiple servers using the same managed service account. Because gMSA can be used with multiple machines, it allows you the flexibility to be able to implement Network Load Balancing (NLB). NLB allows you to group together servers and operate as one single system. This is helpful when you have a service or server that is used frequently by users and you need room to grow for scalability.
Before you can implement gMSA, you need to have at least one domain controller running Windows Server 2012 so it can store managed password information. The client computers that are going to use these accounts must be Windows 8 or newer, and server-based computers must have Windows Server 2012 or newer. One very important thing you need to do before creating a gMSA is create a KDS root key on the domain controller in the domain. It is important to create the KDA root key because Windows Server 2012 domain controllers require a root key to start generating gMSA passwords. This can be done with the following command run in Active Directory Module for Windows PowerShell (“Add-KdsRootKey”).
Step 1: Open ADM for PowerShell
The first thing that we’ll do is open the Active Directory Module for Windows PowerShell, which can be found in Server Manager under the Tools tab.
Once it opens up, type in the following command Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)), and then press Enter. It should now populate a Guid.
Step 2: Create A Service Account
Next, we are going to create the service account named Webservice for the host machine. This will be done through PowerShell using the New-ADServiceAccount cmdlet.
Step 3: Add Host Machine
Once the service account is created, let’s associate it with my host machine, which is called LON-DC1. This will be done through PowerShell using Add-ADComputerServiceAccount cmdlet.
Step 4: Confirm
Next, let’s double check to make sure the account was created successfully by using the cmdlet Get-ADServiceAccount -Filter * .
Once you see the prompt above, you know that the account has been created successfully. So the service account has been created on the host machine, and now we are going to install a Group Managed Service Account using PowerShell.
Step 5: Install gMSA
Run the cmdlet “Install-ADServiceAccount -Identity Webservice” in PowerShell.
Step 6: Connecting gMSA With A Service
Now that I have created a service account and installed group managed service account, we are ready to associate it with a service. In this case, I am going to have it manage a Web-Based program from the DefaultAppPool Web service. In doing so, the service account Webservice will maintain the password for this service.
Let’s open up IIS Manager which can be found in Server Manager under Tools.
Then, expand the host computers tab, which in my case is LON-DC1 and select Application Pools.
Don’t worry, we’ve got just a few more steps left in the process!
Step 7: Associate The gMSA With DefaultAppPool
Next, you will right click DefaultAppPool and click Advanced Settings. From there, proceed to the Process Model section, and click the ellipses which are the three dotted lines(…) on the right.
Under the Application Pool Identity, I am going to select Custom Account and click on Set. Then in User name, enter the name of the service account. Mine is Webservice$, and make sure to use $ at the end of the name. Leave the password section blank and click OK.
Now, you have created a Group Managed Service Account and associated it with a service. Group Managed Service Accounts are most beneficial when you must operate different services under the same service account, for example in a NLB or cluster environment. In some cases, those different services can be across multiple servers. In the example above, I kept it simple and used only one server to associate with the account which was LON-DC1.
Another way this can be completed is by creating a security group and adding all the computers or server in the group. Then in the parameter PrincipalsAllowedToRetrieveManagedPassword, you will just enter the security group name. Then any computer in the group can retrieve the password to utilize the gMSA functionality. Below is an example of the cmdlet if a security group was being used instead of individual names of each server.
gMSAs are helpful in environments where server farms using NLB is utilized because the accounts can associate with multiple servers to run services, scheduled task, SQL servers, or IIS application pools. Also, remember to use gMSA when you need at least one Windows Server 2012 domain controller where the account will be created.
So if you’re looking into using server farms, you should look into using gMSA. It also makes it easier on administrators because they do not have to worry about changing the passwords every couple months. gMSA accounts can configure multiple servers using a single account. Allowing you to be able to use NLB provides you with reliability and performance for your servers.
