Forum Widgets
Latest Discussions
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?
Segreation of views for different sub-companies
I am in a group of companies and due to various legal reasons they are not allowed to see each others data, but we are all part of the same azure tenant and active directories. So i want to use the idnetity sensor, and it to feed data into dfi, but i want to give the it teams from the different companies access to ONLY their own data and also allow them to do investations on only their own users. How can i do this segregation within defender?
