Microsoft Azure AD password protection Service vs Passwordless Authentication

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

Securing M365 mail routing : SCENARIO 3

When an organisation has completely transitioned and migrated to Exchange Online and directed their MX record to contoso-com.mail.protection.outlook.com. The organisation should in line with best practices, have Microsoft Defender for Office365 Plan 2 securely configured.

Scenario 3, this my proffered choice. All Contoso *.onmicrosoft.com aliases can be blocked as they are no longer required. When Contoso’s mx record has been directed at Exchange Online protection. Exchange Online Protection & Microsoft Defender for 365 will protect all aliases. It may not even be necessary to block all Contoso *.onmicrosoft.com aliases.

It is possible to create an email address policy for Office365 groups that only use’s @contoso.com primary email addresses, which can still allow mail flow to Team’s channels. Then the usual protection of contoso.com comes into play, SPF, DKIM and finally DMARC.

Securing M365 mail routing : SCENARIO 2

Some organisations do not use Exchange Online Protection and Microsoft Defender for 365 to protect their Exchange Online tenant and use 3rd party message hygiene services like Mimecast and Proof Point. This blog will demonstrate a a scenario where securing Exchange Online message routing is configured incorrectly and could be classified a vulnerability,

SCENARIO 2


1. Contoso.com MX record is pointed at Mimecast; Mimecast provides spam protection
2. Mimecast then passes the messages to Exchange Online
3. If there are any remaining Exchange on-premise recipients, Exchange online will route the messages to the Exchange Hybrid servers via the secure Exchange Hybrid connectors
3. The Exchange Online inbound connector that accepts traffic from the Mimecast service is secured via TLS

VULNERABILITY
Anyone in the world can send an email to to an Exchange Online recipient with a *.mail.onmicrosoft.com or *.onmicrosoft.com alias, when sending to these domains. The messages completely bypasses , the organisation’s Mimecast’s message hygiene services and can route messages to Exchange Online recipients and Exchange on-premise recipients. If the organisation has not configured Exchange Online protection and Microsoft Defender for 365, then the organisation is vulnerable to malware and phishing emails.

Another problem: Office365 groups, When a Teams Channel is created, it creates an Office365 group that will have a *.onmicrosoft.com alias. Bad actors sending emails to these aliases can once again completely bypass the organisation’s message hygiene services.

SOLUTION
The Hybrid configuration wizard creates an Exchange Online inbound connector that is locked down with TLS via a public trusted certificate on the Exchange Hybrid servers.

The default inbound Exchange Online connector that was created by the Exchange Hybrid wizard, can be modified to only accept inbound messages from the IP ranges of the Mimecast service and TLS.

This script queries the existing inbound connector and creates an inbound connector that blocks messages recipients using the *.mail.onmicrosoft.com to only accept traffic from a service using the TLS certificate and connector that has been modified or it can query a new inbound connector

In this scenario , when a message is sent to an Exchange online recipient , the message flows as follows.
1. MX contoso.com
2. Mimecast
3. Contoso.com aliases & all consto.com *.onmicrosoft.com will only accept messages from Mimecast

Note: run this script using the latest Exchange Online PowerShell module

New-InboundConnector -Name ‘Restrict inbound mail flow to hybrid domains’ -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $InboundConnectorName).TlsSenderCertificateName -RestrictDomainsToCertificate $true -RequireTls $true

Securing M365 mail routing : SCENARIO 1

Some organisations do not use Exchange Online Protection and Microsoft Defender for 365 to protect their Exchange Online tenant and use 3rd party message hygiene services like Mimecast and Proof Point. This blog will demonstrate a scenario where securing Exchange Online message routing is configured incorrectly and could be classified as a vulnerability,

SCENARIO 1

In the scenario above , this could be one of the most typical Exchange Online topologies.
1. Contoso.com MX record is pointed at Mimecast, Mimecast provides spam protection
2. Mimecast then passes the messages to Proof Point, and Proof Point, performs malware inspection on the messages.
3. Proofpoint then routes the messages to the on-premises Exchange Hybrid platform.
4. Exchange Hybrid forwards messages to Exchange Online recipients via the Exchange Hybrid connector and the mail flow source Exchange Hybrid server communicates directly with Exchange Online and does not route via Mimecast or Proof Point.
5. The Exchange Online inbound connector that accepts traffic from the Exchange Hybrid servers is secured via TLS.

VULNERABILITY
Anyone in the world can send an email to an Exchange Online recipient with a *.mail.onmicrosoft.com or *.onmicrosoft.com alias, when sending to these domains. The messages completely bypasses , the organisation’s Mimecast and Proofpoint message hygiene services. If the organisation has not configured Exchange Online protection and Microsoft Defender for 365, then the organisation is vulnerable to malware and phishing emails.

Another problem: Office365 groups, When a Teams Channel is created, it creates an Office365 group that will have a *.onmicrosoft.com alias. Bad actors sending emails to these aliases can once again completely bypass the organisation’s message hygiene services.

