Forum Discussion
Solved
MDI sensor service will not start on ADFS server
I've exhausted my ability to troubleshoot why my ADFS sensor installs just will not start, so hoping someone can provide some guidance on how to get this working 🙂 Info: Windows Server 2022 Da...
- The rep from Microsoft was able to resolve the startup issue!
If a server has HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList set to 1, that will cause the service to fail.
According to https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview 0 is the default as of 2012R2
Since we did in-place upgrades, it makes sense that the value would be set from those previous OS's.
EliOfekThe ATP cert (Azure ATP Sensor) had the following:
- System
- Administrators
- AATPSensor
I added:
- gMSA
- LOCAL SERVICE
Issue persists, no changes in the logging output that I can observe.
EliOfek
Microsoft
MicrosoftOK, I took a deeper look in the code that outputs this message.
The problem is that the sensor is sending a TLS request to the updater on localhost TCP 444.
It authenticates using a client certificate in the request,
But when the updater gets the request and tries to authenticate via the certificate, it is missing from the request.
So either something is blocking the sensor from putting it there, or we have some kind of "Man in the Middle" in the machine that "scrubs" the certificate out.
Are you familiar with anything installed on this machine that might temper with this request?
Some things I found related to similar cases from the past:
Having ADFS proxy installed on the same machine might cause it.
Some customers reported the issue fixed after setting those registry values to 0:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"DisableRenegoOnServer"=dword:00000001
"DisableRenegoOnClient"=dword:00000001
If all fails, the next step is openings a support request, but I have to be honest with you:
The last case that did not resolved by all of the above required so much research time to check what got broken in the machine that eventually it would have been easier to just rebuild it.
The problem is that the sensor is sending a TLS request to the updater on localhost TCP 444.
It authenticates using a client certificate in the request,
But when the updater gets the request and tries to authenticate via the certificate, it is missing from the request.
So either something is blocking the sensor from putting it there, or we have some kind of "Man in the Middle" in the machine that "scrubs" the certificate out.
Are you familiar with anything installed on this machine that might temper with this request?
Some things I found related to similar cases from the past:
Having ADFS proxy installed on the same machine might cause it.
Some customers reported the issue fixed after setting those registry values to 0:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"DisableRenegoOnServer"=dword:00000001
"DisableRenegoOnClient"=dword:00000001
If all fails, the next step is openings a support request, but I have to be honest with you:
The last case that did not resolved by all of the above required so much research time to check what got broken in the machine that eventually it would have been easier to just rebuild it.
Just to note that I had one domain controller with the registry value present: DisableRenegoOnServer = 0.
It wasn't until I deleted the value completely (same as the working DCs) that the Microsoft.Tri.Sensor.Updater log stopped cycling between the first two lines below and was able to move on to identifying the GMSA account to start the main service.
2024-09-05 23:44:56.4801 Warn ClientCertificateAuthenticationMiddleware+ClientCertificateAuthenticationHandler AuthenticateCoreAsync missing client certificate 2024-09-05 23:44:56.4801 Warn AppBuilderExtension UseExceptionHandler IOException ignored [Details=InnerExceptionType=HttpListenerException ErrorCode=1229] 2024-09-05 23:46:16.2911 Warn GroupManagedServiceAccountImpersonationHelper GetGroupManagedServiceAccountAccessTokenAsync started [AccountName= DomainDnsName=]
Obviously some differences there with ADFS servers compared to DCs (the reg key had probably been added during previous troubleshooting).
- The rep from Microsoft was able to resolve the startup issue!
If a server has HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList set to 1, that will cause the service to fail.
According to https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview 0 is the default as of 2012R2
Since we did in-place upgrades, it makes sense that the value would be set from those previous OS's. - Nevermind, I stopped the updater service and the listening stopped.
- Nope nothing tampering with certs. Is the service supposed to be the process listening on 444, or should it be SYSTEM?
TCP 127.0.0.1:444 0.0.0.0:0 LISTENING 4
