Using Group Managed Service Accounts

Windows Server 2012 comes with group managed service accounts, an improved version of the original MSA. Ever since Windows Server 2008 R2 was out, I remember reading about managed service accounts (MSA) a new feature that I wanted to check out. You can read more about MSA here, but in essence they are useful because they have automatic password management.

Introduction

I always wanted to try MSA and was recently in a position to propose using MSAs, but after re-reading the information, specifically “A managed service account can only be installed on a single computer” I decided to skip MSA.

However, I did research if anything had changed since 2008 R2 and apparently it has – Doug Symalla on TechNet has a very interesting article about the new Group Managed Service accounts and how they work in Server 2012.

As MSAs are actually useful now (“A single gMSA can be used on multiple hosts.”), I decided to give it a go and try to use a gMSA in an IIS application pool connecting to a SQL 2008 R2 server. This blog posts details the steps of configuring a gMSA and what I learned in the process.

Install ADDS and configure group Managed Service Accounts

I started by creating 2 servers, SRV001 – domain controller (forest level 2012) and web server (IIS) and SRV002 – SQL Server 2008 R2.

After joining the 2 servers in the same domain, the first problem I ran into was the fact that I had to wait 10 hours for the KDS root key to replicate to all domain controllers.

The error that I would get was New-ADServiceAccount : Key does not exist

In order to skip waiting 10 hours, I used the PowerShell command below, then created the gMSA.

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
New-ADServiceAccount -name IISAppPool1 -DNSHostName SRV001.test.local -PrincipalsAllowedToRetrieveManagedPassword "Domain Computers"

For simplicity, I configured all “Domain Computers” to have rights to this gMSA but in a production environment a distinct security group should be used for each gMSA.

If you don’t configure a proper security group on the service accounts, this is the error you will get when trying to install it

I performed the next two commands on both servers:

Install-ADServiceAccount IISAppPool1
Test-ADServiceAccount IISAppPool1

If the return value of the 2nd command is True then the gMSA has been successfully installed.

Configure gMSA on SQL Server

Next, on the SQL server I configured a new login called testIISAppPool1 where test is the NetBios domain name

.

Make sure to give the gMSA the necessary permissions to access the database server (e.g. enable Windows authentication, remote connections and provide proper database level permissions).

Configure IIS Application pool to use gMSA

Back on domain controller, I installed a web application called ScrewTurnWiki which I used previously and configured it using SQL authentication. After making sure it all works nicely I proceeded to change the settings to use the group Managed Service account.

Open IIS manager (Start, run, inetmgr) and go to Application Pools.

Select the IIS application pool (e.g. wiki) and go to Advanced Settings –> Identity

Configure the IIS application pool to use the gMSA and leave the password fields blank.

You should now see the application pool working under the new identity as below:

I then had to configure the application to use Windows instead of SQL authentication. This may vary based on your application. I modified the following line in the Web.config:

<add key="SettingsStorageProviderConfig" value="Trusted_Connection=True;Database=ScrewTurnWiki449;Server=srv002sqlexpress">

If everything is properly configured, a refresh of the application should load the same page. However, using the SQL Server Management Studio, we can open the current logs and see that a gMSA is being used to access the application

References

• New-ADServiceAccount : Key does not exist – TechNet forums
• Managed Service Accounts with Microsoft SQL Server 2012
• Windows Server 2012: Group Managed Service Accounts – Ask Premier Field Engineering (PFE) Platforms
• Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting