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.
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.
DSA requirements
Hello, DSA is configured with rights "log on as a service" on the domain controllers. Do you need to configure the sensor service it self to also start the service with the DSA account with "Logon as"? Our sensors are starting up fine. But I have some strange logs in the sensor error log file. So I just want to verify that our setup is correct. Thanks!
MDI set up on AD FS but no logs are coming
Hi everyone, We are currently deploying Defender for Identity all around our infrastructure. We already covered all the DCs, however we are facing some configuration issue with the sensors installed on our AD FS farm. In a nutshell, even if it seems that the sensors have been configured correctly (no health issues in the XDR console, service running), when running the KQL query to ensure authentication logs from AD FS are coming in, we get nothing: IdentityLogonEvents | where Protocol contains 'Adfs' No results found in the specified time frame. Here's a summary of the tasks we performed: We installed the sensor on the two servers in our AD FS farm and verified that they check in with the cloud console We enabled verbose logs and granted access to the AD FS database to the gMSA user we use with MDI We were unable to enable audit logs on the AD FS container because for some reason we can't find it (even enabling View > Advanced features in ADUC) - maybe this is the problem? We specified the FQDNs of the domain controllers on the two sensors, in the cloud console After looking at the logs (Microsoft.Tri.Sensor.log), it seems that there is some issue indeed, since for every authentication we get the following two Warning messages: Warn EventActivityEntityResolver ResolveLogonEventAsync logonEvent detected [...] Warn EventActivityEntityResolver ResolveLogonEventAsync logonEvent failed to resolve source computer [...] We cannot see more descriptive errors in the logs. Did anyone have this issue? How is it possible that we don't have the ADFS container in AD?
Question regarding Brute Force (NTLM/Kerberos/LDAP) and Account Enumeration
Hi everyone, The alerts we get the most from our customers are related to MDI. "Suspected Brute Force Attack (NTLM/Kerberos) or (LDAP)" "Account Enumeration Reconnaissance" Often, the alerts provide useful information, such as which computer initiated the attempts and which computers were targeted, along with details on the users involved and whether the logins were successful. However, they rarely explain the root cause of why these alerts are triggered or who the actor is. (e.g., "An actor on a computer performed...") Scenario: Many of our Brute Force/Enumeration alerts come from internal endpoints attempting to access or enumerate other internal endpoints. When I check the most recent users and endpoints involved, I don’t find any malicious activity (the investigation and risk scores are low). This often leads me to believe that an application or misconfiguration may be causing these alerts. Does MDE provide visibility to help identify which application or misconfiguration is triggering these alerts? I have only ever been able to successfully zero in on a application that caused the brute force attack using KQL. Unfortunately, most times I'm left scratching my head. When we discuss this with customers they aren't always sure, but they guess it could be their VPN or some other app. Any thoughts or suggestion would be appreciated.
MDI - licensing for multiple isolated AD forests
Hi, We have the following setup: 400 humans standard AD domain in a single forest (sync'ed via AADConnect to the Entra tenant) 500 AD accounts (user accounts + service accounts), 450 synced to Entra ID (some on-prem service accounts are not synced), 400 accounts with M365 E5 licenses (RBAC accounts do not get any licenses), MDI sensors installed 3 separate dev/UAT/prod AD domains (each in a separate forest, no trusts, isolated): 20 accounts, 300 accounts, 500 accounts (prod AD has many accounts for external clients/consultants/etc). accounts not synchronized to anywhere we want to start using MS Defender for Identity for these domains to sync to the existing MDI workspace. 1. Are these 400 M365 E5 licenses enough for the whole environment (1+3 AD domains) ? 2. If not, what is the final count of licenses needed? 3. how many licenses need to be bought and of which SKU?Detecting service account provisioning
Hi all I'm doing some research around the creation and enabling of old fashioned service accounts using MS Defender. I'm trying to achieve of coupe of things actually. I can detect LogonType of Service Service on MDE onboarded machines using the DeviceLogonEvents Table. But there are a few other things I would like to achieve 1.) Raise an alert when a domain account is granted the "Logon as a Service" right on any machine. 2.) When an account that has never logged on as service suddenly does so. 3.) Perhaps detect when a user account's ServicePrincipalName attribute is populayed or updated. So the service account logon query looks like this: DeviceLogonEvents | where Timestamp >= ago(30d) | where LogonType == "Service" or LogonType == "Batch" | where AccountDomain =~ "saica" | summarize count() by AccountName, DeviceName, LogonType | sort by count_ desc The other ones seem to be a bit trickier. Anyone got any ideas? I would rather not install the MMA agent every and ingest security event logs.
