Tag Archives: Azure

How to Set Up Multi-Tenant Management in Microsoft Defender XDR

Posted on by
Reply

Multi-tenant management in Microsoft Defender XDR (MTO) is designed to provide security operation teams with a single, unified view of all the tenants they manage. This feature allows teams to quickly investigate incidents and perform advanced hunting across data from multiple tenants, thereby improving their security operations.

Multi-tenant management in Microsoft Defender XDR became generally available (GA) on February 20th, 2024.

A copilot search can provide more details 🙂

Blog Purpose

The goal of this blog post is to show you how to set up multi-tenant management in Microsoft Defender XDR with the least privilege needed. Multi-tenant management in Microsoft Defender XDR allows you to manage and monitor multiple tenants from a single console. This feature was released for general availability (GA) on February 20th, 2024.

Topology Scenario

Source tenant : Contoso.com
Target tenant : Fabrikam.com

Typically, I choose a hub and spoke topology. Source and target tenants’

Roles

Global Admin Role, is required for the initial set up in the ‘Contoso.com’ source tenant, when configuring the ‘cross tenant’ configurations

Browser Sessions

Sometimes using multiple Microsoft Edge profiles to sign into the source tenant and the target tenants can cause problems, due to cookies and too many Edge active browser sessions.

Typically, I use the Microsoft Edge browser in private window option to sign into the source ‘Contso.com’ tenant

And then Google Chrome ‘Incognito Mode’ session to sign into the target ‘Fabrikam.com’ tenant.

#####Step 1

Log into the target tenant ‘Fabrikam.com’, browse to https://entra.microsoft.com/ / external identities/ cross-tenant access settings

Select ‘Add organization’ and add the tenant id for ‘Contoso.com’

When the Contoso organization has been added to Fabrikam.com, select the inbound access/ cross-tenant sync and select ‘Allow users sync into this tenant’

Select the inbound access/ trust settings  ‘Automatically redeem invitations with the tenant’
(Typically, this setting will automatically be selected, but just in case, it needs to be checked)

#####Step 2

Log into the target tenant ‘Contoso.com’, browse to https://entra.microsoft.com/  external identities/ cross-tenant access settings

Select ‘Add organization’ and add the tenant id for ‘Fabrikam.com’

When the organisation ‘Fabrikam.com has been added, select Outbound Access/ trust settings/ automatically redeem invitations with the tenant Fabrikam

#####Step 3

Now login to ‘Contoso.com’ and browse to , browse to https://entra.microsoft.com/ / external identities/ cross-tenant access settings

Select ‘Add organization’ and add the tenant id for ‘Fabrikam.com’

In the source tenant ‘Contoso.com’ / cross-tenant access settings, select ‘Fabrikam.com’ outbound settings / trust settings

#####Step 4

This section is where global admin privileges are required in the source tenant ‘Contoso.com’

Browse to Contos.com | cross-tenant synchronization > Cross-tenant synchronisation

Select new configuration

Provide a name for your configuration

It can take up to 60 seconds for the configuration to be created, if the browser session appears like it is hung, JUST WAIT!

Select ‘Get Started’

Change the provisioning mode, authentication mode and tenant ID as per the image below.

When pressing save, the browser session does not revert to the global cross-tenant synchronization / cross-tenant synchronization / configurations GUI.

#####Step 5

At this stage we will configure the provisioning configuration.

Select the ‘Contoso – Fabrikam organization’

Add the admin user accounts from the source tenant ‘Contoso.com’ that will be provisioned into ‘Fabrikam.com’

Select the provisioning status and change it from off to on.

Within the provisioning overview section, select ‘Restart provisioning’

Note: Do not keep clicking on ‘start provisioning’ , ‘stop provisioning’ and ‘restart provisioning’ , be patient and wait!

#####Step 6

To access the security data of the ‘Fabrikam.com’ tenant, the admin users from ‘Contoso.com’ need to be assigned the ‘Security reader’ role in ‘Fabrikam.com’. This role allows them to view security reports and alerts, but not to make any changes.

However, if ‘Fabrikam.com’ has Privileged Identity Management (PIM) enabled and is an Enterprise Identity Protection 2 (EIP2) tenant, there is an extra step involved.

The ‘Security reader’ role assignment must be activated through PIM, either for a specific duration or as permanently eligible. Note that the permanent option is not really permanent, it still expires after 6 months and needs to be renewed manually.

Therefore, it is recommended to set a reminder to check the PIM role assignments in ‘Fabrikam.com’ and renew the ‘Security reader’ role for the ‘Contoso.com’ admin accounts when necessary.

‘Security Reader’ role can manually be added per Contoso admin in Fabrikam or a Microsoft Entra ID security group can be created and assigned the ‘Security Reader’ role. This process could make life easier for admins, they simply need to add the Contoso admins to the newly created security group.

#####Step 7 Each admin account should confirm that ‘Fabrikam.com’ appears in their list of organisations that they can collaborate with via this url: https://myaccount.microsoft.com/organizations

#####Step 8

Each ‘Contoso.com’ admin must login to https;//mto.security.microsoft.com and select settings/ add tenants / and select ‘Fabrikam.com’

To validate successful configuration and visibility of multi tenant devices. The Contoso admin needs to browse to the Devices \ Devices Inventory

By selecting Devices/ Tenants, it will provide an image that provides a high level overview of device status per tenant.

#####Step 9

In this scenario ‘Contoso.com’ and ‘Fabrikam.com’, corporate office locations have trusted named locations in Entra ID conditional access. When a ‘Contoso.com’ admin accesses MTO, the Conditional access policies, may simply grant a ‘Contoso.com’ admin access to ’Fabrikam.com’ tenant without MFA challenge.

In the scenario where an organisation does not have ‘named locations’ configured in ‘Entra conditional access’, the source tenant admin, may be unable to view the organisations target tenant.

Browse to content distribution / tenant groups / create tenant group

In the bottom right hand corner, the image below may display and prompt for MFA login.

Once logged into Fabrikam , via MFA. The Fabrikam tenant will and devices will become visible in MTO

Also test login to the target tenant via https://security.microsoft.com/tenantid to ensure security admins can view all sections of the security.microsoft.com portal.

#####Step 10

MTO device filer view

#####Step 11

Advanced hunting.

Advanced hunting queries can be executed against ‘Contoso.com’ and ‘Fabrikam.com’

#Some sample KQL queries

## All mitre attack alerts

AlertInfo // Define timerange | where Timestamp > ago(30d) | where AttackTechniques != “” | mvexpand todynamic(AttackTechniques) | summarize count() by tostring(AttackTechniques) // Define graphic | render piechart

## Device Scans

DeviceEvents

| where ActionType == “AntivirusScanCompleted”

| summarize arg_max(Timestamp, *) by DeviceId

| extend ScanType = tostring(parse_json(AdditionalFields).ScanTypeIndex),

    DaysAgo = datetime_diff(‘day’, now(), Timestamp)

| project DeviceName, ActionType, ScanType, DaysAgo

// Filter only devices that have not performed a antivirus scan in the last day

| where DaysAgo > 0

| sort by DaysAgo

#####Summary

#Some of the positive features are:

– Simplified threat hunting with multi-tenancy support.

– Centralized view of all device inventory across all tenants and within each tenant.

– Instant insights and ability to filter views according to needs.

The most amazing feature for me is the ability to run KQL queries across all tenants. I ran some KQL queries across 8 tenants with thousands of devices and the results took between 1 – 5 seconds.

#One of the negative features is:

– The service does not provide a cross-tenant reporting functionality.

#### Reference for KQL queries.

https://github.com/Bert-JanP/Hunting-Queries-Detection-Rules/blob/main/MITRE%20ATT%26CK/Mapping.md

Azure Dynamic Groups for all Microsoft Defender for Endpoint Licensed Users

Posted on by
Reply

I always find using Microsoft Azure Active Directory dynamic groups much easier to use when assigning policies, for example Defender for Endpoint onboarding policies via Intune.

Microsoft Defender for Endpoint included with M365 licensed user rule syntax

