In the rapidly evolving landscape of cybersecurity, safeguarding sensitive information and digital assets is paramount. One of the powerful tools in this endeavor is Microsoft Defender for Identity.
This comprehensive guide will walk you through the various aspects of managing Microsoft Defender for Identity, providing expert tips and insights to fortify your organization’s cybersecurity strategy.
Table of Contents
Introduction
Microsoft Defender for Identity is a cutting-edge solution designed to mitigate the growing risks of cyber threats. By leveraging advanced technologies and AI-driven analytics, it offers real-time threat detection, behavioral analysis, and risk-based conditional access. This suite of features empowers organizations to proactively identify and respond to security breaches, ensuring the integrity of their digital infrastructure.
In the previous article, we covered in detail how to deploy Microsoft Defender for Identity (MDI). In this article, we will explore how to effectively manage and maintain Microsoft’s cloud-based identity protection solution, MDI. This solution is designed to help organizations protect their identities from various types of advanced cyberattacks, such as identity theft and unauthorized access.
Prerequisites
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 – You need to have an account with either Global Administrator or Security Administrator in a Microsoft Entra Tenant.
3) Microsoft Defender for Identity (MDI) deployed – Check the following step-by-step guide on how to deploy Microsoft Defender for Identity (MDI) in your environment.
4) Licensing – You need to have any of the following licenses assigned to your account:
- Enterprise Mobility + Security E5 (EMS E5/A5)
- Microsoft 365 E5 (M365 E5/A5/G5)
- Microsoft 365 E5/A5/G5 Security add-on
- MDI standalone license
Assuming you have all the prerequisites in place, take the following steps:
Managing Microsoft Defender for Identity
In this section, we’ll cover key aspects of managing MDI, such as implementing role-based access control (RBAC), creating and managing policies, and monitoring and responding to alerts. Then, we will give you insights into best practices for optimizing MDI performance and troubleshooting common issues.
Configuring RBAC for MDI
When MDI is configured in a tenant, the feature will automatically provide you with three role groups in Microsoft Entra ID (formerly Azure Active Directory). These, outside of the Microsoft Entra ID roles that have permission to manage MDI settings, can help you govern access to the MDI workspace.
The Microsoft Entra (Azure AD) roles that have access as administrators in MDI are as follows:
- Global Administrator
- Security Administrator
The groups that are created once MDI is deployed are defined as follows:
- Azure ATP “your tenant name” Administrators
- Azure ATP “your tenant name” Users
- Azure ATP “your tenant name” Viewers
The Azure Advanced Threat Protection (ATP) groups have different levels of permissions toward MDI. While the Administrators groups can manage the full MDI settings, the Users group has more limited access, and the Viewers group has read-only access to the MDI settings.
// Microsoft is still using the old names from the former product which was known as Azure Advanced Threat Protection (ATP).
It’s important you delegate access appropriately and do not over-privilege users. Even if users do need these rights, you may want to control them with just-in-time (JIT) access.
The role groups are not natively manageable via Microsoft Entra Privileged Identity Management (PIM) since they are not defined as Microsoft Entra roles. You can, however, use PIM for Groups to govern access to the MDI roles. So let us look at how to leverage PIM to govern access to MDI.
Govern Access to MDI with PIM
You can leverage Privileged Identity Management (PIM), a Microsoft Entra Premium P2 capability, you can apply identity governance to MDI roles even though they are not traditional Microsoft Entra roles (in the way a Global Administrator or User Administrator is). This concept is depicted in the following diagram:
Let’s look at how to configure PIM for MDI role groups in the Microsoft Entra admin center portal:
1) Sign in to the Microsoft Entra admin center portal at (https://entra.microsoft.com/) as a Global Administrator or Privileged Role Administrator account.
2) Click on Microsoft Entra ID (Azure AD), then select Groups.
3) Click on + Add | Group to create a new group. Then enter a name for this group. In this example, the group is called, MDI Administrators as shown in the figure below. Make sure to select Yes on Azure AD Roles can be assigned to the group. This will effectively lock the group down quite hard, so it can only be managed by the Global Administrator, Privileged Role Administrator, or Owner roles of the group.
Click Create to continue and then confirm Yes, because creating a group to which Azure AD roles can be assigned is a setting that cannot be changed later.
4) Next, select the newly created group, MDI Administrators, and click on the Privileged Identity Management option under Activity on the left-hand side.
5) Click on Enable Azure AD PIM for this group to enable the PIM feature for this group.
6) Next, click on + Add assignments, you can now select/add which users are eligible to become members for MDI administrators.
7) On the same page, click on Settings | Member to customize this to your requirements. For example, you can change how long eligible administrators can have time-bound access to the role (maximum duration in hours), require multi-factor authentication (MFA) (if not already satisfied), or conditional access authentication context, require justifications, and require approvals.
8) Next, add your new group as a member of the original MDI admin group. For example, the new MDI Administrators group will be nested in Azure ATP “your tenant name” Administrators as direct members.
9) Repeat steps 2–8 for the remaining MDI groups. You need to create two additional groups MDI Users and MDI Viewers and enable Azure AD PIM for those groups. Once PIM is enabled and customized, you need to add those groups to the original MDI groups Azure ATP “your tenant name” Users, and Azure ATP “your tenant name” Viewers as direct members.
In summary, when incorporating RBAC with MDI, we’re presented with numerous options, and even more so with the advantages offered by Microsoft Entra Premium P2. While granting Global Administrator or Security Administrator roles may seem convenient initially, it’s not sustainable in the long run, necessitating a more organized strategy. This is where PIM for Groups comes into play, offering us a method that provides enhanced control and governance over administrative access to these solutions.
See Also: 8 Best Practices for Microsoft Entra ID (formerly Azure AD) Roles.
Managing MDI Security Alerts
Managing security alerts in MDI is straightforward. The different alerts aim to explain suspicious activities detected in the on-premises identity environment. The alerts can be categorized as follows:
- Reconnaissance and discovery alerts
- Credentials access alerts
- Lateral movement alerts
- Persistence and privilege escalation alerts
- Other security alerts
The alerts that are pre-configured in MDI are categorized using their MITRE ATT&CK Matrix tactic for Enterprise, you can find the complete list of alerts in the official Microsoft documentation (Security alert name mapping and unique external IDs).
To manage these alerts, you need to head over to the Microsoft 365 Defender portal and then perform the following tasks:
1) Go to Incidents & Alerts on the left-hand side of the screen and then go to Alerts.
2) To filter alerts from MDI from the other Microsoft 365 Defender services, click on Filter, and under Service sources, select Microsoft Defender for Identity, and then click Apply.
3) The alerts, just like the other alerts in the Microsoft 365 Defender Portal, have ten columns as follows:
- Alert name
- Tags
- Severity
- Investigation state
- Status
- Category
- Detection source
- Impacted assets
- First Activity
- Last Activity
By filtering the alert queue, you can select just the relevant MDI alerts:
4) Now to manage an alert, you click on it to get more details of what happened, as shown in the figure below. You can see what hosts are affected, the destination host for this alert, and the source host. For other alerts, this section might contain other details.
5) Next, click on “View alert details“. On the right-hand side, in the Alert details pane, you can see even more details and perform the following tasks:
- Quickly classify this alert: This is where we can set the alert to True positive or False positive.
- Alert State: This is where we can set classification, change the alert status, assign the alert to ourselves as an investigator, or unassign it from ourselves.
- Alert Details: This consists of more information about the alert, where we can follow a link to documentation about the alert type, see what incident, if any, the alert is associated
with, review the automated investigations linked to this alert type, and drill down into the impacted devices and users.
- Comments & history: This is where we can add comments to the alert and see the history of all actions associated with it.
- Manage alert: This is where you can change the status of an alert to one of the following (New, Resolved, In progress). Classification: This is where you can pick and choose from different types of classifications that fall under True positive, Information, expected activity, or Flase positive.
- Comment: This is where you can add comments.
The different types of alerts in MDI have different recommended actions and investigative actions to them, which are quite hard to cover in total detail in this form as it all depends on other behavior in the environment. Microsoft has provided detailed information about the different built-in alerts, and you’ll find links to these resources in the Further Reading section at the end of this article.
MDI will not only generate alerts when suspicious activity is performed but will also give insights into the security posture of your AD Domain Services (AD DS), Active Directory Certificate Services (AD CS), and Active Directory Federation Services (AD FS) as part of the Microsoft Secure Score and more. This includes lateral movement paths, displaying possible attack vectors from a normal user account through different computers and user accounts to a sensitive entity such as a domain administrator.
As alerts start to show in your MDI instance, you may notice legitimate and non-malicious activities. You can control these activities with exclusions in MDI whether they are true or false positives, and we’ll cover this in the next section.
Managing MDI exclusions
We have three types of exclusion in MDI that we can leverage to reduce false positives in our environment. All are managed from the Actions and Exclusions section of the Microsoft 365 Defender portal | Settings | Identities as shown in the figure below.
First, let’s discuss the “Global excluded entities“. These are IP addresses, Domains, Devices, or Users. These pretty much do what they say on the tin. So, if you want to stop these entities from appearing in any alerts, you can add them here. Please note that you should proceed with caution here by asking yourself the following question: Are you absolutely sure that these entities couldn’t generate true positives?
Then, we have a more fine-grained approach called, “Exclusions by detection rule“. This would ideally be used instead of the global option because we’re limiting our potential blind spots. Navigating to this setting, you’ll find the full list of MDI detection types and then the ability to add entities to exclude (only supported entities, varying by detection type). For example, the Data exfiltration over SMB detection, as shown in the figure below, lets you add in excluded users, devices, or IP addresses.
Third and finally, let’s discuss “Automated response exclusions“. In the previous article, we described how to configure action accounts. Action accounts are used as part of MDI’s ability to automatically respond to potential threats. For example, the disablement of user accounts during an automatic attack disruption. If you want to exclude users from these types of actions, you can add them here. This is a bit of a balancing act. You want to consider that sensitive accounts may be locked, therefore limiting your own access, but also, those same sensitive accounts probably should be locked to limit attack paths.
As you can see, exclusion management in MDI is reasonably straightforward to implement, but we do recommend proceeding with careful planning and minimizing exclusions.
Next, let’s see how can we improve the alerting even more with the use of entity tags in MDI.
Managing MDI Entity Tags
In MDI, we can use entity tagging to highlight sensitive accounts and honeytoken accounts. This improves our response by helping us prioritize the alerts. So what are Honeytokens?
Configuring Honeytokens
Honeytokens are imitation accounts established to detect and track suspicious actions when these accounts are in use. Honkeytoken accounts should remain inactive, designed with an appealing account name to entice unauthorized external or internal individuals to utilize them. For instance, an account named ADDS-Admin would be intriguing to attempt usage, given that the name implies authority within Active Directory Domain Services.
In the real world, though, the name of the account does not matter as the Security Identifier (SID) value of highly privileged users or groups. The SID values in Active Directory Domain Services are always the following. For more information, check the official Well-known SIDs for AD DS.
S-1-5-domain-500for the Administrator account in AD.S-1-5-domain-512for the Domain Admins group in AD.S-1-5-root domain-518for the Schema Admins group in AD.S-1-5-root domain-519for the Enterprise Admins group in AD.S-1-5-32-544for the Administrators group in AD.
Malicious outsiders consistently focus on these users and groups as their primary targets when attempting to control your AD domain. This is due to their possession of comprehensive domain access, enabling them to potentially perform actions such as data exfiltration, data deletion, compromising backups if they are domain-joined, and data encryption.
The honeytoken accounts tag can be assigned to any break glass emergency access account. This tag serves to trigger alerts for any utilization of these accounts. This practice is employed because such accounts are typically crafted to bypass security barriers within Active Directory, including tiered structures.
To tag an account as a honeytoken account, we need to jump over to the Microsoft 365 Defender portal and sign in as Global Administrator, Security Administrator, or, if you have configured RBAC for MDI as described in the previous section, a member of the Azure ATP “your tenant name” Administrators group. Take the following steps:
1) In the Microsoft 365 Defender portal, navigate to Settings on the left-hand side and head to Identities to gain access to the MDI settings.
2) In the Microsoft Defender for Identity settings view, we select Honeytoken under Entity tags and click on + Tag users as shown in the figure below.
3) Next, search for the accounts created in AD DS to be tagged as honeytoken accounts, in this example, the Administrator account. Then check the relevant accounts if more than one and click on Add selection as shown in the figure below.
4) Once the honeytoken account(s) are added, you can see them on the user’s view page as shown in the figure below. Please note that you can also add and tag devices as Honeytoken.
As described above, the process of tagging honeytoken accounts in MDI is very easy to go through and basically is a next-next-finish kind of approach. The same procedure can be followed if your MDI instance is covering multiple domains.
Next, let’s look at sensitive accounts.
Tagging Sensitive accounts
In MDI, the “sensitive” tag is used to identify and designate high-priority targets. Numerous pre-defined (built-in) groups are automatically categorized as sensitive by Defender for Identity, including Domain Admins, Domain Controllers, Microsoft Exchange Servers, Backup Operators, Server Operators, Schema Admins, and Enterprise Admins. Additionally, if servers are running roles like Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), or Certificate Authority Server roles, they are also automatically assigned the sensitive tag.
Beyond these built-in groups, we can also manually tag accounts, groups, and devices as sensitive in the same fashion as tagging honeytoken accounts and devices, but instead of heading into the Honeytoken part of Entity tags, we head to the Sensitive section and proceed with the following steps:
1) While in the MDI settings, click on Sensitive under Entity tags. Then click on + Tag users, + Tag devices, or + Tag groups and repeat the same steps as described in the previous section (Configuring Honeytokens).
2) Under each category, select Tag… to tag that type of entity. For example, under Groups, select Tag Groups. A pane will open with the groups you can select to tag. To search for a group, enter its name in the search box as shown in the figure below.
3) Last, select your group and click on Add selection.
Tagging sensitive accounts, devices or groups is as straightforward as tagging Honeytoken accounts. This stands as a crucial practice to incorporate into your operational routine, particularly for any alterations within your environment, such as the addition of new groups or servers.
Managing MDI Health Issues
The last piece that we need to cover is MDI health issues. MDI is equipped with a range of health alerts designed to activate under specific circumstances.
These alert triggers encompass instances where configuration settings are misconfigured, overlooked during the initial setup, or when issues arise related to communication and performance. For example, MDI sensors will generate alerts if no traffic from domain controllers is being received, if sensor updates aren’t occurring automatically, or in the event of errors in event analysis. The list of issues that can be detected dynamically evolves as the product life cycle progresses. As a result, notifications might also include information about end-of-life versions of Windows Server if a sensor operates on those particular versions.
These alerts, depending on severity, should be handled as soon as possible as they might impair MDI’s ability to successfully monitor the environment.
The health alerts in MDI can be accessed from the Security Portal available at Microsoft 365 Defender portal | Settings | Identities | General and the Health issues part, as shown in the following figure.
Last, it’s also worth heading to the Notifications | Health issues notifications area in MDI’s settings to add a notification email. This way, you’ll be proactively informed about any potential issues.
That’s it there you have it! Setting up health issue notifications helps you to keep on top of your MDI investment.
Summary
In this article, we covered key aspects of managing Microsoft Defender for Identity, such as implementing RBAC for MDI, creating and managing policies, and monitoring and responding to alerts. Additionally, we provided insights into best practices for optimizing MDI performance and troubleshooting common issues.
Managing Microsoft Defender for Identity is a crucial aspect of maintaining a strong cybersecurity posture. By leveraging its advanced features and implementing best practices, you can effectively detect, respond to, and mitigate cyber threats. By following these instructions, you can effectively manage Defender for Identity and ensure that your identity infrastructure is protected against advanced cyber threats.
Further Reading
Microsoft’s official documentation has great reference material for the full list of alerts MDI may generate. If you see these types of alerts, you can read up on them here:
- Reconnaissance and discovery alerts
- Credentials access alerts
- Lateral movement alerts
- Persistence and privilege escalation alerts
- Other security alerts
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
