The New DefenderForIdentity PowerShell module 1.0.0.0

Microsoft released a new PowerShell module for that assists with configuring and validating your Defender for Identity (MDI) sensor deployments.

What is MDI?

Microsoft Defender for Identity is a cloud-based security solution that helps secure your identity monitoring across your organization.

For organizations who's identity environment spans both on-premises and the cloud, MDI provides an overview of your identity security posture, not just in the cloud, but for your on-premises identity environment as well.

Sensors are installed on your on-prem Domain Controllers (and also, your ADFS and ADCS servers) and monitor traffic identifying suspicious activities using deep packet inspection technology. It is able to detect known malicious attacks and techniques, security issues and risks against your network and sends this data to your MDI cloud service instance and generating alerts that can be investigated by your security teams.

What data does MDI collect?

Your data is isolated from other customers. Information collected includes:

• Network traffic to and from domain controllers, such as Kerberos authentication, NTLM authentication, or DNS queries.
• Security logs, such as Windows security events.
• Active Directory information, such as structure, subnets, or sites.
• Entity information, such as names, email addresses, and phone numbers.

After deploying the MDI sensors to your Domain Controllers, there are some configuration requirements. MDI relies on specific event logs which the sensor parses to enhance detections and so we must configure Advanced Audit Policy settings. Misconfigurations here will generate health alerts in your MDI portal and it is necessary to configure this properly to avoid gaps in the event logs and incomplete MDI coverage.

The new MDI PowerShell Module

The new MDI PowerShell module has a neat cmdlet that generates a report and illustrates which settings are misconfigured in your environment. Microsoft recommends leveraging this module post sensor installation. the New-MDIConfigurationReport cmdlet exports a snazzy HTML report and illustrates your configurations:

New-MDIConfigurationReport -Path "C:\work" -Mode Domain -OpenHtmlReport 
        

• Path specifies the path to save the reports to
• Mode specifies whether you want to use Domain or LocalMachine mode. In Domain mode, the settings are collected from the Group Policy objects. In LocalMachine mode, the settings are collected from the local machine.
• OpenHtmlReport opens the HTML report after the report is generated

Not only does this HTML report identity which configurations require correcting, but the corresponding cmdlets are provided making it extremely easy to remediate the misconfigurations.

In the report, we can see "DomainObjectAuditing" has "failed". Taking a look at the object auditing for my domain, I can see 5 objects configured by default:

Typically, there is a lot of... "clicking" and "checkboxes" to enable all of the objects for auditing but with the new Set-MDIConfiguration cmdlet and the appropriate parameters, I can run a single command and save a lot of time configuring this single configuration. The HTML report shows these commands in the "Command to fix" column in the report:

Set-MDIConfiguration -Mode Domain -Configuration DomainObjectAuditing        

After running the above Set cmdlet, I can now see the additional 5 entries added and all of the correct permissions!

After re-running the New-MDIConfigurationReport cmdlet, I can now see the DomainObjectAuditing configuration has "Passed"!

See the PowerShell gallery link for information on how to install this module here. Also, see the official MDI documentation here.