Forum Widgets
Latest Discussions
Incorrect Secure Score recommendation - Remove unnecessary replication permissions
Hi, In our environment, we got the "Remove unnecessary replication permissions for Entra Connect AD DS Connector Account" secure score recommendation. Based on the https://learn.microsoft.com/en-us/defender-for-identity/remove-replication-permissions-microsoft-entra-connect replication permission is needed when PHS is in use. We are using PTA, but PHS is also enabled as a fallback. On the Entra Connect server I ran the following: Import-Module ADSyncDiagnostics Invoke-ADSyncDiagnostics -PasswordSync The result is: Password Hash Synchronization cloud configuration is enabled If I remove the replication permission, we soon receive an alert that password hash sync did not occour. Is it normal? I would say that the sensor should be able to detect PHS usage hence not recommending to remove the permissions. Thank you in advance, DanielAlert Not Found
We are receiving the following the follow alert from Defender; 2025-08-15T09:26:42-07:00 {SERVERNAME} CEF[6208]0|Microsoft|Azure ATP|##########|AccountEnumerationSecurityAlert|Account enumeration reconnaissance|5|start=2025-08-15T16:23:14.5550516Z app=Ntlm shost=NULL shostfqdn= msg=An actor on NULL performed suspicious account enumeration, exposing 6 existing account names. externalId=2003 cs1Label=url cs1=https://security.microsoft.com/alerts/xx###xxxx-#xx#-####-#x##-##x##x#x#x#x cs2Label=trigger cs2=update But when we go to the URL listed, we get an error that it can't be found. We are able to see other alerts that come in. How do I go about finding the details on this error?
Low success rate of active name resolution NetBIOS (failed rates 80%) andRdpTls (failed rate 90%).
Low success rate of active name resolution Three Domain controllers are failing name resolution using NetBIOS (failed rates 80%), NetworkNameResolverMethod RdpTls (failed rate 90%) however RPC over NTLM and reverse DNS working confirmed by Microsoft support.The three domain controllers are runing windows server 2016 with the installed Azure ATP Sensor on the DCs is version is 2.243 I need assistance how to get this issue resoves on the failing three dc please.
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.
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.
