Step-by-Step: Deploy Microsoft Defender for Identity – Comprehensive Guide

Updated – 16/08/2023 – Microsoft Defender for Identity team released Active Directory Certificate Services (AD CS) sensor. AD CS is a Windows Server role that issues and manages public key infrastructure (PKI) certificates in secure communication and authentication protocols.

In today’s digital landscape, securing sensitive data and maintaining a robust cybersecurity posture is paramount. Microsoft Defender for Identity (MDI) is a cutting-edge solution that offers advanced threat protection by leveraging cloud intelligence and behavioral analytics.

This guide is your go-to resource for understanding the deployment process of Microsoft Defender for Identity (MDI). Whether you’re a seasoned IT professional or a newcomer to cybersecurity, this article will provide you with actionable insights to safeguard your organization’s digital assets effectively.

Introduction

Within the realm of enterprise IT, on-premises Active Directory (AD) remains extensively utilized. As Microsoft’s attention and priorities pivot towards Azure, Microsoft Entra, Microsoft 365, and cloud-based services, on-premises AD has experienced limited advancements over the past decade, though it continues to receive support!

The current trajectory leans towards adopting Microsoft Entra ID (formerly Azure AD), Microsoft Intune, and similar cloud-based services. However, a substantial number of organizations, especially those with large operations or complex infrastructures, will persist in a hybrid condition. This entails the continued deployment of synchronized on-premises AD in conjunction with Microsoft Entra ID (formerly Azure AD) for a considerable duration.

A while ago, we wrote a step-by-step guide on how to install and evaluate Microsoft Advanced Threat Analytics (ATA). Advanced Threat Analytics (ATA) is an on-premises platform that helps protect your enterprise from multiple types of advanced targeted cyber attacks and insider threats.

ATA was discontinued by Microsoft and was replaced with Microsoft Defender for Identity service. The mainstream support of Microsoft Advanced Threat Analytics (ATA) was ended on January 12, 2021, and the extended support will be continued until January 13, 2026. For more information, check the announcement end of mainstream support for Advanced Threat Analytics.

ATA is a standalone on-premises solution with multiple components, such as the ATA Center that requires dedicated hardware on-premises. However, Defender for Identity (MDI) is a cloud-based security solution that uses your on-premises Active Directory signals. MDI solution is highly scalable and is frequently updated.

If you still have Advanced Threat Analytics (ATA) running in your environment, please check the migration guide to move an existing ATA installation to the Microsoft Defender for Identity service.

In this guide, we will focus on how to deploy Microsoft Defender for Identity in your enterprise.

Microsoft Defender for Identity Overview

As previously stated, MDI functions as a security feature based in the cloud, utilizing indicators like event IDs, network traffic, and event trace logs (ETLs) from your on-premises Active Directory (AD) to identify, detect, and explore potential threats within your environment.

MDI’s purpose is to safeguard hybrid identities for businesses and represents a progression from Advanced Threat Analytics (ATA). Unlike ATA, MDI is primarily a cloud-oriented service, streamlining much of the administrative burden related to infrastructure requirements.

MDI plays a pivotal role in identifying prevalent attack patterns to preempt a worst-case scenario, including the following:

• Reconnaissance: Recognizing potential risks from insiders and malicious entities attempting to gather information.
• Compromised credentials: Detecting efforts to illicitly obtain user credentials, often via methods like brute force attacks.
• Lateral movements: Detecting attempts to perform lateral movement within the AD environment, often aiming for escalated privileges.
• Domain dominance: Alerting when indicators signal that an adversary has taken control of your on-premises domain, as evidenced by actions like remote code execution on the domain controller.

You can have only one instance of MDI in your Microsoft 365 / Microsoft Entra Tenant with support for multiple Active Directory (AD) forests. This involves the deployment of sensors on all domain controllers, Active Directory Certificate Services (AD CS), and Active Directory Federation Services (AD FS) servers. The sensor installation package is the same for Domain Controllers, AD FS, and AD CS.

