Managed Service Groups (MSA)

During my interventions at my clients I still continue to see service accounts created in the old-fashioned way, this way of doing is no longer in adequacy with the security standards. When we wanted to use a service account for SQL weaned by Example, the latter, as a rule, was a user account of the domain to which we assigned the following parameters:

• A fixed password that never expires (Password Never Expires)
• User can not change password (User can not changed password)

Windows Server 2012 has arrived with many new features. Among them, the possibility of creating “gMSA”.

On Windows Server 2008R2, we could only create Managed Service Accounts (MSA) that can be used on a single machine and can not be used for scheduled tasks.

We now benefit from several new features, including:

• The use of gMSA on several machines.
• The use of gMSA for scheduled tasks.
• The use of gMSA for IIS application pools for example or other applications. However, we must check before that if our application supports the use of gMSA

Managed Service Account (MSA)

An MSA is a domain account specifically assigned to a single computer and designed to perform a service. However, it can not be used to connect to a computer. In summary, this is an account administered by the domain controller and unable to log on locally. Its composition is {DOMAIN} \ {Service account} $ and the generated passwords have a structure of 240 random cryptographic characters.

Prerequisites

To set up MSAs, you must validate the following prerequisites:

• Schema greater than or equal to Server 2008 R2
• A schema in version 2008 can be used but the management of the SPN is not supported
• Install the account on a version greater than or equal to Server 2008 R2 or Windows 7
• Install PowerShell Commands for Active Directory on the Server and Client Side
• Install the 3.5 Framework

limitations

MSAs, however, have certain limitations. Because of this, they can not be used on:

• Multiple computers
• Clustered nodes
• A load-balancing system (NLB) for web servers using Kerberos
• A scheduled task

Managed Service Groups (gMSA)

GMSA (“Group Managed Service Accounts”) appeared with Windows Server 2012 to address the major problems of MSA accounts, namely the use of an account on a single computer. As a result, it was, for example, impossible to use the same MSA account on an SQL cluster. You had to either use a service account for each server or create one or more domain accounts for the server farm. With the gMSA, this “1: 1” restriction has been removed and it is now possible to use the same account on multiple servers. We will agree that this new feature makes sense with the AAG technology introduced with SQL Server 2012. In its operation, a gMSA is a service account associated with security group in which computers authorized to use this account will be added.

Prerequisites

To set up gMSA, you must validate the following prerequisites:

• Have a DC with a schema greater than or equal to Server 2012
• Create a KDS root key (detailed later)
• Install the account on a version greater than or equal to Server 2012 or Windows 8
• Install PowerShell Commands for Active Directory

KDS key :

Domain controllers running Windows Server 2012 require a KDS root key for generating passwords associated with gMSA accounts. After its creation, it is necessary to wait 10 hours so that the replication between DC converges. This is a security measure to ensure that all DCs are able to respond to gMSA requests (source).

After that, you can see the creation of the MSA in the Managed Service Account:

Account Association

It is then necessary to associate the created MSA with the computer on which it will be used:

Account setup

Finally, install this service account on the target computer. To do this, go to the machine that will use this account and run the following command:

Account setup with a service

We will now configure this account to be used by an SQL instance:

• Open the SQL Server Configuration Manager console and access the Log On property of the service in question:

Leave the password blank and restart your service:

Establishment Managed Service Groups (gMSA)

Verification of the AD schema

We will first check the version of our AD schema:

The objectVersion attribute is at 69 (2012R2).

By exploring our AD schema we can see that we have the class “msDS-GroupManagedServiceAccount” that inherits classes:

• msDS-GroupMSAMembership – attribute to identify (group or machine) who will be able to obtain the password and use the gMSA.
• msDS-ManagedPassword – attribute containing the current password, the old password but also the password change interval.
• msDS-ManagedPasswordInterval – attribute configured at the time of account creation (can not be changed later!), which will determine how many days the password needs to be changed.
• msDS-ManagedPasswordID – ID used by the service (KDS) to generate the current password.
• msDS-ManagedPasswordPreviousID – ID for the old password.

KDS configuration

Creating a gMSA

Adding the computer account in a group

Add the target computer from the previous point ($TargetComputer) in the management group created in this regard ($gMSAGroup).You must then restart your target server to take into account this new membership (ou « membership ») :

Account setup

Once the target computer has restarted, install the gMSA account on it: