Simplified deployment with Defender for Identity

Introduction

Microsoft Defender for Identity is an essential part of a modern security practice, helping your organization protect against, and respond to, identity-based threats. In this blog we will show you the simple steps for deploying Microsoft Defender for Identity within your environment.

Before we get into the deployment overview however, let’s quickly cover some of the benefits of deploying Defender for Identity:

• Reduce your attack surface - Understand your Identity risk posture to proactively minimize exposure to attacks.
• Detect threats in real time - Be alerted to suspicious activities, compromised identities, and lateral movement throughout your organization.
• Investigate with incident-level visibility - Correlate identity alerts with other data from across Microsoft 365 Defender to give security teams important context into broader incidents when investigating identity threats.
• Respond to threats comprehensively - Take immediate action on a compromised identity or use custom detection rules to automate a response that suits your organization’s needs.

Prepare

Before you get started deploying Defender for Identity, it's important to consider your unique identity footprint and determine the right coverage and protections you need. While this planning is crucial, attackers don't wait so it's imperative that you get started deploying protections for your identities as soon as possible. Do not let planning the optimal scenario delay you from implementing needed protections.

For on-premises identities you will need to start by identifying the identity infrastructure to which a sensor should be deployed, like Domain Controllers, Active Directory Federation Services (AD FS) and Active Directory Certificate Services (AD CS) servers. Once you have an understanding of where sensors should be deployed, review the Defender for Identity prerequisites to ensure you have the correct system requirements, accounts, permissions, and network configuration.

The complete list of pre-requisites can be found here Prerequisites - Microsoft Defender for Identity, but some key minimum requirements for installing the Defender for Identity sensors are:

• Network connectivity – ensure that the servers where the Defender for Identity sensors will be installed can communicate with the Defender for Identity cloud service. Full details on the network configuration can be found here: Configure endpoint proxy and Internet connectivity settings - Microsoft Defender for Identity
• Server specification – check the supported operating systems and required server specifications.

Deployment

Now that you have confirmed that all the pre-requisites are met let’s get started deploying the Microsoft Defender for Identity sensor within your environment.

1. Download and install

Download and install the sensors on to your domain controller, AD FS, and AD CS servers. The download for the sensor and access key can be found in the Microsoft 365 Defender portal (https://security.microsoft.com) by clicking + Add sensor. For the complete steps and guidance on downloading and installing the sensor check our documentation here Download the sensor

Once you have downloaded the sensor and access key you can then install the sensor on your domain controllers, AD FS and AD CS servers.

There are two main methods of installing the sensor on your servers:

1. Manual installation – Manually run the sensor setup executable on your servers. The setup wizard will guide you through the installation steps.
2. Silent install – This option can be used to automate the installation of the sensor across many servers and can be deployed using software deployment systems such as Microsoft Configuration Manager. The silent install method also needs to be used when configuring proxy settings during installation. 

2. Deployment Health

Once your Defender for Identity sensors have been deployed and onboarded you can check the health of the sensors within the Microsoft 365 Defender portal by navigating to Settings > Identities > Sensors. This will help you to understand the deployment status and review the health of the sensors and updates. From this view you can see the Health Alerts for the specific onboarded servers.

All Defender for Identity Health Alerts for your tenant can also be viewed under Settings > Identities > Health issues. The Microsoft Defender for Identity Health issues page lets you know when there's a problem with your Defender for Identity sensors and configuration, by raising a health alert.

As an example, the following Health alert shows the impacted servers and the recommended steps required to fix the issue. For the example, configuring Windows Events enhances detections and provides additional information on the actions performed.

If Health Alerts are raised in your environment, you should review them and follow the recommendations to get your deployment to a healthy state. You should check your Health Alerts after deployment to find any pre-requisites that are not yet fulfilled.

3. Directory Service accounts

After installing the sensor, the sensor will use the local service account to connect to the domain controller. This allows Defender for Identity to provide security information and detections out-of-the-box. The local service account can be used in a single domain environment but when more domains are onboarded it is recommended to configure a Directory Service Account (DSA). Also, even in a single domain environment a DSA is required to detected potential Lateral Movement Paths (LMP).

The Directory Service account (DSA) in Defender for Identity is used by the sensor to perform functions such as connecting to and querying the domain controller and other domain controllers within your environment.

It is recommended to configure a Group Managed Service Account (gMSA) as this offers additional benefits such as easier management across multiple domains and detections for lateral movements.

The types of DSA which can be configured in your environment are:

• gMSA (Recommended)
• Regular user account

Full details on how to configure the DSA can be found here Directory Service account recommendations - Microsoft Defender for Identity

4. Permissions

During and after deployment of Microsoft Defender for Identity permissions will be required to view and administer the environment. Microsoft Defender for Identity offers role-based security allowing you to segregate duties within your security team and grant only the amount of access that users need to do their jobs.

When your MDI workspace is created, three Azure AD groups are created automatically:

• MDI Admin (Azure ATP [workspace] Administrators)
• MDI User (Azure [workspace] ATP Users)
• MDI Viewer (Azure [workspace] ATP Viewers)

To start managing your workspace you have different permission options which can be used. If administrators are using Azure AD roles, they can use the Global Administrator and Security Administrator Azure AD roles to access Defender for Identity.

If you don’t want to use Azure AD roles with your administrators Microsoft 365 Defender Unified RBAC can be configured to provide granular access. You can use the three default role groups mentioned above or use Microsoft 365 Defender Unified RBAC to configure and provide access to administrators.

More details on getting started with Microsoft 365 Defender Unified RBAC can found here: Microsoft 365 Defender role-based access control (RBAC) | Microsoft Learn

This article also provides detailed information and permissions which can be configured for Defender for Identity: Role groups - Microsoft Defender for Identity | Microsoft Learn

Post-deployment

As sensors are onboarded you will begin to receive Identity Security Posture Management (ISPM) recommendations. These recommendations enable you to identify and remediate weak spots in your protections of on-premises identities and identity infrastructure. We recommend continually reviewing and monitoring these ISPM recommendations.

Once the deployment steps in the section above have been completed there are some post-deployment steps which can be configured to ensure you get the maximum value and security from your deployment.

We recommend ensuring the following things are configured.

1. Network Name Resolution (NNR) – NNR is a key component of Defender for Identity functionality and enables correlation between raw activities (containing IP addresses), and the relevant computers involved. Ensure that at least one of the primary methods (NTLM, NetBIOS, RDP) can be used within your network, full details can be found here Network Name Resolution. Where required, optional NNR methods can be disabled by opening a support case.
2. Windows Event Collection - Defender for Identity detection relies on specific Windows Event log entries to enhance some detections and provide additional information on who performed specific actions such as NTLM logons, security group modifications, and similar events. Learn more here Configure Windows Event collection.

3. Configure SAM-R - Lateral movement path detection relies on queries that identify local admins on specific machines. These queries are performed with the SAM-R protocol. Configure the policy detailed here Configure SAM-R to enable lateral movement path detection.
4. Honeytoken tags - Honeytokens are used as traps for malicious actors, they are also simple to setup and validate Defender for Identity is working correctly. You can find more information on getting started here Entity tags in Microsoft 365 Defender. As a bonus, there is also a great blog on best practices for setting up honeytokens, Deceptive defense: best practices for identity based honeytokens in Microsoft Defender for Identity.
5. Manage action accounts - Defender for Identity can take remediation actions targeting on-premises Active Directory accounts if an identity is compromised. To take these actions, the required permissions need to be configured, more can be found here Manage action accounts.
6. Automated response exclusions - Configure accounts which should be excluded from automated response actions. As an example, once an account is excluded, automatic response actions as part of an incident wouldn't automatically disable a specified excluded account. Automated response exclusions.
7. Review Secure Score - Review the overall Secure Score for your environment and follow the recommendations for improving your security posture and reducing your possible attack surface.

Conclusion

Identity threats are constantly evolving, to stay ahead of attackers ensure that you have deployed Defender for Identity sensors correctly across your on-premises identity infrastructure and regularly check your posture recommendations and health alerts to leverage the latest best practices and minimize your attack surface.