Install the Microsoft Defender for Identity sensor on Active Directory Certificate Services

Microsoft released a new Microsoft Defender for Identity (MDI) sensor type for Active Directory Certificate Services (ADCS). Visit this article to see what’s new in Microsoft Defender for Identity. The article is updated frequently to know what’s new in the latest released of MDI.

In this blog I will demonstrate how to deploy the MDI sensor on your ADCS servers.

Download the MDI sensor

The sensor can be downloaded from the Microsoft 365 Defender portal. The sensor installation package is the same for Domain Controllers, ADFS and ADCS.

Refer to this blog post for the download steps.

MDI Sensor installation

I’ve already downloaded the MDI Sensor package, copied and extracted the zip file on my ADCS Issuing server.

Execute the “Azure ATP Sensor Setup” install file.

Enter the Access key obtained from the Microsoft 365 Defender portal. The latest key should be used. The installation will fail should you use an old access key after regenerating the access key from the portal.

Wait for the installation to complete.

You can validate the sensor installation in the Microsoft 365 Defender portal. The newly deployed sensor should be displayed on the Sensors page in the Microsoft 365 Defender portal. The sensor type should be listed as an AD CS Sensor and the service status should be Running.

In my instance, the ADCS sensor service status was showing as Starting and did not go into the Running state.

Troubleshoot the service in starting state

The System event log in Event Viewer listed the error events. The Azure Advanced Threat Protection service terminated unexpectedly.

I reviewed the Microsoft.Tri.Sensor log and found an issue with the Group Managed Service Account (GMSA) configured in the MDI portal.

“failed to retrieve group managed service account password.”

The image below shows the GMSA account configured in the Microsoft 365 Defender portal.

Configure Group Managed Service Account (GMSA)

The PrincipalsAllowedToRetrieveManagedPassword attribute determines on which computer accounts the GMSA account can be used. Only the accounts specified in this attribute will be able to retrieve the GMSA account password.

The attribute can contain either computer accounts or security groups. In my environment I’ve specified a security group and I manage the GMSA account access by adding or removing computer objects to this security group.

For more information on GMSA accounts, refer to this blog post.

I’m running the following command to determine which group or computer objects are defined in the PrincipalsAllowedToRetrieveManagedPassword attribute:

Get-ADServiceAccount gmsa-adtasks -Properties * | FL KerberosEncryptionType,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName

Current members of the group. Only these computer accounts are allowed to retrieve the GMSA account password. My ADCS server is not a member of this group and thus cannot use the GMSA account. This is causing the issue with the MDI service not being able to start.

I add the ADCS server account to the security group, and then restart the server for the computer object group membership changes to take effect.

Verify MDI Sensor service status

After the GMSA account was updated and the server rebooted, I could see that the MDI service is now in a running state as per the Windows Services console:

The MDI sensor status on the Microsoft 365 Defender portal is also showing the expected status for the service.


Installation of the MDI sensor on ADCS server follows the same steps as running the installation on Domain Controllers. Verify the service health after the installation and ensure proper configuration of the service account specified in the Microsoft 365 Defender portal.