These sensors are responsible for transmitting telemetry data to the MDI cloud service. The collected information encompasses various data sources, including Windows event logs (including Event Tracing for Windows), network traffic, and AD object modifications and activities like authentication. The scope of identity protection can also be extended to Virtual Private Network (VPN) systems through the forwarding of RADIUS accounting events.

The cloud service that receives MDI signals seamlessly integrates with the Microsoft Intelligence Security Graph (MISG). This integration taps into Microsoft’s extensive suite of telemetry collection services, enabling the use of big data and machine learning to detect and analyze threats. The cloud service processes the received events and presents them to security administrators through the Microsoft 365 Defender portal. Events can either be isolated individually or grouped into larger incidents.

MDI’s ability to identify unusual behavior has been enhanced through the implementation of sensitive account tagging and the utilization of honeytokens. Honeytokens are essentially decoy AD users or computer objects created to attract potential attackers. Any attempt to sign in using a honeytoken triggers an alert that requires investigation. Similarly, sensitive accounts, often linked to highly privileged groups like Domain Admins, can be automatically tagged or manually configured for heightened alert priority.

Additionally, MDI can uncover lateral movement paths (LMPs) that highlight potentially concerning users and the associated paths that could lead to compromising their accounts. This information is presented in an intuitive visual interface that aids in reviewing potential attack scenarios, such as pass-the-hash attacks. One of MDI’s crucial features is its capability to query local administrators of domain devices using Security Account Manager Remote (SAM-R), enabling proactive defense against this specific attack vector.

Until 2022, MDI primarily provided administrators with details of suspicious activities, leaving them to manage any compromises independently. This paradigm shifted with the recent introduction of action accounts. These service accounts allow for automated responses, such as deactivating compromised accounts, modifying group memberships, and resetting passwords, triggered by specific types of alerts.

MDI Sensor for Active Directory Certificate Services

As of August 2023, Microsoft Defender for Identity (MDI) team introduced a new sensor type for Active Directory Certificate Services (AD CS). AD CS is a Windows Server role that issues and manages public key infrastructure (PKI) certificates in secure communication and authentication protocols.

AD CS can be part of a domain controller, in which case, no extra actions are needed. If the AD CS is part of a domain controller, as a module on the domain controller server, the sensor type is shown as a “Domain Controller Sensor” as shown in the screenshot below.

However, if your AD CS role is deployed on its dedicated server, then you must make sure that events are being collected from that server as well (see deploying Microsoft Defender for Identity section). The sensor type will be shown as an “AD CS Sensor” instead. If the AD CS role is deployed on a dedicated server, then make sure to add its computer object (account) to the gMSA AD security group (more on this in this section), otherwise, the MDI sensor service won’t start.

Together with the new MDI sensor type, Defender for Identity also now provides related AD CS alerts and Secure Score reports including:

• Domain-controller certificate issuance for a non-DC – also known as ESC8, an attacker can relay NTLM authentication to ADCS, issuing a certificate for the impersonated entity. When the victim of such an attack is a Domain Controller, this can result in full domain compromise.

• Suspicious disable of audit logs of AD CS – Attackers will often disable the logs so that they can perform malicious actions without leaving any trace of their activities. Defender for Identity will now track the audit configurations and alert you when that change has been made.

• Suspicious deletion of the certificate database – Attackers will often delete certificate requests to cover their tracks. This new detection will monitor that activity by tracking when and by whom those requests are deleted.

• Suspicious modifications to the AD CS settings – This event suggests that a change was made to the access control list (ACL) of the certification authority itself. This allows attackers to perform certificate authority-level operations that potentially can lead to domain takeover.

The MDI team is working on new detections and security recommendations around AD CS coming over the next few weeks. The installation of the MDI sensor on the AD CS server follows the same steps as described below when installing on Domain Controllers.

Prerequisites

You now understand that MDI is deployed to your on-premises AD domain to defend the hybrid identity infrastructure. Defender for Identity is composed of the Defender for Identity cloud service, the Microsoft 365 Defender portal, and the Defender for Identity sensor.

To follow this article, you need to have the following:

1) Tenant – Microsoft 365 / Microsoft Entra (formerly Azure AD) Tenant. If you don’t have a tenant yet, you can create a free one here.

2) Permissions:

• To create your Defender for Identity instance, you’ll need a Microsoft Entra ID (formerly Azure AD) tenant with at least one global/security administrator.
• You need to be a global administrator or security administrator on the tenant to access the Identity section on the Microsoft 365 Defender portal and be able to create the workspace. We strongly recommend using the Security Admin role and NOT the Global Admin. Please check the types of Defender for Identity security groups.
• Please note that any global administrator or security administrator on the tenant is automatically a Defender for Identity administrator.

3) Active Directory (AD) – One or more AD domain controllers deployed on-premises or as an Azure IaaS VM:

• Suppose you still have Windows Server 2012 and 2012 R2. In that case, you should plan to upgrade those servers as Microsoft will no longer support the Defender for Identity sensor on devices running Windows Server 2012 and Windows Server 2012 R2.
• MDI sensors installed on Windows Server 2019 without the following update (KB4487044) will be automatically stopped.
• The domain controller can be a read-only domain controller (RODC).
• The Defender for Identity sensor requires a minimum of 2 cores, 6 GB of RAM, and 10 GB disk space installed on the domain controller. When running as a virtual machine, all memory is required to be allocated to the virtual machine at all times.
• For optimal performance, set the Power Option of the machine running the Defender for Identity sensor to High Performance by running the following command.

POWERCFG.EXE /S SCHEME_MIN

4) Directory Service Account (DSA) – When creating the DSA, you have three options:

• Group Managed Service Account (gMSA) (recommended) – This is the recommended DSA option due to its more secure deployment and management of passwords. You need at least one Directory Service account with read access to all objects in the monitored domains (more on this later).
• A regular user account in Active Directory – This option is easy to get started with but requires additional management overhead of passwords.
• Local service account – This option is used out-of-the-box and deployed by default with the sensor, no additional configuration steps are required. This option has limitations such as no support for SAM-R queries and multi-forest scenarios.

5) Licensing – Microsoft Defender for Identity is available as part of Enterprise Mobility + Security 5 suite (EMS E5), and as a standalone license. You can acquire a license directly from the Microsoft 365 portal or through the Cloud Solution Partner (CSP) licensing model.

6) Internet connectivity – Defender for Identity sensors must be able to connect to the Internet, but please do NOT put or open domain controllers to the public Internet, many domain controllers are completely restricted from the Internet. It’s strongly recommended to use a proxy server instead of allowing direct outbound connectivity to the Internet through port 443, and then allow the Defender for Identity sensors to access through that proxy only your dedicated Defender for Identity Cloud Service.

• Ensure your network appliances and firewalls strictly limit and control any traffic you need to open following the official Defender for Identity firewall requirements.

7) Download the Defender for Identity Sizing Tool – The recommended and simplest way to determine the capacity of your Defender for Identity deployment is to use the Defender for Identity Sizing Tool.

Assuming you have all the prerequisites in place, take the following steps:

Deploying Microsoft Defender for Identity

Microsoft Defender for Identity (MDI) relies on specific audit event log entries to provide detections and add additional information on what or who performed those actions on your AD Domain Services (AD DS), Active Directory Certificate Services (AD CS), or AD Federation Services (AD FS) infrastructure.

The following relevant Windows events need to be configured in the Advanced Audit Policy on each AD DS, AD CS, or AD FS server:

For Active Directory Federation Services (AD FS) events

• 1202 – The Federation Service validated a new credential
• 1203 – The Federation Service failed to validate a new credential
• 4624 – An account was successfully logged on
• 4625 – An account failed to log on

For Active Directory Certificate Services (AD CS) events

• 4870: Certificate Services revoked a certificate
• 4882: The security permissions for Certificate Services changed
• 4885: The audit filter for Certificate Services changed
• 4887: Certificate Services approved a certificate request and issued a certificate
• 4888: Certificate Services denied a certificate request
• 4890: The certificate manager settings for Certificate Services changed
• 4896: One or more rows have been deleted from the certificate database

For other events

• 1644 – LDAP search
• 4662 – An operation was performed on an object
• 4726 – User Account Deleted
• 4728 – Member Added to Global Security Group
• 4729 – Member Removed from Global Security Group
• 4730 – Global Security Group Deleted
• 4732 – Member Added to Local Security Group
• 4733 – Member Removed from Local Security Group
• 4741 – Computer Account Added
• 4743 – Computer Account Deleted
• 4753 – Global Distribution Group Deleted
• 4756 – Member Added to Universal Security Group
• 4757 – Member Removed from Universal Security Group
• 4758 – Universal Security Group Deleted
• 4763 – Universal Distribution Group Deleted
• 4776 – Domain Controller Attempted to Validate Credentials for an Account (NTLM)
• 5136 – A directory service object was modified
• 7045 – New Service Installed
• 8004 – NTLM Authentication

The Advanced Audit Policy can be configured in several ways: locally on each domain controller, which is not recommended; or by creating a brand-new Group Policy Object (GPO), and linking the GPO to the domain controller’s Organizational Unit (OU). As a best practice, do NOT edit the Default Domain Controller Policy.

Enabling Advanced Audit Policy

To create a new group policy for MDI, perform the following steps:

1) On your domain controller (or on your management server), open the Group Policy Management console.

2) Expand the domain you are managing and expand the Domain Controllers OU.

3) Right-click on the Domain Controllers container and select the menu item called Create a GPO in this domain, and Link it here… as shown in the figure below:

4) Enter a descriptive name for the new GPO. In this example, we will use Defender for Identity Audit Event.

5) Next, right-click on the newly created GPO and select Edit… to edit the settings of this GPO.

6) In the Group Policy Management Editor window, expand Computer Configuration | Windows Settings | Security Settings | Advanced Audit Policy Configuration.  Make sure to configure the following policies to audit both Success and Failure.

The following table shows which audit policy triggers which event ID.

Audit Policy	Subcategory	Triggers event IDs
Account Logon	Audit Credential Validation	4776
Account Management	Audit Computer Account Management	4741, 4743
Account Management	Audit Distribution Group Management	4753, 4763
Account Management	Audit Security Group Management	4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758
Account Management	Audit User Group Management	4726
DS Access	Audit Directory Service Access	4662 + Configure object auditing (more on this in Step 8)
DS Access	Audit Directory Service Changes	5136
System	Audit Security System Extension	7045

7) To audit Event ID 8004 (NTLM Authentication), you need to edit the settings under Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options and set the following settings for three NTLM security policies accordingly:

• Network security: Restrict NTLM: Audit Incoming NTLM Traffic – Value: Enable auditing for all accounts
• Network security: Restrict NTLM: Audit NTLM authentication in this domain – Value: Enable all
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers – Value: Audit all

8) To collect Event ID 4662, it’s also necessary to configure object auditing on the User, group, and computer objects. The following steps will enable auditing on all users, groups, and computers in the Active Directory domain.

9) To perform this, open Active Directory Users and Computers and select the domain you want to audit, and then select the View menu and select Advanced Features.

10) Right-click the desired container or the root domain name, and select Properties to obtain the domain Properties menu as shown in the figure below, then go to the Security tab, select Everyone, and then click on Advanced.

11) Under the Advanced Security Settings for Domain, Group, Computer, or User accounts, open the Auditing tab and select Add.

12) Then click on Select a principal, and under Enter the object name to select, enter Everyone. Then select Check Names and click on OK.

13) You’ll then return to Auditing Entry. Then make the following selections:

• For Type select Success.
• For Applies to, select Descendant User objects (last item in the drop-down menu).
• Under Permissions, scroll down to the bottom and select the Clear All button.

14) Then scroll back up and select Full Control. You’ll see that all the permissions will be selected. Then uncheck the List contents, Read all properties, and Read permissions. Select OK. This will set all the Properties settings to Write. Now when triggered, all relevant changes to directory services will appear as 4662 events.

15) Last, repeat steps 11-14, but under Applies to, select the following object types:

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

Please note that assigning the auditing permissions on the ‘All descendant objects‘ would work as well, but MDI requires only the object types as detailed above.

Now that your domain controllers can generate the event IDs required to fully implement MDI, next, we will create the Directory Service account (DSA) for the MDI sensors, and then create an action account to be used during an attack disruption.

See Also: Configure auditing for Active Directory Certificate Services (AD CS) using Group Policy.

Create group Managed Service Accounts

The Directory Service Account (DSA) should have read-only permissions on all objects in AD, including the Deleted Objects container. MDI has support for group Managed Service Accounts (gMSAs), and in this section, we will use a gMSA for our MDI installation. While a standard AD account is supported, we strongly recommend gMSA for its additional security benefits, such as AD-managed password rotation.

As a side note, Domain Controllers require a root key to begin generating gMSA passwords. The KDC root key creation requires domain admin or enterprise admin rights. Before creating a root key, you can check if one exists in your environment by running the Get-KdsRootKey PowerShell command.

To create the DSA gMSA, run the following Microsoft-provided PowerShell commands as an administrator. In this example, we are adding a KDC root key, creating a group, and then adding domain controllers; you may want to add ADFS servers and use existing groups instead:

# Set Variables
$gMSA_AccountName = "svc_mdiGMSA" # INSERT PREFERRED NAME FOR GMSA
$gMSA_HostsGroupName = "gMSAGroup" # INSERT GROUP NAME TO ADD SERVERS TO
$gMSA_HostNames = "DC01" #, "DC02", "ADCS01", "ADCS02", "ADFS01", "ADFS02"

# Import Active Directory PowerShell module
Import-Module ActiveDirectory -Verbose

# Create the group and add the members
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru

$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
    ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }

# Add Key Distribution Service (KDS) before start adding new group Managed Service Accounts
# If you have only one DC, then use this command to create the KDS root key and set start time in the past
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
# If you have multiple DCs, then use the command below to replicate immediately
Add-KdsRootKey -EffectiveImmediately

# Create gMSA
New-ADServiceAccount -Name $gMSA_AccountName `
 -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
 -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

To confirm the creation of the gMSA account, open PowerShell and run this command:

# "svc_mdiGMSA" is the name of the gMSA account
Get-ADServiceAccount -Identity svc_mdiGMSA

You can also run the following PowerShell command to verify which AD group or computer objects are defined in the PrincipalsAllowedToRetrieveManagedPassword attribute:

 Get-ADServiceAccount $gMSA_AccountName -Properties * `
   | FL KerberosEncryptionType, Name, PrincipalsAllowedToRetrieveManagedPassword, SamAccountName

Install the gMSA account on each DC

After creating the gMSA account we need to install it on each Domain Controller. To install the gMSA, you need to sign in locally on each of the DC servers and run the following PowerShell commands as an administrator:

# Import Active Directory PowerShell module
Import-Module ActiveDirectory

# Install the gMSA account, svc_mdiGMSA is the name of the gMSA account
Install-ADServiceAccount -Identity svc_mdiGMSA

Once you run the command above, you need to wait 10 hours for the DC to request a new Kerberos ticket and registered its group membership. If you do not want to wait, you can restart the DC or purge the KDC cache by running the following commands:

# Clear KDC Cache on each DC
$gMSA_HostNames = "DC01" #, "DC02", "DC03", "DC04", "ADFS01", "ADFS02"
Invoke-Command -ComputerName $gMSA_HostNames -ScriptBlock {
    klist purge -li 0x3e7
}

Last, to verify the successful installation of the gMSA account and that the DC server has the required permissions to retrieve the gMSA’s password, you can run the following command:

# svc_mdiGMSA is the name of the gMSA account
Test-ADServiceAccount -Identity svc_mdiGMSA

// IMP: Make sure to assign both the DSA and action account gMSA the “Logon as a service” permission on all domain controllers that run the Defender for Identity sensor. You can do that using the existing Group Policy Management that we created earlier.

Now that the DSA gMSA is installed, let’s move on to create the action account gMSA.

Create an action account

Attack disruption refers to how Microsoft 365 Defender effectively halts potential attacks that it detects. In the context of MDI, this would be actions such as disabling user accounts or resetting passwords. To perform these actions, you need to provision another gMSA with the appropriate permissions. This gMSA will replace MDI’s out-the-box use of the domain controller’s LocalSystem account.

Please note that multiple action accounts are supported, but for this example, we will create only one. You may want to consider additional gMSA accounts to have different scoped levels of permission, such as resetting passwords and disabling AD users.

1) First, you need to provision the gMSA using the command below, make sure to replace the account name, DNS hostname, and host group as required to match your environment.

# Set Variables
$gMSA_AccountName = "gMSA-MDI-Action" # INSERT PREFERRED NAME
$gMSA_HostsGroupName = "gMSAGroup" # INSERT gMSA HOST GROUP NAME

# Create gMSA for MDI Action
New-ADServiceAccount $gMSA_AccountName `
 -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
 -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

2) Next, go to Active Directory Users and Computers and open the Properties menu of the domain or individual OU.

3) In the Domain Properties menu, head to Security | Advanced. Then on the Permissions tab, select Add | Select a principal.

4) Click the Object Types button and ensure Service Accounts is selected, then return to choose your action account gMSA that you created in step 1 above.

5) When you return to the Permission Entry window, verify the Type option is set to Allow and Applies to is set to Descendant User objects (last item in the drop-down menu).

6) Under Permissions, scroll down to the bottom and select the Clear All button.

7) Then select the checkboxes for the below five permissions only and select OK. You may need to scroll up/down quite a lot of options, as shown in the figure below.

• Reset password
• Read pwdLastSet
• Write pwdLastSet
• Read userAccountControl
• Write userAccountControl

8) Last, you need to repeat steps 3-7 to add another Descendant Group objects permission entry with permissions set to Read members and Write members under the Properties section.

// IMP: Make sure to assign both the DSA and action account gMSA the “Logon as a service” permission on all domain controllers that runs the Defender for Identity sensor. You can do that using the existing Group Policy Management that we created earlier.

Now that you have both the DSA and action account gMSA accounts created in your domain. There are some more configurations we need to perform before they’ll be ready to use, and this is where Security Account Manager Remote (SAM-R) comes into play.

Enable Security Account Manager Remote

As mentioned earlier, MDI can identify lateral movements by attackers. This is achieved by the Security Account Manager Remote (SAM-R) protocol, and group policy configuration is required to allow this for all computers in your domain apart from domain controllers.

We can configure SAM-R to enable lateral movement path detection in MDI by using a new or existing Group Policy Management that you have in your environment (do NOT use the previous GPO that is assigned to domain controllers, this new GPO should be assigned to all computers other than domain controllers).

Take the following steps:

1) In the Group Policy Management Editor, navigate through Computer Configuration | Policies | Windows Settings | Security Settings| Local Policies| Security Options.

2) Then look and open the Network access: Restrict clients allowed to make remote calls to the SAM setting as shown in the figure below.

3) Click the Edit Security… button and add the Directory Service Account (DSA) gMSA service account you created earlier with Remote Access set to Allow.

4) Last, proceed to assign this new GPO to all computers except domain controllers.

Now that you’re good to go with SAM-R, let’s jump into Microsoft 365 Defender to perform some configuration before installing the MDI sensor(s).

Create MDI Workspace in Microsoft 365 Defender

In the Microsoft 365 Defender portal (security.microsoft.com), we first need to set up the MDI workspace to be able to download the sensor and add our gMSA for the MDI configuration. To complete this step, you require the permissions of at least the Security Administrator role (Use always least privileged accounts).

To create the MDI workspace, take the following steps:

1) In the Microsoft 365 Defender portal, as a Security Administrator or Global Administrator, then navigate to Settings | Identities. Allow Microsoft 365 Defender (60 seconds) for the workspace to provision successfully.

2) Next, we will add both the Directory Service Account (DSA) and action gMSA service accounts that we provisioned earlier.

3) Go to Settings | Identities | Directory service accounts | + Add credentials as shown in the figure below. In the pop-out blade, ensure that the Group managed service account is checked, and then enter the account and domain name of your DSA, then click Save.

4) Next, jump to the Manage action accounts blade under (Directory service accounts ) and choose + Add credentials, then repeat what you did in the last step, but this time for the action account gMSA.

Moving now to the final step of installing Microsoft Defender for Identity (MDI) sensor(s) on domain controllers.

Download and Install the MDI Sensor

In the previous steps, we covered all the necessary configurations to install the MDI sensor, it’s now time to install it. To do this, you need to perform the following steps on each domain controller in your environment:

1) First, you need to verify that the domain controller has connectivity to relevant MDI endpoints by using the official steps as described on this web page.

2) We will use Powershell to validate access to the instance URL. For the commercial cloud, use https://*your-instance-name*sensorapi.atp.azure.com and for Government Community Cloud (GCC), use https://*your-instance-name*sensorapi.gcc.atp.azure.com. To do that, we will need to get the MDI workspace name.

3) Open the Microsoft 365 Defender portal at security.microsoft.com, then go to Settings | Identities, under General click on About, and then copy the Workspace Name. In this example, the Workspace Name is mdich.

4) As we know, it’s not a best practice to browse on domain controllers, we will use the following PowerShell command to verify that the machine has connectivity to the MDI instance. On your domain controller, run the following command. Make sure to replace the workspace name before *sensorapi.atp.azure.com or *sensorapi.gcc.atp.azure.com to match your environment.

$HTTP_Request = [System.Net.WebRequest]::Create('https://mdichsensorapi.atp.azure.com')
$HTTP_Request.GetResponse()

Please note that you should get an Error (503) Server Unavailable, which indicates you were successfully able to route to the Defender for Identity HTTPS endpoint. This is the desired result. If you don’t get Error (503) Server Unavailable, then you may have a problem with your proxy configuration. Check your network firewall and proxy settings. And if you get a certificate error, then ensure that you have the required trusted root certificates installed before you continue.

5) Next, switch to the Microsoft 365 Defender portal and go to Settings | Identities | Sensors page, then click on + Add Sensor to open the dialog box to download your first MDI sensor.

6) In the Add a new sensor dialog box, click on Download installer, and make sure to securely note the Access key value, as this is needed to install the sensor on your domain controllers. Please note that regenerating the access key will not affect any sensors that are already installed and operational.

In this example, we blurred the Access key in the image below for obvious reasons. The name of the installer file is Azure ATP Sensor Setup.zip.

7) Extract the installation files downloaded in step 6 locally on your workstation, and then copy the installer (Azure ATP Sensor Setup) to your domain controller. The Azure ATP Sensor Setup.zip installer file includes the following files.

8) In this example, we are running the domain controller on Windows Server Core, we will run the following PowerShell command to install the MDI sensor silently. This is especially useful if you have a large domain controller estate and want to automate this process.

The same PowerShell command will work on Windows Server with Desktop Experience as well. You can remove the /quiet switch if you want to perform an interactive installation of the MDI sensor. Please make sure to replace the access key as appropriate:

.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="AccessKey"

This command will install the sensor service, the sensor updater service, Npcap OEM, and the Microsoft Visual C++ 2012 (x64) Redistributable.

9) The installation wizard will auto-detect whether the server is a domain controller, ADFS server, or dedicated server. If you are installing this on a non-domain controller, the sensor will be installed as a Standalone Sensor and not a Sensor, which would be the case if the server is a dedicated server, and this requires configuration of port-mirroring from the domain controllers to receive network traffic.

Note: As a best practice, it’s recommended to install the MDI sensor on a dedicated machine and not on the Domain Controller (DC), after you configure the port mirroring to forward the network traffic from the DC to this machine which is a member of the domain. Learn how to configure port (traffic) mirroring with a Hyper-V vSwitch.

10) If your domain controllers are accessing the Internet using a proxy, then you’ll need the following PowerShell command to provide this information. Please make sure to replace the access key, proxy URL, and credentials as appropriate:

.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" `
 AccessKey="AccessKey" ProxyUrl="http://proxy.yourdomain.com:portnumber `
 ProxyUserName=domain\myaccount ProxyUserPassword=MySuperSecurePW

