A lot of the work I do consists of working in hardened security baselines. In short, that means STIGS are pushed via Group Policy to harden the systems.
The prerequisites are pretty straight forward and have been updated. Please read this thoroughly and for my friends working in US Government, here is your doc. Disclaimer - depending on your govt environment, you may have to allow *atp.azure.us through your proxy instead *.atp.azure.com, just be aware.
Plan for capacity here.
Disclaimer - Huge Kudos to Raymond Roethof and allowing me to drop his link for some tidbits as well. His document here outlines all the auditing steps. Albeit, my article revolves around hardened systems. One awesome tidbit from his is the 4th section, "Object Auditing". This will simplify those GUI steps for you all. Cheers and thanks Raymond.
For the most part STIGs capture the audit settings but MDI does call out a bit more, here. My advise is Do NOT edit default GPOs, whether that be Default Domain Controllers of the Default Domain. For each OS flavor you should be following its own hardened baseline, same holds true for a Domain Controller - use dedicated GPOs. The "Configure Windows Event Collection", site is a bit misleading so I broke it down for you. When you go to edit, DO NOT forget to edit each for success and failures.
Domain Controllers - Use STIG baseline and follow doc.
- On Domain Controllers ONLY - Configure your hardened baseline GPO for EventID 8004, here.
- Additional Configuration for LDAP Search Event ID 1644, here. What is Event ID 1644? See here. Disclaimer - I would add this registry setting to the OS based hardened GPO so that it gets added to ALL Domain Controllers. See image below.
ADFS - Use STIG baseline, ADFS auditing and follow ADFS events. Lastly, Enable auditing on an ADFS Object.
OS flavors and Tiered structures - Use STIG baseline and follow other events.
Configure Object Auditing - this needs to be completed for 4662 events. Disclaimer - follow these steps closely. One tidbit too, on the first step, the instructions are clear. When it says 'Clear All', then add full control and so on. It will look like under 'Properties', that it is empty. Click 'OK' and apply. Go back into the current setting you just set and it will be made clear to you that 'WRITE' permissions are now there. Just wanted to clear that confusion up. Repeat the SAME steps for all 3 Audit entries.
The recommendation here is to use a gMSA account. Lets dig into creating that.
If your domain is NOT using gmsa (Group Managed Service Accounts), you need to Create the Key Distribution Services KDS Root Key seen. More info here. This is a prerequisite for using gMSA. If you are using gMSA, skip this step.
Domain Group - Create. Create an Active Directory Security Group and make the MDI member servers members of the group. I created a group called 'MDIGroup'. Why do we do this? If you are planning on protecting Domain Controllers and ADFS Servers with MDI, they need to be members of the same group to allow -PrincipalsAllowedToRetrieveManagedPassword.
Copy the contents of the script to the first DC you are installing MDI on. Disclaimer - you may or may not need to use the -KerberosEncryptionType flag but if you are using 2016+ Domain Controller STIGyou will have to on OS 2016-2022.
Install-WindowsFeature -Name RSAT-AD-PowerShell //This is already installed if you are on a Domain Controller
Run this script
# Filename: MDIgMSA.ps1
# Description: Creates and installs a custom gMSA account for use with Microsoft Defender for Identity.
#
# Declare variables
$Name = 'MDIgMSA' #The name of the gMSA to be created
$Description = "MDI group managed service account for MDI"
$DNS = "MDIgMSA.cyberlorians.net" #This is the gmsa dns hostname
$Principal = Get-ADGroup 'MDIGroup' #AD group created in the DC step, comment out if using 'Domain Controllers' only and uncomment next step.
#$Principal = Get-ADGroup 'Domain Controllers' #Uncomment if just using DomainControllers and comment out the previous step
$Kerb = 'AES128,AES256' #If using 2016STIG and above you have to use
# Create service account in Active Directory
$NewGMSAServiceDetails = @{
Name = $Name
Description = $Description
DNSHostName = $DNS
ManagedPasswordIntervalInDays = 30
KerberosEncryptionType = $Kerb
PrincipalsAllowedToRetrieveManagedPassword = $Principal
Enabled = $True
}
New-ADServiceAccount @NewGMSAServiceDetails -PassThru
#Install-ADServiceAccount -Identity 'MDIgMSA'#MSFT Docs call for this piece BUT you do not have to since you will be setting the new gMSA account in a GPO for proper permissions.
Get-ADServiceAccount -Identity 'MDIgMSA' -Properties * | select Prin*
Test-ADServiceAccount -Identity 'MDIgMSA'
!!Verify!! that the newly created gMSA account has the log on as a service permission to all MDI machines. Disclaimer - add this to the Domain Controller OS Based STIG and if using in conjunction with ADFS, then add to the ADFS OS Based STIG as well. I cannot stress how important this step is. In the past, this step was missing from current docs and I am happing that it has been added but it is still an easy oversight. If this is NOT in place, nothing will work!
Your last step in the gMSA ladder is to Configure the gMSA in 365 Defender. When adding the gMSA account suffix with the $ so it matches the SAMAccountName Attribute on prem in AD.
I am not going to cover this in detail, perhaps another article. However, keep the MDI groups protected, carefully. Use Conditional Access Policy to enforce access to the traditional ATP portal. As well as, use a Privilege Access Group to lock down the groups via nesting. These groups are NOT AAD Roles so you cannot PIM them by default. Just adding food for thought but that is not the intent of this article. More on that later.
This is another DENY to Domain Controllers. On a STIG level, you could add these GPO settings to each OS Based GPO STIG. Or, add a top level down from the root. Read through this page closely as you are going to have to decide how to approach these rights assignments and how GPO precendence could effect them. I.e, if you are following a correct Tiered Model, putting the these SAM-R settings at the root can work. See the DENY below - DENY Read and Apply Group Policy to Domain Controllers.
You are on a roll now. Final steps are below!
-Download the sensor.
-If you are going via a proxy, check the doc here.
-After extracting the contents, install Npcap first - DO NOT MISS THIS STEP!
-Install the sensor, see the Prerequisites. As I stated above, install the Npcap driver first before the sensor install. Or, Pcap will install.
Once installation has completed. Check the MDI portal and see the health of your sensor. If you have followed each step all should be well.
Now go connect MDI/365 to Sentinel and be complete!