New features in Active Directory Domain Services in Windows Server 2012, Part 8: Group MSAs (gMSAs)

Back in Windows Server 2008 R2, Managed Service Accounts (MSAs) solved the problem of unsecure service accounts. Managing them was a nightmare, even if you knew what you were doing. Now, In Windows Server 2012, Microsoft addresses a couple of these challenges This blogposts shows how.   

What's New

Challenges with service accounts

We all use service accounts in our environments. These accounts allow us to run a service with the right amount of privileges. It also allows us to change the passwords for normal accounts, since these are not abused to run services.

However, there is also a downside to service accounts. Problems with service accounts pre-Windows server 2008 R2 include:

• Service account password changes are a nightmare and they tend to break stuff. Nonetheless, it is a best practice to change these passwords regularly.
• Passwords for service accounts are stored in plain text in registry. Sure, the passwords are protected, but still accessible if you know how.
• The Scope of service accounts is not easily set. Service accounts can often be used outside the intended scope, for instance to set up VPN connections are send mail through the (authenticated) SMTP gateway.

MSAs in Windows Server 2008 R2

Microsoft introduced the Managed Service Account (MSA) in Windows Server 2008 R2. This new object type (msDS-ManagedServiceAccount) is derived from the computer account object and lives in the Managed Service Accounts container under the domain root.

It offers a big benefit: just like with a computer account and the typical local system accounts, the managed service account will automatically change it password regularly. IT can also update its Service Principle Name (SPN) automatically.

From a security point of view, this means, in a worst case scenario, a sniffed (and decoded) password(hash) can only be used for a limited amount of time. It also means that when the account is only given the barely minimum privileges, an attacker cannot exploit a vulnerability in the service, beyond the service itself.

From a management point of view, it means you can create automatically changing service accounts per service per host. After renaming the host, the service will start like it did before.

To create and manage Managed Service Account, an Active Directory admin would use PowerShell. The typical command to create a Managed Service Account would look like this:

New-ADServiceAccount -Name MSA-Host1 -Path "CN=Managed Service Accounts,DC=domain,DC=tld"

Note:
While creating a Managed Service Account is also possible using Active Directory Users and Computers (ds.msc), this is not the ideal way to create these accounts.

Then, to assign the Managed Service Account to a host, the following PowerShell command would be used:

Add-ADComputerServiceAccount -Identity Host1
-ServiceAccount MSA-Host1

As a last step, install the Managed Service Account on the host, that hosts the service, in this case Host1:

Import-module Active Directory
Install-ADServiceAccount -Identity MSA-Host1

After this third step you can configure the service to run using the managed service account in the Services MMC Snap-in (services.msc).

gMSAs in Windows Server 2012

Alongside the Managed Service Account (MSA), in Windows Server 2012, a new type of object is being introduced: the group Managed Service Account. (msDS-GroupManagedServiceAccount)

gMSAs provide the same functionality as MSAs within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as IIS Network Load Balance farms, Exchange DAG members and SQL Failover Clusters, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When group Managed Service Account are used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.

gMSAs provide a single identity solution for services running on a server farm, or on systems behind Network Load Balance. By using gMSAs, services can be configured for the new gMSA object and the password management is handled by Windows.

Creating gMSAs

To be able to work with group Managed Service Accounts, first, the Key Distribution Services needs to be turned on on the Domain Controllers. This is a two-step procedure

Step 1. Configure the Group Key Distribution Service

First, you need to check whether the service is configured correctly on your Windows Server 2012-based Domain Controllers. For this, open the Active Directory Sites and Services MMC Snap-in (dssite.msc) and in the View menu check the Show Services Node option.

Then in the left pane, click to open the Services folder, then click to open the Group Key Distribution Service and drill down further by clicking on the Server Configuration node. Here you should see the Group Key Distribution Service Server Configuration object. When it exists, the service has been correctly registered.

In order for the Group Key Distribution Service to work, however, it needs root keys. In the Master Root Keys node under the Group Key Distribution Service node in Active Directory Sites and Services, check whether at least one exists. If not, use the following command to create them:

Add-KdsRootKey -EffectiveImmediately

Note:
Although the command specifies the Root Key to be effective immediately, you will actually have to wait 10 hours for it to become active. This ensures there is ample time to replicate the information to other Domain Controllers.

The command will output a Generally Unique Identifier (GUID) for the new Master Key. The new key should be visible with this GUID as its name in the Master Root Keys node under the Group Key Distribution Service node in Active Directory Sites and Services.

You will only need to create this first step once.

Step 2: Create a group (best practice)

When you want to dynamically scope the gMSA, it's a best practice to use a group. You can specify hosts allowed to consume the gMSA when you create the gMSA, but it's easier to create a group and make the servers a member of the group.

Note:
The servers need to be rebooted afterwards to pick up their new group memberships.

Step 3: Create the gMSA

To create a group Managed Service Account use the following PowerShell one-liner:

New-ADServiceAccount gMSA1 –DNSHostName MemberSrv1.domain.tld
-PrincipalsAllowedToRetrieveManagedPassword ShortGroupName

Note:
By default, a gMSA will change the password every 30 days, as defined in the msDS-ManagedPasswordInterval.

Step 4: Enable the gMSA for use on the hosts

On the host that hosts the service, execute the following command to make the gMSA available for selection in the Services MMC Snap-in (services.msc):

Install-ADServiceAccount gMSA1

Step 5: Specify the gMSA as the service account on the hosts

Now, in the Services MMC Snap-in (services.msc), specify the group Managed Service Account as the service account for the intended service:

    

Creating MSAs in Windows Server 2012

For Windows Server 2012, the Windows PowerShell cmdlets default to managing the group Managed Service Accounts instead of the server Managed Service Accounts. To create a 'normal' MSA instead of a gMSA, use the following PowerShell syntax:

New-ADServiceAccount MSA-Host1 -RestrictToSingleComputer    

Requirements

In order to create and use group Managed Service Accounts (gMSAs), you will need to meet the following requirements:

• Deploy at least one Windows Server 2012-based Domain Controller
  Even though gMSAs can authenticate to any Domain Controller in the environment, the passwords are computed by the Group Key Distribution Services (GKDS) running on Windows Server 2012-based Domain Controllers
     
• Active Directory Powershell on management servers
  Implement a Windows Server 2012-based member server with the Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools.
    
• Active Directory PowerShell on management workstations
  Implement a Windows 8-based domain-joined workstation with the Remote Server Administration Tools (RSAT) package installed and Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools.
    
• Recommended: Windows Server 2008 R2 Domain Functional Level
  For automatic password and SPN management to work, the Active Directory environment should be running the Windows Server 2008 R2 Domain Functional Level. If the domain is less than Windows Server 2008 R2 Domain Functional Level, automatic passwords will work, but automatic SPN management will not work, and SPNs will have to be maintained by administrators.