Daily Defender News
Aboutmerill.net
Microsoft Defender for Identity
Identity protection

Configure a gMSA directory service account for Defender for Identity

4 September 2026Feature updateAction required+49 / −21 lines

In brief

The instructions now cover multi-domain and multi-forest deployments, require Enterprise Admin permissions when using a root-level group and single gMSA, and document KDS root-key replication timing and group-scope options.

What Defender admins need to know

For applicable deployments, use the required permissions and allow 10 hours for KDS replication. Use the accelerated key timing only in single-domain-controller test environments, not production.

Summaries are generated from the documentation change itself.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

Configure a gMSA directory service account for Defender for Identity

Create and configure a group managed service account (gMSA) for the sensor v2.x to use when reading Active Directory data (querying objects, tracking changes, resolving entities). This is separate from the action account used to perform remediation actions like disabling users or resetting passwords. Before you begin, review the prerequisites for creating a gMSA for sensor v2.x deployments.

  • Choose how to configure password retrieval:

    • Assign the gMSA account directly to each of the sensors.

    • Use a group that contains all the sensors that need to use the gMSA account.

  • Choose the appropriate group based on your deployment:

    • Single-forest, single-domain deployment:

      • Use the built-in Domain Controllers security group if you're not installing sensors on Active Directory Federation Services (AD FS) or Active Directory Certificate Services (AD CS) servers.

    • Forest with multiple domains:

      • If you use a single Directory service account (DSA), we recommend creating a universal group and adding each of the domain controllers and AD FS or AD CS servers to the universal group.

      • In multi-forest or multi-domain environments, make sure the domain where you create the gMSA trusts the sensors’ computer accounts.

      • Option 1: Use a gMSA per domain. Create a Domain Local group in each domain that includes only the sensors computer accounts from that domain so that only those sensors can retrieve the gMSAs' passwords and perform the local domain authentications.

      • Option 2: Use ashared gMSA across all domains. Create a Universal group at forest root that includes all sensors computer accounts so that all sensors can retrieve the gMSAs' password and perform the cross-domain authentications.

Create the gMSA account

  1. If you've never used a gMSA account before, you might need to generate a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory. This step is required only once per forest. To generate a new root key for immediate use, run the following command: 

    Add-KdsRootKey -EffectiveImmediately

    Although the command name suggests that the key takes effect immediately, wait 10 hours for the KDS root key to replicate and become available on all domain controllers.

    If your test domain has only one domain controller, you can expedite the process by setting the key's effective time to 10 hours earlier. 

```powershell
# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```

  1. Run the PowerShell commands as an administrator. This script will:

    • Create a gMSA account.
    • Create a group for the gMSA account.
    • Add the specified computer accounts to that group.
    • Configure the gMSA to use AES128 and AES256 Kerberos encryption.

  2. Before running the script:

    • Update the variable values to match your environment.
    • Make sure to give each gMSA a unique name for each forest or domain.

Define the gMSA creation variables, including the account name, host group, and computer accounts, then run the following script to provision the gMSA: 

# Variables:
# Specify the name of the gMSA you want to create:
if ($gMSA_HostsGroupName -eq 'Domain Controllers') {
    $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
} else {
    # If this group is being created at the root of a forest and will be used across multiple domains or subdomains then the -GroupScope parameter should be changed to Universal
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope DomainLocal -PassThru
    $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
        ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
}

# Specify the Kerberos encryption type as AES.
$kerberosEncType = ('AES128','AES256')

# Create the gMSA:
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
 -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup -KerberosEncryptionType $kerberosEncType

Grant required directory service account permissions

The directory service account requires specific read permissions on Active Directory objects so that the sensor can query directory data. The following include details the required permissions and how to grant them:

[!INCLUDE dsa-permissions]

Verify that the gMSA account has the required rights

The Defender for Identity sensor service, Azure Advanced Threat Protection Sensor, runs as a LocalService that impersonates the DSA account. If the Log on as a service policy is configured but the permission wasn't granted to the gMSA account, the impersonation fails. In that case, you see the following health issue: Directory services user credentials are incorrect.

If you see this alert,the health issue Directory services user credentials are incorrect, check to see if the Log on as a service policy is configured either in a Group Policy setting or in a Local Security Policy.

Check the Local Security Policy

Troubleshooting

For more information, see Sensor failed to retrieve the gMSA credentials.