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.
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.
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.
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.