I saw Benjamin’s Reynolds post this week on Active Directory Group Managed Service Accounts and it piqued my interest mucho, ended up taking it out for a spin in the lab and as a result here’s a step-guide to help you work through it.

The post linked to gives a bread-crumb-trail towards implementing gMSA, laying out the fundamental blocks needed. Great primer.

gMSA means Global Managed Service Account, global as in multiple computers can use the account at the same time, permission to do so is granted via AD group membership. A Managed Service Account (MSA) is the same account but a restriction is in place which locks it down to a single computer, requiring a MSA for each computer participating such as a group of SQL servers.

Let’s step through this lot and get gMSA working in the lab, or with a bit more planning and checks made, even production.

Active Directory KDS Root Key

You will need to make sure your Active Directory has a Kds root key available, this is used to generate passwords for AD Managed Service Accounts.

You only need to install a Kds root key if there isn’t one already there, use the Get-KdsRootKey applet and if one exists skip over this section.

If no Kds root key exists and you have multiple domain controllers use the Add-KdsRootKey command with a 10 hour delay so that everything is in sync before the gMSA is put to use:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(10))

If you have a single domain controller put the date into the past so we can get going immediately:

Add-KdsRootKEy –EffectiveTime ((get-date).addhours(10))

Use Get-KdsRootKey to view the key created:

Use Get-KdsConfiguration to have a nose around:

If you want to dig around further you can see the KDS root key mentioned in Active Directory Sites and Services under Master Root Keys:

To get to the Master Root Keys node crack open Active Directory Sites and Services.

Click on Active Directory Sites and Services then click on View and finally toggle on Show Services Node:

To remove the Kds Root Key entry, delete it from within Active Directory Sites and Services, if you have multiple Domain Controllers, replication will remove it from the other DC’s.

Here’s the Add-KdsRootKey, Get-KdsRootKey and Get-KdsConfiguration documentation.

Create an AD Group to grant computers usage permissions to use the gMSA

I created an AD group called gMSASQLServers within which I dropped in my Site server which is hosting SQL locally, if SQL was remote I’d add the SQL servers computer account here instead:

Reboot any member server added to the new group, so that its computer account token is refreshed and includes the new group membership.

Create the AD Group Managed Service Account

Now the fun stuff. We’ll create a gMSA that has restricted access and bind it to the new AD group just created using the New-ADServiceAccount PowerShell applet.

Visit a Domain Controller and open an elevated PowerShell shell.

If you don’t need an SPN due to SQL running locally to ConfigMgr enter the following:

New-ADServiceAccount -name gMSASQLService -enabled $true -DNSHostName gMSASQLService.configmgr2012.com -PrincipalsAllowedToRetrieveManagedPassword gMSASQLServers

If SQL is running remote you’ll need the SPN, what I am not sure of is whether the SPN is registered on the gMSA or the computer account for the server hosting SQL, I would expect it to be on the computer account but since I’ve not tested this on remote SQL I’m not sure, so I opted to apply the SPN to the gMSA (you can easily add it to the computer account instead, don’t forget to remove it from the gMSA beforehand), enter the following:

New-ADServiceAccount -name gMSASQLService -enabled $true -DNSHostName gMSASQLService.configmgr2012.com -PrincipalsAllowedToRetrieveManagedPassword gMSASQLServers “MSSQLSvc/L4CM2012TP.configmgr2012.com:1433″

Here’s some good info on SPN’s over at Microsoft Docs.

Get-ADServiceAccount -Identity gMSASQLService

If you want to remove this managed service account use the Remove-ADServiceAccount applet:

Remove-ADServiceAccount -Identity gMSASQLService

Install and test the AD Service Account on the SQL Server

I found these steps to be redundant in that when SQL Server Configuration Manager is used to change over to the gMSA, the gMSA seemingly is installed\cached at that point and ready to go, If I’m wrong then the steps are reproduced below. You can read the documentation for Install-ADServiceAccount here

Head on over to wherever the SQL server hosting the CM Database is.

You most likely will have to install AD DS and AD LDS tools via Server Manager unless its already been done.

  • Open Server Manager
  • Navigate through until you can tick AD DS and AD LDS Tools

  • Click Next and Install

  • Open an elevated PowerShell shell
  • Type in the following command

Install-ADServiceAccount gMSASQLService

  • Now test the account to make sure it is okay

Test-ADServiceAccount gMSASQLService

Configure permissions on any certificates SQL is using

If you have assigned PKI certificates to the SQL server and you go ahead and configure SQL to run using the gMSA it most likely won’t work straight off. SQL may be using a certificate from the computers certificate store for SSL purposes, if one is found SQL when starting up will try to get at the private key of the certificate using the gMSA and fail, this is due to lack of permissions which will be assigned to SYSTEM and not the gMSA, here’s some shots highlighting and then cleaning this up on my lab device.

The SQL Server service refusing to start even though the gMSA is bonified: