Using Group Managed Service Accounts

A Group Managed Service Account (gMSA) is the type of domain account configured on the server. It does not need the administrator to manage the password as this role is performed by the Microsoft Windows operating system. Randomly generated complex passwords are automatically changed every 30 days which reduce the risk of brute force and dictionary attacks. For more information about gMSAs, see this Microsoft article.

You can use gMSAs to only run guest processing tasks.

Requirements and Limitations

gMSAs have the following requirements and limitations:

• gMSAs are applicable to Microsoft Windows Server 2012 and later. For more information about operating system and Microsoft Active Directory requirements, see this Microsoft article.

• gMSAs are not supported for backups of the Linux target machines joined to the Active Directory domain.

• When using gMSAs for guest processing, consider the following:
• For backup and replication jobs:

• A guest interaction proxy must be joined to the Active Directory domain where the gMSA was created.
• The gMSA must also have Logon as a service permission granted.

• For CDP policies, the backup server must be joined to the Active Directory domain where the gMSA was created.

• Veeam Explorers do not support data recovery using gMSAs.
• Since gMSAs require a connection to the domain controller, these accounts work only over network.
• If you use gMSAs to manage the restore process of VM guest OS files, consider Requirements and Limitations.
• If you back up a machine using a gMSA, both the guest interaction proxy and the target machine must have network access to the domain controllers and be in the same domain to obtain the gMSA password. On the target machine the gMSA must be added to the Administrators group (local or domain). Domain Administrator permissions are only required for Microsoft Active Directory backups, for other supported applications local Administrator permissions are sufficient.

Before You Begin

Before you start using gMSAs, configure the domain controller:

1. The domain controller requires a root key to generate gMSA passwords. Ensure that the Key Distribution Service is enabled on the domain controller and use the following command in Microsoft Windows PowerShell to generate a root key:

Wait until the Active Directory replication is finished or force it manually. For more information about creating KDS root keys, see this Microsoft article.

2. To enable gMSA support in Microsoft Windows PowerShell, use the following commands:

Creating gMSA

To create a gMSA, use the New-ADServiceAccount cmdlet on the domain controller. For example:

Consider the following:

• In the DNSHostName parameter, specify the FQDN of the gMSA.
• For the PrincipalsAllowedToRetrieveManagedPassword parameter specify the AD group containing computer accounts which will use the gMSA. As an alternative, specify computer accounts separated by comma.
• By default, created gMSAs are shown in the Managed Service Accounts container.

For more information about all cmdlet parameters, see this Microsoft article.

To refresh AD group membership after you create a gMSA, run the following command on the machines on which you plan to install the gMSA:

Alternatively, you can reboot these machines.

Installing gMSA

To install a gMSA on the server or the target machine, perform the following steps:

1. Run the Install-ADServiceAccount cmdlet.

2. Ensure that the gMSA was successfully installed.

3. Add the gMSA to the local Administrators group.

For guest processing, install the gMSA on the guest OS machine and the guest interaction proxy.

Using gMSA

To run guest processing tasks with the gMSA, do the following:

1. Make sure that the following services run under the LocalSystem account:

• The Veeam Backup Service on the backup server.
• The Veeam Data Mover Service on the guest interaction proxy.

2. Add the gMSA account type to the Credentials Manager. For more information, see Group Managed Service Accounts.
3. Select the gMSA when specifying guest OS credentials for jobs or policies.