MDI Sensor on ADCS fails to start
Microsoft Defender for Identity Group recently released the Active Directory Certificate Service (ADCS) support and expanded its coverage with a new AD CS sensor!. Great milestone.
Like other sensor types in Microsoft Defender for Identity, this one is simple to prepare, install, and configure as required. Sometimes, the sensor could not start because of some reason.
While installing the Microsoft Defender for Identity sensor on the Active Directory Certificate Service (ADCS) server, the sensor did not enter a running state, even when the MDI sensors had completed the installation correctly.
While checking the status of the services, the service with the name Azure Advanced Threat Protection Sensor Updater (AATPSensorUpdater) is up and running. Still, the primary service, the Azure Advanced Threat Protection Sensor (AATPSensor), isn’t running. Once you check the service state and attempt to start the service, you receive a failed window.
The image below describes the service status. The event log raised a common error log, and the service is in stopped mode.
If you go to the Defender for Identity prerequisites for ADCS and check the requirements, you will find that the requirements were set correctly.
Troubleshooting MDI on ADCS
Troubleshooting Microsoft Defender for Identity sensor on the Active Directory Certificate Service (ADCS) is straightforward.
The event log viewer shows a common name for this error with the following information:
- The Azure Advanced Threat Protection Sensor service terminated unexpectedly. It has done this 2570 time(s). The following corrective action will be taken in 5000 milliseconds: Restart the service.
- Service Control Manager
In the background, the Azure Advanced Threat Protection Sensor (AATPSensor) service is trying to start with no success.
You can validate the sensor status in the Microsoft 365 Defender portal. The newly deployed sensor will be displayed on the Sensors page. The ADCS sensor service status was showing as Starting and did not go into the Running state.
While searching for the error in Microsoft.Tri.Sensor log, you can find a few errors. One of them will be the following one.
“DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=red-dc1.red.local Domain=red.local UserName=mdiSvc01]”
In a nutshell, when the Azure Advanced Threat Protection Sensor (AATPSensor) is starting, the service tries to connect to the nearest DC and retrieve the Group Managed service information. If he doesn’t have the required permissions, the request will fail, and the error will appear on Microsoft.Tri.Sensor log.
The primary information in the log will be as the following:
2023-11-04 07:05:22.2553 Info RemoteImpersonationManager CreateImpersonatorInternalAsync finished [UserName=mdiSvc01 Domain=red.local]
2023-11-04 07:05:22.2553 Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=red-dc1.red.local Domain=red.local UserName=mdiSvc01 ]
2023-11-04 07:05:22.6459 Error DirectoryServicesClient+<CreateLdapConnectionAsync>d__47 Microsoft.Tri.Infrastructure.ExtendedException: CreateLdapConnectionAsync failed [DomainControllerDnsName=red-dc1.red.local] at async Task<LdapConnection> Microsoft.Tri.Sensor.DirectoryServicesClient.CreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing) at async Task<bool> Microsoft.Tri.Sensor.DirectoryServicesClient.TryCreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing)
2023-11-04 07:05:22.6771 Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers [ _domainControllerConnectionDatas=red-dc1.red.local] at new Microsoft.Tri.Sensor.DirectoryServicesClient(IConfigurationManager configurationManager, IDirectoryServicesDomainNetworkCredentialsManager domainNetworkCredentialsManager, IDomainTrustMappingManager domainTrustMappingManager, IRemoteImpersonationManager remoteImpersonationManager, IMetricManager metricManager, IWorkspaceApplicationSensorApiJsonProxy workspaceApplicationSensorApiJsonProxy) at object lambda_method(Closure, object)
For those who are familiar with the Microsoft Defender for Identity sensor and its errors, this error is a bit familiar.
To solve this issue, you must set the permissions and add the new ADCS server to a specific group. Below are the instructions.
ADCS – Verify that the ADCS can access the password. You should have a Security Group in Active Directory that contains the domain controllers, ADFS servers, ADCS servers, and standalone sensors server accounts included.
Note: If a Security Group doesn’t exist, you should create one.
Then, add the relevant ADCS server object to the specific group.
PrincipalsAllowedToRetrieveManagedPassword – The PrincipalsAllowedToRetrieveManagedPassword attribute determines on which computer accounts the GMSA account can be used. Only the accounts specified in this attribute can retrieve the GMSA account password. The attribute can contain either computer accounts or security groups.
You can use the following command to check if a computer account or security group has been added to the parameter. Replace mdiSvc01 with the name you created.
Get-ADServiceAccount mdiSvc01 -Properties * | FL KerberosEncryptionType,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName
Then, you should set the command in the ADServiceAccount
Set-ADServiceAccount mdiSvc01 -PrincipalsAllowedToRetrieveManagedPassword “mdiSvc01Group”
Once you create the relevant group, add the ADCS server account, and set the required permission in the service account, the Azure Advanced Threat Protection Sensor (AATPSensor) service will start and change to Running state.
You should verify the state mode in the ADCS server, the Microsoft 365 Defender, and the Microsoft.Tri.Sensor log.
below is the Microsoft 365 Defender portal.
The Microsoft.Tri.Sensor log – this time, the DirectoryServicesClient can initiate the connection successfully.