user.assignedPlans -any (assignedPlan.servicePlanId -eq “871d91ec-ec1a-452b-a83f-bd76c7d770ef” -and assignedPlan.capabilityStatus -eq “Enabled”)

Microsoft Defender for Endpoint plan 1 licensed user rule syntax

user.assignedPlans -any (assignedPlan.servicePlanId -eq “292cc034-7b7c-4950-aaf5-943befd3f1d4” -and assignedPlan.capabilityStatus -eq “Enabled”)

Microsoft Defender for Endpoint DLP

user.assignedPlans -any (assignedPlan.servicePlanId -eq “64bfac92-2b17-4482-b5e5-a0304429de3e” -and assignedPlan.capabilityStatus -eq “Enabled”)

Microsoft Defender for Vulnerability Management add-on

user.assignedPlans -any (assignedPlan.servicePlanId -eq “36810a13-b903-490a-aa45-afbeb7540832” -and assignedPlan.capabilityStatus -eq “Enabled”)



Microsoft Azure AD password protection Service vs Passwordless Authentication

Posted on by
Reply

When the Azure Active Directory Premium password protection service was first released, it was well received.

There a few issues with the Azure AD Premium ‘Password Protection’ service.

1: An enterprise customer will block internet access on all domain controllers
2: If using the Azure AD Premium ‘Password Protection’ service, it requires an agent installed on all domain controllers, this agent will then, communicate with a proxy agent to establish access to Azure AD. For example , ‘agent on dc’s’ communicates to agent on ‘AD Connect server’
3: Microsoft Defender for Identity domain controller agent, cannot co-exist with the Azure AD Premium ‘Password Protection’ service agent, on the same domain controller
4: Microsoft Defender for Identity service will significantly improve an organisation’s security posture in comparison to the Azure AD Premium ‘Password Protection’ service
5: A much easier and secure method of Identity Management, is to enable the Microsoft Active Directory Premium and Microsoft Authenticator services to use: Passwordless authentication.

Passwordless can protect against

BruteForce Attacks
Password Spray Attacks.

Enabling passwordless , can also help organisations, to get one step further in their Zero Trust journey

Azure Identity Protection – Microsoft Defender for Identity

Posted on by
Reply

The image above is a high level overview of all identity protection methods regardless of vendor and especially when it comes to implementing Zero Trust. A lot of organisations do not really know what Zero Trust is, or how to begin their Zero Trust journey.

Zero Trust is a bit like Data Classification, it becomes an operational task that will never end. It is not implemented as a project but more as an operational procedure, that constantly evolves as threats and data protection requirements evolve. I have not yet seen a Zero Trust request from an organisation yet that are exactly the same. Zero Trust strategies can often be similar per industry like , legal, pharma, manufacturing and food industry etc..

The purpose of this blog post is to show how Azure Identity Protection and Microsoft Defender for Identity protection work together and can improve any organisation’s security posture as Identity is the new security plane and the days of protecting identity behind edge perimeter firewalls are no longer relevant.

Not all organisations’ (like SMB) can afford Microsoft Azure Identity Protection. I normally advise SMB organisations to procure Azure AD Premium plan 2 licenses to protect any privileged accounts.

For enterprise organisations that are licensed for Azure Identity protection, my preference for implementing the Azure Identity Protection controls, is via Conditional Access. This provides additional insights when placing the policies in report mode only and then reviewing the reports in Conditional Access – Insights and Reporting.

Azure Active Directory Topology

The image above illustrates Azure ADDS (Active Directory Domain Services) and Azure AD. So, think of Azure Identity Protection, as a service protecting identity at the cloud level or like the traditional perimeter edge firewall for ADDS. Microsoft Defender for Identity, protects on-premise identities.

Microsoft Azure Identity Protection

Identity Protection is a tool that allows organizations to accomplish three key tasks:

Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats

Microsoft Defender for Identity

Microsoft Defender for Identity monitors domain controllers by capturing and parsing network traffic and leveraging Windows events directly from domain controllers, then analyses the data for attacks and threats. Utilizing profiling, deterministic detection, machine learning, and behavioural algorithms Defender for Identity learns about your network, enables detection of anomalies, and warns you of suspicious activities.

