Before deploying Microsoft Defender for Identity (MDI), administrators traditionally have relied on the MDI Test Readiness script to validate domain controller prerequisites. The script is intended to catch configuration issues early, such as missing directory permissions or insufficient system resources, before sensor installation begins. However, a recent update has caused a question to be raised regarding the tool's output. The goal here is to be proactive. Rather than install into production and then realise there are issues, we want to deal with that proactively.
MDI Test Readiness Script
We can use this script prior to deploying MDI, that way we can ensure that the necessary changes have been correctly performed before moving onto the next phase in the deployment.
Download the script from the Microsoft MDI Github.
Once downloaded we can run Test-MdiReadiness.ps1 to query the local environment.
Simple Execution
Running the script with no parameters will check the AD DS auditing, AD FS and Certification Authority audit settings.
The result initially appears to be rather underwhelming – just “False”. That means that not all of the auditing requirements have been met. We need to open up the HTML report file for more information.
This can be done automatically by using the OpenHtmlReport parameter
.\Test-MdiReadiness.ps1 –OpenHtmlReport
Note that the example report below is somewhat colourful. There are multiple issues in this environment. The blatant ones are that the audit configuration is not correct and that one one server does not have the correct Windows Power Plan set (they all should be High Performance). The more subtle issue is that the network capture driver on two of the servers is outdated – WinPcap should not be used at this point.
But for now, let’s focus on the auditing issues.
You can click each of the hyperlinked sections, and that will take you to the relevant documentation so you can double check what was configured.
Verbose Switch
Adding the -verbose switch writes out the names of the tests being performed.
Ideally everyone would run the MDI Test Readiness script, and have a smooth deployment in production. But that does not always happen, or issues arise afterwards due to a change in GPOs etc.
In such cases we can re-run the script, and in addition also review the MDI health issues.
Reactive Remediation
MDI previously added the Health Issues feature so that tenant admins are aware of performance or configuration issues with their MDI sensors. However this requires that the MDI sensor is installed and it would be nice to:
-
-
Have the ability to proactively ensure the configuration is good prior to installing the first sensor
-
-
-
Have more detailed troubleshooting information
-
Examples of issues within the Global Health and Sensor Health areas are shown below. Issues with auditing should appear in the global section.
The sensor health section will typically indicate issues specific to that a given server. In the below example, communication has been lost amongst other issues.
If we look at the details for the alert on Configuration container auditing we do not see exactly what the issue is. Granted this is one of the simpler AD DS auditing things that needs to be set, the guidance does not have to be that detailed as its a simple change to fix.
But the Directory Services auditing is more complicated. What exactly did I do wrong to anger the MDI gods, and what exactly do I need to fix?
Well, the details on the report and also what is contained in the health issue will help out. Time to get that fixed!
Cheers,
Rhoderick
