A few months ago, I wrote a tool to check the Microsoft Defender for Identity Configuration, which you run on a domain controller. Running the tool is a snapshot at that time. What if you want to monitor the configuration using your SOAR solution for misconfigurations? Well, I created a PowerShell script that creates an event in the event viewer which is sent to the cloud to monitor the configuration using your favorite SOAR solution. In this blog post, I will describe how to monitor this using Microsoft Sentinel.
Introduction
I wanted to know how to monitor the Microsoft Defender for Identity configuration twenty-four-seven. Even though the tool I created works fine, it is a snapshot at a particular time. At the time of writing, Microsoft Defender for Identity does not notify you about any misconfigurations, even though enabling auditing is extremely important. No auditing means no detections for specific attacks. For this reason, I came up with a solution to send the Microsoft Defender for Identity configuration to the cloud and make it possible to monitor any misconfigurations using Microsoft Sentinel.
Collect Data using PowerShell
Since Microsoft Defender for Identity does not support sending the configuration to the cloud, I needed a low-cost solution to ingest the data. But first, I needed to collect the data. The solution I came up with is a PowerShell script, as you can run it using a scheduled task, and it is easy to read.
As of the time of writing, the PowerShell script collects all auditing configurations needed for Microsoft Defender for Identity to detect all attacks. I wanted to use as many standard solutions as possible, so I wrote the data to the application log in the event viewer. This way, filtering and ingesting the data to any SOAR solution is easy.
A simple true or false statement indicates any misconfiguration. To continuously monitor the configuration, create a scheduled task that runs the PowerShell script once daily, for example.
Azure Monitor Agent
Now that we have the data in the event viewer, we want the data to ingest into Microsoft Sentinel. Since the Azure Monitor Agent supports custom events, we can “filter” for only certain events sent to the cloud using Azure Collection Rules.
To collect the event from an on-premises server, you must install the Azure Monitor Agent from the Azure Arc blade.
Note: If the server runs in Azure, you only need to add an Azure Collection Rule which I will describe later.
In my case, I am running the server in an on-premises environment, so I installed the Azure Monitor Agent using a script that I downloaded from the Azure Arc blade:
The installation is straightforward. Execute the script to install the agent using PowerShell. The script asks you to authenticate to the correct tenant during the installation:
Once installed, we can create the Azure Collection Rules.
Azure Collection Rules
If we look at the data connectors in Microsoft Sentinel, we see a connector named “Windows Forwarded Events.” Once we open the connector page, we can add a Data Collection Rule:
With “Select a scope,” we can select the servers where we installed the Azure Monitor Agent:
At “Collect,” we select “Custom” and add the following expression:
Now that we have ingested the data into the cloud, the last step is to create an analytics rule in Microsoft Sentinel.
Microsoft Sentinel Alert
After we trigger a new event using the PowerShell script, or the scheduled task in the event viewer, we can check the logs for the result:
Once we have the result, we can create the alert. We can map the hostname using entity mapping to know which host triggered the alert:
The result is an alert in Microsoft Sentinel if Microsoft Defender for Identity is not configured correctly, including the hostname:
The PowerShell script and the Kusto Query is just an example. Feel free to write anything fancier to make it more to your liking.
Conclusion
Maybe, in the future, Microsoft Defender for Identity will send the configuration settings to the cloud, but this is a good solution for now. Especially in an organization with 100+ domain controllers and ESPECIALLY considering how important it is to enable auditing for Microsoft Defender for Identity to detect correctly.
Microsoft Security Blog 