SOLUTION
The Hybrid configuration wizard creates an Exchange Online inbound connector that is locked down with TLS via a public trusted certificate on the Exchange Hybrid servers.

This script queries the existing inbound connector and creates an inbound connector that blocks messages routed to *.onmicrosoft.com recipients, to only accept traffic from the Hybrid servers that are using the matching TLS certifictate.

In this scenario , when a message is sent to an Exchange online recipient , the message flows as follows.
1. MX contoso.com
2. Mimecast
3. Proof Point
4. Exchange on-premises
5. Exchange on-premise forwards the message to the Exchange Online recipient’s *.mail.onmicrosoft.com alias.

Note: run this script using the latest Exchange Online PowerShell module

New-InboundConnector -Name ‘Restrict inbound mail flow to hybrid domains’ -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $InboundConnectorName).TlsSenderCertificateName -RestrictDomainsToCertificate $true -RequireTls $true

Azure Identity Protection – Microsoft Defender for Identity

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.




Quest Migration Migration Manager Unable to migrate SID history

One of my colleagues Mark Doyle highlighted an issue with QMMA for Windows Server 2019 and 2022 domain controllers. Without these commands run on the 2019 and 2022 domain controllers the DSA agent server could not successfully migrate user accounts and SID history.

So my colleague Mark Doyle stuck at it , and even the Windows Server 2019 or 2022 firewall may state that it is off, it kind of isn’t.

So to resolve this issue we had run a couple of commands on the new 2919\2022 domain controllers and the problem was solved , so here are the commands.

1.netsh advfirewall firewall add rule name=”Quest Migration Manager Agent” dir=in action=allow program=”%SystemRoot%\System32\AelAgentMS.exe”

2.netsh advfirewall firewall add rule name=”Quest Migration Manager Agent” dir=in action=allow program=”%SystemRoot%\System32\AelAgentMS64.exe”

Now we can migrate SID history with user accounts,

Using the location condition in a Conditional Access Policy

Microsoft have released a new feature in Conditional Access where named locations can be defined by country GPS coordinates. The Microsoft Article can be referenced HERE

Conceptual Conditional signal plus decision to get enforcement

This is a great improvement in protecting against bad actors. A lot of my customers’ often ask me to create a conditional access policy to block access for all countries except Europe, Ireland and the UK. Bad actors could simply use a vpn and then specify what country they are connecting from which can then by-pass the conditional access blocking bad actors based on country IP, where they cannot by pass GPS coordinates

How to assign Microsoft Defender for EndPoint Policies

The first task is to assign a security group with all users in scope for Microsoft Defender for Endpoint via Azure Licensing Mnagement.

The second part is to apply the policies to a group of users. The syntax below can be used to create an Azure Dynamic user group which will auto populate based on whether a user has a license for Microsoft Defender for Endpoint.

user.assignedPlans -any (assignedPlan.servicePlanId -eq “111046dd-295b-4d6d-9724-d52ac90bd1f2” -and assignedPlan.capabilityStatus -eq “Enabled”)

Phishing Email

Quite a nasty phishing email that sailed past Mimecast and Microsoft Defender for ATP.
It brings the user to a site and the the end user clicks on another link to listen to their voicemail and this is when the payload is delivered and it can perform the following malicious acts

Copy cached credentials
Modify Outlook Rules
Infect the entire global address list
Attempt data exfiltration via One Drive for Business

Phishing email displayed below , Careful folks. End user security awareness training is the best defense against the phishing emails that get through and breach your message hygiene services.


Conditional Access Insights and Reporting

Conditional Access Schematic

One of the most desirable Conditional Access policy controls is to only grant access to cloud applications if the Windows 10 devices are Azure AD Hybrid joined.

To ensure all Windows 10 devices are Azure AD Hybrid joined can be quite tricky , It is not as simple as enabling Azure AD Hybrid join in the AD connect wizard and simply synching an organizational unit that contains all of the Window 10 machines

The Windows 10 devices must be able to communicate with the Microsoft Office365 and Intune endpoints.

Microsoft Azure AD Conditional Access Policy – Report Mode only has been available for some time, however trying to demonstrate and analyze the impact of enabling the new conditional access policy was quite difficult when trying to review the activity for the new policy in the Azure AD sign in logs or even via a csv export of the policy activity.

Microsoft released Conditional Access Insights and Reporting : Overview and setup available HERE Power BI can also connect to the Log Analytics workspace to create custom dashboards if required.

Now when attempting to review conditional access policies in report mode only and in this example the policy is a report mode only if devices were blocked from signing in unless they were Azure AD Hybrid joined.

The impact summary is simple to read and break down

The next page summarizes user sign in details and which users would be impacted most by enabling the policy and then allow IT administrators to take action and get the users \ devices compliant before enabling the policy.