11) You can confirm that MDI (Azure Advanced Threat Protection Sensors) services are running on your domain controller(s) by running the following PowerShell command:

Get-Service -Name AATP* | FT -AutoSize

12) At the time of this writing, the MDI sensor is at Version 2.210.16929.27360.

13) Last, navigate to the Microsoft 365 Defender portal and confirm the health of the sensor under General | Sensors. Check the Service status and the Health status.

If the status is not healthy, then make sure you set the Power Option on the DC to High Performance, and check if NTLM auditing is enabled as described in the “Enabling Advanced Audit Policy” section.

Attack Simulations for MDI

Microsoft Defender for Identity is a powerful solution for detecting abnormal or suspicious activities from managed, unmanaged, or even unknown machines targeting domain controllers.

Let’s validate that Defender for Identity is working correctly in the environment by simulating a couple of attacks using the official attack simulations published by Microsoft.

First, you need to download PSExec.exe from Sysinternals tools.

Remote code execution attempts

Defender for Identity identifies instances of PSexec, Remote WMI, and PowerShell connections originating from a client machine and directed towards a domain controller.

Open a command line on a workstation, and then run the following command with a domain admin account (replace DC01 with your domain controller):

PsExec.exe -s -i \\dc01 powershell.exe #To get a PowerShell session on a DC

