Forum Widgets
Latest Discussions
Sensor install failing, error log indicates proxy issue
Hi Everyone, I was re-installing a sensor that was stuck on updates and I get an error in the logs - failed connecting to service. The issue can be caused by a transparent proxy configuration From what I can find that's related to either missing certificates or SSL inspection. The proxy works fine for other sensors and I know it's not inspecting this traffic anyway. I found a troubleshooting page that calls out the specific Root CA - "DigiCert Global Root G2" which exists on this machine. https://learn.microsoft.com/en-us/defender-for-identity/troubleshooting-known-issues#proxy-authentication-problem-presents-as-a-connection-error I believe this sChannel error is related The remote server has requested SSL client authentication, but no suitable client certificate could be found. I am stumped at this point, any help is appreciated.Agent install error
Hi Everyone, One of the servers running the agent was failing to update so I attempted a reinstall. During install it fails / rollsback with an error in the log stating "failed connecting to service. The issue can be caused by a transparent proxy configuration". The device does use a proxy set via netsh, and I've tried specifying it on the command line of the install. I have read elsewhere that this can be related to SSL inspection or an issue with Root CAs on the device. I know there is no inspection going on in this case. I have compared the Root CA list on this device to working devices and don't see anything related to Microsoft that is different. Any ideas?
Clarification over "dormant" account status
I was looking today at our list of "Remove dormant accounts from sensitive groups" within Microsoft Defender for Identity, and one service account has caused a bit of discussion. The account would only be used on-premise and would never be carrying out authentications out of our estate. In this case would Defender for Identity still see the account as being "dormant", or is the reason because it's not carried out any of those off-estate authentications? Apologies if this is a simple question, but it would be very helpful to know the answer.
Defender for Identity Certificate Requirements
One of the required certificates for the MDI sensor to run is this certificate: Subject : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE Issuer : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE Thumbprint : D4DE20D05E66FC53FE1A50882C78DB2852CAE474 FriendlyName : DigiCert Baltimore Root NotBefore : 5/12/2000 11:46:00 AM NotAfter : 5/12/2025 4:59:00 PM Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid} It expires in a little over 2 weeks. I still see it listed as required here: https://learn.microsoft.com/en-us/defender-for-identity/troubleshooting-known-issues Does anyone know if that requirement will be going away and/or will the certificate be updated before this one expires? I haven't been able to find anything related to its replacement through my various searches so I apologize if this has been covered already. Thanks.
Spurious health alerts with sensor 2.241.18721.18894
We use delayed update on half of our sensors to help catch possible issues with new sensor versions. Only on half of our DCs running the latest sensor 2.241.18721.18894, we are receiving alerts "The virtual machine that sensor [hostname.domain] is installed on has a network configuration mismatch. This issue may affect the performance and reliability of the sensor" Looking at the alert in the portal, MDI alleges that the affected virtual machines virtual NICs have Large Send Offload (LSO) enabled. However, the virtual machines do NOT have LSO enabled. We are not seeing these alerts from the other half of our sensors that are still running 2.241.18708.7989. The issue is only appearing on VM DCs running sensor 2.241.18721.18894. Anyone else see this issue? All the affected DCs are virtual machines. We do have some bare-metal DCs, but they are still running 2.241.18708.7989.Directory Services Advanced Auditing is not enabled
I have received this alert recently and have tried everything to enable auditing per the recommendation found here Configure Windows Event collection - Microsoft Defender for Identity | Microsoft Learn The errors are getting in the security logs, but MS Defender for Identity continues to say there is a health issue. Any ideas?
Azure ATP Sensor install failing (Updater Service do not start)
Hello All! We try to install the Azure ATP Sensor on a DC, setup wizard is running until this point ...then do some retries for about 3 minutes, during this time the service "Azure Advanced Threat Protection Sensor Updater" is several times on state "starting" und back to not started. Then setup fails with 0x80070643 and do a rollback. In the "Microsoft.Tri.Sensor.Updater-Errors" log, we find this error every 10 seconds during the setup: 2019-12-23 11:27:37.8384 Error CommunicationWebClient+<SendWithRetryAsync>d__8`1 Microsoft.Tri.Infrastructure.ExtendedException: Sanitized exception: [Type=System.Net.Http.HttpRequestExceptionMessage=7INzM3PVZQKggOiiHcWjqw==StackTrace= 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)InnerException=Microsoft.Tri.Infrastructure.ExtendedException: Sanitized exception: [Type=System.Net.WebExceptionMessage=5iiWw0iPCPzCGdZStU4OxA==StackTrace= at Stream System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, out TransportContext context) at void System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)InnerException=]] at async Task<TResponse> Microsoft.Tri.Common.CommunicationWebClient.SendWithRetryAsync<TResponse>(byte[] requestBytes, int offset, int count) at async Task<TResponse> Microsoft.Tri.Common.CommunicationWebClient.SendAsync<TResponse>(IRequestWithResponse<TResponse> request) at async Task<TResponse> Microsoft.Tri.Sensor.Common.ServiceProxy<TWebClientConfiguration>.SendAsync<TResponse>(IRequestWithResponse<TResponse> request) at async Task Microsoft.Tri.Sensor.Updater.SensorUpdaterConfigurationUpdater.UpdateConfigurationAsync(bool isStarted) at void Microsoft.Tri.Infrastructure.TaskExtension.Await(Task task) at new Microsoft.Tri.Sensor.Updater.SensorUpdaterConfigurationUpdater(IConfigurationManager configurationManager, IMetricManager metricManager, ISecretManager secretManager, IWorkspaceApplicationSensorApiJsonProxy workspaceApplicationSensorApiJsonProxy) at object lambda_method(Closure, object[]) at object Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate() at void Microsoft.Tri.Infrastructure.ModuleManager.AddModules(Type[] moduleTypes) at ModuleManager Microsoft.Tri.Sensor.Updater.SensorUpdaterService.CreateModuleManager() at async Task Microsoft.Tri.Infrastructure.Service.OnStartAsync() at void Microsoft.Tri.Infrastructure.TaskExtension.Await(Task task) at void Microsoft.Tri.Infrastructure.Service.OnStart(string[] args) A proxy is used which allows access to *.atp.azure.com without auth. In proxy logs, we see no block for this server, only successful requests from this DC. There is no indication that 443 would be blocked somewhere else... The AD account which is configured in the ATP portal was checked, domain is given in FQDN there and the password is correct. Any ideas someone?
