Microsoft Defender For Identity Article Series: Onboarding MDI Sensor in Windows Server 2019

This tutorial will give you an explanation about how to install Microsoft Defender for Identity. In this article I made my own lab environment using Azure VM with Local AD.

Let me Introduce you Defender for Identity shortly. I quote from the official Microsoft page : MDI is a cloud-based security solution that protect your on-premises Active Directory users and/or users synced to your Azure Active Directory (Azure AD) to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

For more technical explanations you can visit here.

Defender for Identity architecture picture

Pre-Requisites

• Virtual Machine : 1 Server (Windows Server 2019 acts as a domain controller) & 1 Client (Windows 10 with join domains
• License Trial M365 E5
• Minimum 2 core and 6 GB RAM
• Minimum 6 GB Storage
• In AD, at least one Directory Service account with read access to all objects in the monitored domains.
• Global administrator or security administrator on the tenant to access the Identity section on the Microsoft 365 Defender portal
• If you have proxy, you can use this to whitelist
• Few ports opened please check here
• Network Name Resolution must be enabled
• Few Audit Log Configuration Needed
• need to create KDS Rootkey
• need 1 or 2 users AD for testing

Step by step :

1. I assume that your local AD Domain Controller has been installed. Go to the Client PC. Ensure your AD is ready and your computer client connected with domain joined. (In this case I just use 1 DC, if you want to try install MDI Sensor with AD FS it it’s also supported).

at the client computer, nslookup dns server was connected

2. Client PC must connected to your local domain. just search and type “env” > Computer name > Change > Fill your LOCAL AD Domain like picture below.

source : mustbegeek.com

2. Then configure your Windows Policy with this following tutorials https://learn.microsoft.com/en-us/defender-for-identity/configure-windows-event-collection#configure-audit-policies

3. Go to the GPO Policy and edit.

Path : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Edit the GPO

4. You can adjust it yourself depending on your needs. Please enable based on following table below :

Enable Success and Failure audit like the picture below

5. Then config this also at the same GPO. Path : Local Policies > Security Options. Setup based from the table :

Config like this picture below :

6. dont forget to use this command at powershell to force the policy enabled immediately.

gpupdate /force

7. Then Config your Object Auditing based from this tutorial : https://learn.microsoft.com/en-us/defender-for-identity/configure-windows-event-collection#configure-object-auditing

The principal is always everyone like this, then click the Check Names

Principal Everyone

Then OK and Doing the configurations like below.

Object auditing configuration

8. The flow is : Scroll down > Clear All. Click Full Control > Then uncheck :

List contents,

Read permissions,

and Read all properties

9. Do the same things but please change the Applies to :

• Descendant Group Objects
• Descendant Computer Objects
• Descendant msDS-GroupManagedServiceAccount Objects
• Descendant msDS-ManagedServiceAccount Objects

10. Enable Auditing Exchange

Start, select Run, type ADSIEdit.msc > Setting like this tutorial > OK

Enable Auditing Exchange

11. Create KDS RootKey. It must when you want to use gMSA method.

Why I use the command, because in default you must to wait 10 hours. this command can help you saving your time and do it immediately.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)

12. Then create your gMSA Account using powershell:

$gMSA_AccountName = 'mdiSvc01'
$gMSA_HostsGroupName = 'Domain Controllers'

New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

13. validate that the server has the required permissions to retrieve the gMSA’s password, run the following PowerShell command:

Test-ADServiceAccount -Identity 'mdiSvc01'

14. Then Run this :

$Identity = 'CONTOSO\gunawanjeffry'
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName

$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params
$params = @("$deletedObjectsDN", '/G', "$($Identity):LCRP")
C:\Windows\System32\dsacls.exe $params

Get-ADUser -Identity "mdisvc01" -Server "contoso.azure"
Install-ADServiceAccount -Identity 'mdiSvc01'

15. Test your Server is it ready to install the sensor? using this tools : https://github.com/microsoft/Microsoft-Defender-for-Identity/tree/main/Test-MdiReadiness

NB : All Table must Green like below. recheck your requirement if you see the red Color.

Tools Test MDI Readiness

16. Download the sensor from security.microsoft.com. Go to Settings and then Identities > Sensors.

Download the sensor

17. Extract and run as admin.

Run the Sensor

18. Input your access key from Security portal.

Installation Success

19. Fill the same account name from your LOCAL gMSA Account and fill your local domain.

20. The result sensor is healthy.

Healthy Sensor

21. You can adjust as needed the learning period (optional)

Adjust your Learning Period in this sample We turn off the Learning.

If you want to implement the MDI, better you can turn on the learning period. but in my case I just want to know the detection.

22. Run the sample playbook to trigger the alert here (DWYOR) :

Reconnaissance playbook - Microsoft Defender for Identity

you can choose by yourself at the left side :

Choose alert trigger playbook

23. The Detection is appear like this. it came from MDI.

References :

Prerequisites - Microsoft Defender for Identity

https://learn.microsoft.com/en-us/defender-for-identity/playbook-setup-lab