This command will start and open a PowerShell session on the domain controller.

Next, switch to the Microsoft 365 Defender portal | Incidents & Alerts | Alerts. After a short period, you will see a similar alert as shown in the figure below (Remote code execution attempt).

Data exfiltration over SMB

The next attack simulation that we need to perform, is Data exfiltration over SMB (external ID 2030).

Again, open a command line on a workstation, and then run the following commands with a domain admin account (replace DC01 with your domain controller):

PsExec.exe -s -i \\DC01 cmd.exe #To get a cmd session on a DC

#To get a local copy of the locked ntds.dit file
Esentutl /y /i /vss c:\windows\ntds\ntds.dit /d c:\windows\ntds.dit

Then copy the ntds.dit file out from your DC (c:\windows\ntds.dit) to a workstation with a shared folder:

#To get a copy of the ntds.dit file from the DC to your workstation
Esentutl /y /i /vss c:\temp\ntds.dit /d \\workstation\share\ntds.dit /o

After a couple of minutes, the following alert will trigger when suspicious transfers of data are observed from your monitored domain controllers, such as when an attacker copies the ntds.dit file from a DC to a workstation.

These are just a few of the attacks that you can use to test your environment. Microsoft explains more in-depth attacks that are available as playbooks for Reconnaissance, Lateral movement, and Domain dominance.

That’s it there you have it. Happy Hunting!

Summary

In today’s rapidly evolving digital landscape, deploying Microsoft Defender for Identity is a strategic move to protect your organization’s sensitive data and ensure a robust cybersecurity posture.

In this article, we introduced MDI and understood its nature, explored diverse deployment methods, and ultimately highlighted its critical significance in the current landscape. With the surge of cybercrime and threat actors exploiting vulnerabilities in our identity infrastructure, MDI emerges as a paramount solution in countering these challenges and maintaining the security of your environment.

By following the deployment process outlined in this guide, you’ll be well-equipped to leverage the power of advanced threat detection, behavioral analytics, and cloud intelligence. Remember, cybersecurity is a continuous journey, and staying vigilant is key to safeguarding your organization’s digital assets.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-