Microsoft Defender for Identity provides alerts to suspicious lateral movements in an on-premise network with ADDS identities. The alerts are great but can only be actioned as soon as a Security staff member can respond to the alerts.

The two automated responses that Microsoft for Identity can perform are:

Disable user â€“ this will temporarily prevent a user from logging in to the network. This can help prevent compromised users from moving laterally and attempting to exfiltrate data or further compromise the network. 


Reset user password – this will prompt the user to change their password on the next logon, ensuring that this account cannot be used for further impersonation attempts. 

Typically, all enterprise organisation’s do not permit internet access on their domain controllers, except for port 53 (DNS) or port 123 (Network Time Protocol), but most normally domain controllers internet connectivity is controlled by proxies

The Azure AD Premium P1 and P2 password protection service, provides an excellent topology. An agent is installed on domain controllers that then communicates with a proxy agent installed on a server, that has internet access, like an AD connect server.

Microsoft Defender for Identity standalone sensor

The standalone sensor requires two network adapters.
1: Management Adapter: used for communications on your corporate network
2: Capture adapter: used to capture traffic to and from the domain controllers

The below ports are required to be configured for standalone sensor

Azure Sentinel

Playbooks may be available in the future that can perform more automated remediation tasks with Microsoft Defender for Identity.

Microsoft have provided an online demonstration on how to compromise an identity and take control of a domain, which I find hard to believe, however, it is a bit like ethical hacking. Security professionals must know the lateral movements of a bad actor when attempting to compromise an identity and an on-premise Active Directory domain.

The article is available HERE

Microsoft Defender for Identity also provides some recommendations, when the Microsoft for Defender Identity sensors (agents) have gathered telemetry information on an on-premise Active Directory instance. An example would be ‘implement secure LDAP’, when an organisation reviews the recommendations provided by Microsoft Defender for Identity, some careful planning is required to assess the impact of implementing the recommendations that Microsoft Defender for Identity has provided.

When Azure Identity Protection and Microsoft Defender for Identity, has been fully implemented in an organisation, it will really improve the organisation’s security posture and Microsoft will continually develop these services to protect against existing and future vulnerabilities.




Azure AD Conditional Access Policies Best Practices

Posted on by
Reply

Every organisation is different and has different requirements. I have been working with conditional access for quite some time and have settled on the following policies for every organisation.

Create a security group that contains users that are permitted to access the organisations cloud services when outside of trusted locations.

Blocked Countries Conditional Access Policy

  • All Users
  • Exclude Break Glass Admin account
  • All Cloud Apps
  • Location : Blocked Countries that have been setup in the named locations section of Azure Conditional Access.
  • Access Control : Block Access

Blocked External Access

  • All users , except Break Glass Admin account and security group that contains users that are permitted access.
  • All Cloud Apps
  • Locations : Any location except trusted locations
  • Access Control : Block Access

Permit External Access 

  • Users : security group that contains users that are permitted access.
  • All Cloud Apps
  • Locations : Any location except trusted locations
  • Client Apps
    Browser
    Mobile apps and desktop clients
    Modern authentication clients
  • Grant Access : Require all of these controls
    Require Multi factor Authentication
    Require Hybrid Azure AD joined device
    Require approved client app
    Terms of Use

Mobile Device Access

  • Users : security group that contains users that are permitted access.
  • Exchange Online
  • Locations : Any location except trusted locations
  • Device Platforms : Android & IOS
  • Client Apps
    Browser
    Mobile apps and desktop clients
    Modern authentication clients
  • Grant Access : Require all of these controls
    Require Multi factor Authentication
    Require device to be marked as compliant (Enrolled in Intune)
    Require approved client app

Why still enable MFA for the mobile device access policy. When the Microsoft Authenticator application is installed on an Android or IOS device. It acts like an SSO broker and can communicate with the modern authentication Microsoft Outlook client.

Block Legacy Protocols

Simply replicate the legacy : Baseline policy: Block legacy authentication (Preview)