Introduction
Welcome to the sixth article in our series on Microsoft Defender for Identity (MDI). As cyber threats continue to evolve, the need for robust security solutions has never been more critical. Over the course of this series, we’ve explored the foundational concepts of MDI, its integration strategies, and its role in fortifying organizational security. Today, we’re expanding the horizon further. MDI has broadened its capabilities beyond just Active Directory Domain Services (ADDS) to now include protection for Active Directory Federation Services (ADFS) and Active Directory Certificate Services (ADCS). But how do you ensure a seamless deployment across these services? In this installment, we’ll walk you through some key aspects of the MDI deployment in your environment, ensuring you’re well-equipped to leverage its full potential.
Webinar Recording and Slides
On 14.09, I had a webinar on implementing Microsoft Defender for Identity together with Daniel Naim from Microsoft.
Preparing for MDI Deployment
Setting up Microsoft Defender for Identity (MDI) requires a holistic approach that encompasses Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), and Active Directory Certificate Services (ADCS).
- General Assessment for All Servers (ADDS, ADCS, ADFS)
- Before diving into specific services, gather general data across all servers.
- Determining the number of vCPUs and memory allocated.
- Identifying the OS version and edition in use.
- Understanding the hypervisor type and version.
- Check PowerShell Remoting configuration.
- Before diving into specific services, gather general data across all servers.
- Connectivity to Azure
- MDI requires a connection to Azure. Coordinating with the security and networking team is important to ensure necessary rules are in place. This may take time and engaging them early in the project is important.
- Automated Installation
- With the potential of multiple domain controllers, ADFS, and ADCS servers, manual installation may not be a good idea. If possible, try to automate the sensor installations as much as possible. Consider using PowerShell Remoting to make the deployment process more efficient. Remember that it is not only a one-time job, and you need to consider that you may need to add new Domain Controllers, ADCS, or ADFS servers in the future, and it would be a good idea to automate the complete process. I have seen this in many cases where the new Domain Controllers are not covered.
- Resource Allocation with the Sizing Tool (For ADDS)
- The Defender for Identity Sizing Tool is needed for ADDS to understand how many resources you need for the Domain Controllers.
- Audit Active Directory Settings and Policies
- Audit Group Policies related to NTLM, SAM-R, Advanced Audit Policies, etc
- Audit AD Object Audit policies
Do the assessment first, collect the data, and analyze it. After that, communicate the necessary information to different stakeholders. The sooner, the better. Sometimes, some changes around the AD, ADCS, or ADFS can take longer.
Understanding MDI Deployment Models for ADDS
When deploying Microsoft Defender for Identity (MDI) for ADDS, choosing the right deployment model is vital to maximize both performance and security. MDI offers two primary deployment options:
Direct Deployment on the Domain Controller (Recommended)
- Advantages
- Streamlined setup without the need for extra hardware.
- Considerations
- The Domain Controller must fulfill MDI’s prerequisites and resource requirements.
- This method is typically suitable for most setups due to its straightforwardness.
Using a Separate Server for the MDI Sensor
- Advantages
- Provides adaptability for organizations with policies restricting installations on Domain Controllers.
- Useful when port mirroring is employed to route traffic to the MDI sensor.
- Considerations
- Involves additional hardware, which might expand the infrastructure.
- Additional configurations, such as port mirroring, are necessary.
- The separate server must meet MDI’s prerequisites.
- Larger footprint
Your deployment choice should align with your organization’s infrastructure, security guidelines, and operational needs. While the direct deployment on the Domain Controller is often favored for its straightforwardness, certain situations might warrant using a separate server. Aspects like the size of the organization, the structure of the network, and specific security protocols will influence this choice.
Lastly, ensure your chosen method aligns with Microsoft’s capacity planning recommendations.
Capacity Planning for MDI
Capacity planning ensures that your MDI deployment can handle your organization’s network traffic demands. Proper planning prevents performance issues, resource wastage, and operational challenges.
Key Considerations
- Performance: MDI might experience slowdowns during peak traffic without adequate capacity, potentially missing critical security events.
- Resource Efficiency: Overestimating needs can lead to unnecessary costs and underutilized hardware.
- Operational Stability: Sudden traffic spikes without proper capacity can result in system disruptions and delayed threat detection.
MDI Sensor – The Core Component
The MDI sensor monitors domain controllers, analyzes traffic, and sends data to the MDI service. Its performance is crucial for efficient threat detection.
Resource Guidelines for the MDI Sensor
- CPU: Allocate enough CPU resources, especially for domain controllers with high traffic.
- Memory: Ensure sufficient RAM for swift data processing and analysis.
Optimizing the MDI Sensor
- Monitor: Regularly check the resource utilization of Domain Controllers. Adjust resources if consistent peaks are observed.
- Stay Updated: Always use the latest version of the MDI sensor for improved features and performance.
- Optimal Power Configuration: For the MDI sensor to function at its best, ensure the server’s power plan is set to ‘High Performance’.
Measure your Domain Controllers traffic and based on the data, you can see how much memory and CPU you need to assign. You can download the MDI Sizing Tool from here – https://aka.ms/mdi/sizingtool
Service Accounts for MDI – Standard AD Accounts vs. GMSA
When deploying MDI Sensor, the choice of service account is important. While standard Active Directory (AD) accounts and Group Managed Service Accounts (GMSA) can be utilized, I recommend using GMSA for enhanced security and automation.
Standard AD Accounts
- Pros
- Flexibility: Can be used across various services and applications.
- Familiarity: Most organizations are already accustomed to managing standard AD accounts.
- Cons
- Manual Password Management: Administrators need to periodically update passwords, which can lead to potential security risks if not managed diligently.
Group Managed Service Accounts (GMSA) (Recommended)
- Pros
- Automated Password Management: GMSA automatically handles password changes, reducing administrative overhead and bolstering security.
- Scoped Permissions: Designed for specific services, minimizing the risk of over-privilege.
- Isolation: If compromised, the impact is limited to the specific service the GMSA is associated with.
- Cons
- Limited Use: Can only be used with services and applications that support GMSA.
- Initial Setup Complexity: Requires a bit more effort during initial setup, especially for organizations unfamiliar with GMSA.
While both account types have pros, GMSA is the recommended choice for MDI deployment due to its inherent security advantages and automation capabilities. Organizations should weigh the benefits of GMSA against their operational needs and existing infrastructure when deciding.
Recycle Bin Permissions for Deleted Objects
For a holistic view of activities, the MDI sensor requires permission to access deleted objects in the Active Directory Recycle Bin. This capability allows MDI to monitor and analyze actions related to objects even post-deletion. Configure the necessary permissions here.
Log on as a Service Permissions for the Sensor
When deploying the MDI sensor ensure that the account has the ‘Log on as a service’ rights. This permission is required for the sensor’s seamless operation. More details can be found here.
Deploying MDI Sensor with GMSA Across ADDS, ADFS, and ADCS
When deploying the MDI sensor across multiple services, you may wonder what to do with the service accounts. Single GMSA on all three services or distinct GMSA per service.
Single GMSA for ADDS, ADFS, and ADCS
- Pros
- Simplified Management: Easier to manage one account rather than multiple accounts.
- Consistent Configuration: Ensures uniformity across all services.
- Cons
- Potential Security Concerns: If the GMSA is compromised, it might impact on all three services.
- Over-Privilege Risk: The GMSA might have more permissions than necessary for individual services.
Distinct GMSA for Each Service (ADDS, ADFS, ADCS) (Recommended)
- Pros
- Enhanced Security: Isolates each service. If one GMSA is compromised, the other services remain unaffected.
- Tailored Permissions: Each GMSA can be finely tuned to the specific permissions required by its respective service.
- Cons
- Increased Management: Requires managing multiple accounts.
- Complex Configuration: Initial setup might be more intricate, especially for organizations unfamiliar with multiple GMSA configurations.
For enhanced security, I recommend using distinct GMSAs for each service. While this approach requires more effort in management, the security benefits it offers by isolating each service are significant.
Understanding Lateral Movement and Its Implications
Lateral movement is a technique employed by cyber attackers where they progressively move through a network, seeking to escalate their privileges by exploiting non-sensitive accounts to gain access to sensitive ones. This tactic is a critical step in the cyber-attack kill chain, with the goal often being domain dominance.
Why is lateral movement a concern?
- Access to Sensitive Accounts: Attackers leverage non-sensitive accounts to identify and access sensitive accounts, groups, and machines that share stored sign-in credentials.
- Domain Controller Compromise: Once an attacker successfully navigates the network, they can potentially gain access to domain controllers, amplifying their threat.
Microsoft Defender for Identity is acutely aware of these threats and has mechanisms to detect and counteract them.
Lateral Movement Paths (LMPs) with Microsoft Defender for Identity
A standout feature of Microsoft Defender for Identity is its Lateral Movement Paths (LMPs). These are visual guides designed to provide a clear picture of how attackers might move laterally within a network. LMPs serve a dual purpose:
- Visualization: They offer a direct, easy-to-understand visual representation of potential attack paths, highlighting vulnerable, sensitive accounts.
- Mitigation: By understanding these paths, organizations can take proactive measures to mitigate risks, closing off avenues of attack before they can be exploited.
SAM-R Configuration for Enhanced Security
SAM-R, or Security Account Manager Remote Protocol, is another method attackers might use in their lateral movement strategy. It allows for the enumeration of domain users. To ensure that Microsoft Defender for Identity effectively detects suspicious SAM-R activities you need to configure the “Network access – Restrict clients allowed to make remote calls to SAM” policy.
Action Accounts
Microsoft Defender for Identity (MDI) can take remediation actions on potentially compromised on-premises Active Directory accounts. These actions can include disabling user accounts or resetting their passwords. To execute these remediation actions effectively and securely, MDI requires specific permissions, which are granted to what are named as action accounts.
Some key things to take into account
- Default Behavior: By default, the Microsoft Defender for Identity sensor installed on a domain controller will impersonate the LocalSystem account of the domain controller and perform the actions. This allows for immediate remediation without additional configurations.
- Custom Configuration: Organizations can change this default behavior by setting up a GMSA account. This provides more control over the permissions and actions the account can perform, ensuring a tailored fit to the organization’s security policies.
- Permissions: Action accounts are granted specific permissions in the Active Directory to carry out their tasks. These permissions typically include resetting passwords and modifying user account attributes.
- Reset Password: Allows the action account to reset passwords for user accounts.
- Write: Enables the action account to modify certain attributes of user accounts, such as disabling them.
- Read: It is necessary for the action account to read user account attributes.
- Dedicated or LocalSystem Account: I recommend creating a dedicated Group Managed Service Account (GMSA) for these remediation actions.
- Monitoring: I recommend monitoring these activities using Microsoft Sentinel in both cases.
AD FS Audit Configuration
Many organizations are still using AD FS today. Microsoft recommends getting rid of AD FS in general, but in some cases, it may be difficult and take time. So, if you are still using ADFS today, it is still a good idea to cover the AD FS servers with MDI Sensors.
Key Configuration Aspects for ADFS
- Enable AD FS Object auditing in Active Directory
- Enable ADFS Auditing on AD FS Servers. Use PowerShell or AD FS Administrator Console.
- 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
- Configure AD FS Database Permissions
- Install MDI Sensor
Exchange Object Auditing
To bolster defense against threats targeting Exchange, it’s important to enable auditing on the configuration container. This ensures comprehensive logging and analysis of Exchange activities by MDI. Learn how to configure this here.
NTLM Auditing
NTLM Auditing is needed for capturing NTLM authentication events. When Defender for Identity Sensor processes this event, it provides enriched insights about the server interactions within the network. It’s recommended to apply domain group policies specifically to domain controllers to ensure accurate data collection and enhance security monitoring. To capture the Event ID 8004, you must configure one additional GPO. Read more from here.
AD Object Auditing with Advanced Policies
For comprehensive threat detection, MDI not only requires changes to your AD object auditing configuration, but you also need to make sure that certain advanced audit policies are enabled. These policies ensure that all relevant events are captured, providing a holistic view of activities within the Active Directory. If these advanced policies haven’t been enabled in your environment, it’s important to discuss with the SIEM engineers. This ensures they are prepared for the increased data flow from AD.
Key points
- Check Current Settings: Check your existing auditing configurations before adjusting anything. This helps identify what needs change.
- Group Policy Adjustments: You might need to modify Group Policy settings to capture the right events for MDI.
- Audit Logs: Capture all relevant events without flooding your audit logs with unnecessary data.
ADCS Auditing and Sensor for MDI
Now that MDI supports ADCS service, you need to ensure that ADCS auditing is configured correctly. I recommend reading my previous post on configuring ADCS service auditing settings.
MDI Sensor installation on AD CS is like installing the sensor on AD DS. You need to configure service account logon rights first and then install the sensor.
Microsoft 365 Defender for Identity Portal Settings
The Microsoft 365 Defender for Identity Portal is a centralized hub for configuring and managing various aspects of your MDI deployment. While the initial setup might focus on the MDI sensor and service accounts, there are other settings that deserve attention to maximize the potential of MDI.
- Honeytoken Accounts: These are decoy accounts set up to lure attackers. Any activity on these accounts is likely malicious, and MDI can alert you immediately when they’re accessed.
- Sensitive Accounts, Devices, and Groups: Not all accounts and devices in your organization have the same risk profile. By tagging certain accounts, devices, and groups as ‘sensitive’, you can prioritize their monitoring and get alerts on suspicious activities related to them.
- Scheduled Reports: Regular reports can provide insights into the security posture of your organization.
- Automated Response Exclusions: While automated responses can be a boon, there might be certain scenarios or entities you want to exclude from automatic actions. Configuring these exclusions ensures that MDI acts in line with your organization’s operational needs.
- Exchange Servers: If you’re using Exchange, it’s important to tag these in the MDI portal.
- Health Notifications: The health of your MDI infrastructure is important. Set up notifications to alert you of any issues, ensuring that your MDI is always operational and effective.
- Advanced Settings: MDI allows you to turn off the learning period if it is needed.
Summary
Deploying Microsoft Defender for Identity (MDI) is more than just a technical exercise; it’s a strategic initiative that requires planning, collaboration, and continuous monitoring. Here are some of my recommendations for ensuring a successful MDI deployment:
- Stakeholder Alignment: Before the deployment, gather all necessary stakeholders, including IT, security, and networking. Discuss the value proposition of MDI and ensure everyone understands the need and reasons behind MDI deployment.
- Educate and Advocate: Organize internal or external workshops to educate relevant teams about MDI. Highlight its capabilities, benefits, and the changes it might introduce to the existing infrastructure.
- Phased Deployment Approach: If you have many domain controllers, avoid deploying the sensor all at once. Adopt a phased approach, starting with a few and gradually expanding, allowing for continuous monitoring and adjustments.
- Review Current AD Policies: Examine your existing Active Directory advanced audit policies, including NTLM and object audit policies. Ensure that the necessary auditing settings are enabled across all domains.
- Consistency is Key: MDI requires specific settings for each domain controller. It’s crucial to maintain consistency across all environments. Regularly review and track these settings to ensure uniformity.
- Use Group Managed Service Accounts: For enhanced security and simplified account management, leverage Group Managed Service Accounts (GMSA) during deployment.
- Connectivity and Installation: Discuss connectivity requirements with the security and networking teams. Ensure everyone is on the same page regarding how the sensor will be installed.
- Integration with Microsoft Sentinel: If you’re an existing Microsoft Sentinel user, ensure that MDI data is ingested into Sentinel for a more comprehensive security overview.
- Portal Settings Configuration: Dive into the MDI portal settings to:
- Define settings such as Honeytoken accounts, Exchange servers, and health issue notifications.
- Identify and define sensitive accounts.
- Schedule built-in reports for regular insights.
- Configure action accounts for specific tasks.
- Configure reports.
- Etc.
- Continuous Monitoring and Feedback: Monitor MDI’s performance after deployment. Engage with teams to gather feedback, address concerns, and make necessary adjustments.
- Stay Updated: The cybersecurity landscape is ever evolving. Regularly update MDI to incorporate the latest features and threat detection capabilities.
- Dive into Advanced Hunting: Familiarize yourself with MDI’s advanced hunting tables. Understand the data within to leverage its full potential for in-depth investigations and threat hunting.
