Azure ATP sensor : Could not create SSL/TLS secure channel

Copper Contributor

Hi All,

 

I have multiple DC on which Azure ATP sensor is working fine, however on one of Domain controller 2008 R2 server it is throwing below error

 

Error ExceptionHandler Microsoft.Tri.Infrastructure.ExtendedException: RestrictCpuAsync failed, exiting ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

 

Could you please advise, installation is having no issues

 

Microsoft.Tri.Sensor-Errors - shows above logs

15 Replies

@aniketvpandey something is blocking proper TLS communication on localhost between the sensor process and the updater process.

 

@Eli Ofek thanks for your advise, anything you would like to advise, it was working before?

 

I have checked TLS 1.2 enabled

@aniketvpandey 

 

The TLS communication is on localhost :444, any chance there is a new FW rule that cause issues?

 

Some of the cases we know about were resolved by making sure these registry values are set to 0 (1 is not the default)

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

"DisableRenegoOnServer"=dword:00000001

"DisableRenegoOnClient"=dword:00000001

 

Was ADFS installed on this machine by any chance?

 

 

@Eli Ofek 

Hello,
I have the same problem on ADFS Sensor. It's Windows server 2019.
I didn't have problem on the Domain Controller just on ADFS.

 

The service Update is running but not the service AATPSensor. It just starting again and again.

Can you help me?

 

Error:

2022-04-13 08:03:19.6535 Error ExceptionHandler Microsoft.Tri.Infrastructure.ExtendedException: RestrictCpuAsync failed, exiting ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at Stream System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, out TransportContext context)
at void System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at async Task<HttpResponseMessage> System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task<HttpResponseMessage> sendTask, HttpRequestMessage request, CancellationTokenSource cts, bool disposeCts)
at async Task<TResponse> Microsoft.Tri.Common.CommunicationWebClient.SendAsync<TResponse>(byte[] requestBytes, int offset, int count)
at async Task<TResponse> Microsoft.Tri.Common.CommunicationWebClient.SendWithRetryAsync<TResponse>(byte[] requestBytes, int offset, int count)
at async Task Microsoft.Tri.Common.CommunicationWebClient.SendAsync(IVoidRequest request)
at async Task Microsoft.Tri.Sensor.Common.ServiceProxy<TWebClientConfiguration>.SendAsync(IVoidRequest request)
at async Task Microsoft.Tri.Sensor.SensorResourceManager.RestrictCpuAsync()
--- End of inner exception stack trace ---

 

I have this error on updater but the service is running.

2022-04-13 08:04:13.8606 Error ServiceControllerExtension ChangeServiceStatus failed to change service status [name=AATPSensor status=Running Exception=System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
at Microsoft.Tri.Infrastructure.ServiceControllerExtension.ChangeServiceStatus(String name, ServiceControllerStatus status, TimeSpan timeout, Nullable`1 awaitedStatus)]

@Sebastien65 The error in the updater's log is expected given the fact that the sensor is failing to start.
It has a watchdog that alerts the sensor is down. 

As for why the sensor is failing to communicate over TCP/444 using TLS, given that you tried my previous suggestions, I would say you should open a support ticket to get an engineer to deep dive into this,

it is most likely a configuration/policy issue of some sorts, but it's impossible to troubleshot over community posts. We can update here once you get this resolved and add info about what was the issue.  

@Eli Ofek 

 

Did this ever resolve? I have the exact same problem on a 2019 DC.

@arejoh 

No I didn't resolve and I have open a ticket with Microsoft and send my logs but for the moment.

 

But for the moment nothing works better.

 

You have the problem on the DC 2019 not ADFS? So maybe the problem is only on 2019 server and not because it's ADFS server for moment.

 

For the moment Microsoft said nothing when I said I have only the problem on 2019 Server.

@Sebastien65 
I am not aware what is going on with the support ticket,

but I can say that there is no such "known issue" with 2019 AD or ADFS.

We have tons of them working fine world wide without any issues.


From previous incidents, it was always some sort of policy on the machine the customer was not aware of,  or a 3rd party that was creating the block.

@Eli Ofek 

Hello,

I didn't have the problem on all my DC. I Have more than 20 DCs without problem but all my DCs are with 2012 Server R2.

My 2 ADFS Server are in Windows Server 2019 and I have the same problem.

@Sebastien65 

 

I reverted to ncap v1.0 from 1.1

ATP now works.

Can you elaborate on the npcap install?
was npcap 1.1 pre installed for a different reason before you deployed the sensor ?
If so, was it deployed with the correct parameters ? (compatibility, no admin only)
And which parameters were used when you deployed 1.0 ?

I uninstalled wincap but ncap 1.1 was not install and I installed Ncap 1.0 in zip folder « Azure ATP sensor Setup ».

I installed with good parametet I follow the process on the microsoft site.
There was some testing of issues at some point prior to ATP sensor install, with wireshark. It was in place from their installer. We have 6 DCs running atm at that location and this was the only 1 with issues. The others are all using npcap 1.0. The process was the standard microsoft (https://docs.microsoft.com/en-us/defender-for-identity/technical-faq#winpcap-and-npcap-drivers) one, with npcap 1.0 from the downloaded folder. NPCAP is up to v1.70 now. I assume that upgrading to the current version is beneficial?
We don't lock down to a specific npcap version, so in theory you can upgrade to 1.70 and it might just work.
If you run into issues with 1.70 you can open a support case with us, and we will try to work with Npcap to resolve this in best effort mode.

The main problem is that we didn't test 1.70 with MDI so we can't say it will work well without any issues. 1.0 was tested heavily in the past.
We did not test newer versions as 1.0 is very stable (we worked hard for a few months with npcap to make sure it is), and there are no known CVE's or issues that will interrupt MDI with it.