About Sean O'Farrell

Behind the scenes of this blog is me, Seán O'Farrell. I am a Solution Architect with Evros Technology Group in Dublin, Ireland. You can find me on Linkedin My blog posts are completely my own views & provide no warranty. My blog posts are in no way affiliated with my current employer, Microsoft, Quest or any vendor’s technologies mentioned in my blog. I started my blog in 2009 and at this point in time I was not even aware of the Microsoft MVP programme, having a family and a very busy career in some ways held me back from the commitment it takes to obtain the prestigious MVP award. A lot of my colleagues that I have worked with for over 10 years are MVPs. Over the years some of my clients have presented my blog posts by searching the net to resolve problems and some vendors have officially published some of my blog posts. I acquired the domain informationprotection.ie, I was surprised the domain name was available, given all the so called GDPR experts that have suddenly appeared. I have focused on Office365 since before BPOS and the Office365 platform is now a mature platform, the Office365 skillset is not so special anymore and a standard requirement for most IT professionals, Since the start of 2018 nearly all of my professional services engagements have been focused on Office365 & Azure security. I am going to try and focus on Microsoft cloud security with this blog and invite guest peers to post security blog postings. I do not want to post generic material and always want to post items that are unique and will help people in the industry. If you have found the blog helpful in any way, and/or like what I am doing, please nominate me for the Microsoft MVP award here. It's very quick and easy, fill in your own details, then the details in the screen grab below for me. Thank you!

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

Microsoft Authenticator Password less Authentication

Microsoft are consistently adding new features to Microsoft Authenticator, which have been very well received by organizations that use their cloud services. One of the new features that Microsoft has released is a feature called ‘Password less’

A lot of my pharmaceutical and financial customers love this feature as it improves their security posture. This blog will provide a high level guide on how to enable ‘Password less’

1:The following technical steps describe how to set up password less authentication. To successfully roll out password less in any organization, I would recommend running a pilot, with the IT department and some additional departments, when the pilot phase has successfully come to conclusion, and all feedback from the pilot users has been addressed and remediated, the next step, is a production roll out.

2:When logged into Azure Active Directory, browse to user settings \ user features \ manage external collaboration settings. This feature may be automatically enabled if it is a new M365 tenant

3:Select All in the ‘Users can use the combined security information registration experience

4:It is also possible to use the Microsoft Graph to manage users’ authentication methods to enforce global policies for large organizations’ which will reduce help desk calls and can accelerate the roll out of this new authentication method.

5:Users must register the Microsoft Authenticator app as an authentication method before they can use password less sign-in. If users have already registered Microsoft Authenticator for use with multifactor authenticator, they won’t need to re-register the app for use with password less sign-in.

I always provide easy to follow user guides with screenshots for my customers and my customer’s IT department or communications department to submit to their users’ well in advance of going live with the new password less authentication method.

6:A really important step is to enforce MFA registration policy which is a component of Azure Identity Protection. MFA registration policy is a feature of Azure Active Directory Premium Plan 2 – Identity Protection.

Not all customers can afford the additional cost of Azure Active Directory Plan 2, M365 E5 or M365 A5. An alternative to using Azure Active Directory  Plan 2 is Azure Active Directory Plan 1, Which can be configured to use conditional access policies to enforce the user to register their security information, if they have not signed in previously or before, the new conditional access policies have been applied.

7:In the Azure Portal select Authentication methods in the Security section of Azure Active Directory.

8:Click Microsoft Authenticator in the list of methods.

9:Select a security group that contains your pilot users, When the pilot has successfully concluded, Then the password less configuration can be applied to ‘ALL users’

10:For a single user: Select the …

11:Then click config

12:For the end user and pilot users , they can browse to this location https://mysignins.microsoft.com/security-info  if the ICT admins of the M365 tenant have not already set up Microsoft Authenticator as the as the default sign in method, the end user can select Microsoft Authenticator as the default authentication method.

13:Select Passwordless

14: Next step is to sign into https://aka.ms/mfasetup

15:Set up Microsoft Authenticator

16: Continue setup

17:Within the Microsoft Authenticator application, select add a Work or School account and choose the option to ‘Scan the QR code’

18:The next step is to hit continue as per image below

19:So how does password less work, when an end user wants to authenticate a six digit code is sent to the Microsoft Authenticator application, and the end user must enter the six digit code, and then authenticate via bio metric thumb print or pattern.

20:The end user may receive the error displayed below, if they have multiple organizations’ set up with MFA hosted on their Microsoft Authenticator application. Like myself working in IT, I have many customers registered in my Microsoft Authenticator application.

21:Didier Van Hoye describes the issue perfectly in his blog post

22:In a green field site, Password less is a very well received as a new method of authentication and to protect organizations’ identity. It takes end users a little bit of time to become familiar with password less authentication, but once they are familiar with this authentication method, they find it a lot easier than traditional passwords and it improves an organizations’ security posture.




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”)

How to begin your data classification journey

The container and content classification graphical representation above represents a high-level starting point around formalizing your data classification requirements. Microsoft have created an innovative solutions suite around data protection that is scalable for small, medium and enterprise requirements.

In some Sectors data classification has already been implemented and applied as part of the general operational procedures to support regulatory compliance (i.e., Pharma and Finance).

Since data classification has been established, it has been expanded to 204 different sensitive information types as defined by Microsoft in compliance.microsoft.com

Policy creation can be created easily to protect personally identifiable information via DLP (data loss prevention), classification and retention policies by using these sensitive information types that Microsoft provide as part of their Office365 platform.

Regex101.com is a free utility that provides the ability to create regular expressions (regex) and test the regex against input of a sensitive information types.

As an example, to implement – within the Office365 platform, Microsoft only provide three sensitive information types applicable to Ireland:

  • Ireland Driver’s License Number
  • Ireland Passport Number
  • Ireland Personal Public Service (PPS) Number

There is however some more common sensitive information type unique to Ireland as follows:

  • Eircode
  • Mobile phone number
  • Landline phone number

Regex101 also provides a regex library to cater for a particular sensitive information type.

The European Union caused quite considerable anxiety when the GDPR regulation was released during 2018.

The GDPR regulation’s primary purpose is to provide individuals control over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.

Regrettably, this regulation does not protect an organization’s intellectual property.

Use cases listed below could however enable organisations to protect their intellectual property more effectively:

  • Food Industry: Using document fingerprinting and if working for Coca Cola or Guinness and an employee attempts to leak the secret recipe. Office365 can prevent this.
  • Manufacturing Industry: If a patent or manufacturing process were attempted to be shared outside the organization to that organizations’ competitors, it could cause the source organization to lose market share or cease to exist. If an employee sends an email with 100 mobile phone numbers or 100 land line phone numbers, this could be classed as data exfiltration and the employee is leaking their employers’ customers information to a competitor.
  • Technology Industry (Nokia, Ericsson or Huawei): may invent the next Wi-Fi standard and before the company that invents the technology registers the patent for this new technology and the information is leaked to one of their competitors, it could cause billions in lost revenue.
  • Legal industry: GDPR in certain scenarios can mandate that data is deleted after 7 years. This can really suit legal organization’s as they are no longer liable if the data has been permanently destroyed via a retention policy.
  • Pharmaceutical Industry: The first company that manufactures a permanent vaccine for Covid 19 and all Covid variants that successfully patents the solution would not like their intellectual property falling into the hands of their competitors.

AIP (Azure Information Protection) scanner is generally the initiation point of data classification as it can scan file shares and on-premises SharePoint farms. To prove the benefit of data classification, define some sensitive information types for an organization. Use AIP scanner to integrate with an Azure Log Analytics workspace and then demonstrate to an organization, how much of their critical intellectual property is not protected.

The basic overall implementation approach to enable data classification is as follows:

  • Monitor
  • Provide Tips
  • Protect.

AIP scanner can auto classify data, depending on the organization’s Office365 license plan, but this is all useless unless the organization has begun their data classification journey. Obviously sharing a credit card number is the most common instance of data loss prevention, but what about protecting critical intellectual property for an organization.

Another use case is when an organization has already begun their data classification journey with another vendor like Forcepoint, Symantec or McAffee. If Office365 is in the organization’s roadmap then it is easy to transfer all the custom sensitive information types and regexs’ into Office365. Regex is a universal standard and works across all vendors.

Cyber Attacks are most commonly associated with phishing attacks and most commonly performed by BOTs on the dark web, however in a targeted attack and when the bad actor’s are trying to specify the exact information they are trying to steal from an organization, if this information is classified then there is a very strong chance the bad actors attempt to steal the information will be unsuccessful and the attack will generate alerts and notify the security admins of an organization.

Microsoft have also introduced some new technology: trainable classifiers. Trainable classifiers introduce the power of Azure and AI (artificial intelligence). An organization can choose not to classify their data but let a trainable classifier analyze their data and then report on all the known sensitive information types defined in an organisation’s Office365 tenant.

A Microsoft 365 trainable classifier is a useful tool you can train to recognize various types of content by giving it samples to look at. Once trained, you can use it to identify information for the application of Office sensitivity labels, Communications compliance policies, and retention label policies.

Source: Get started with trainable classifiers – Microsoft 365 Compliance | Microsoft Docs

The security component to complete the overall Microsoft suite was lacking but has been resolved by Microsoft releasing Microsoft Defender for EndPoint. Microsoft Defender for Endpoint integrates seamlessly with MCASB (Microsoft cloud app security broker) and enforces corporate security policies for devices that are not connected to the corporate LAN – which is a likely scenario, during the current Covid-19 Pandemic.

Exchange 2016 CU20 ECP\OWA not available

After a clean successful installation of Exchange 2016 CU20 and reboot on completion of the installation. I was presented with the following error when trying to login to the ECP and OWA.

###########################################################

Now this was a unique scenario. There were two Exchange 2013 production servers patched to the highest level and each Exchange 2013 server had a certificate issued from an internal certificate authority, the certificate included all of the required subject alternate names, but the certificate was also acting as the Microsoft Exchange Server Auth server on the Exchange 2013 servers and included .local domain names.

The design decision to introduce Exchange 2016 to the environment was purely to act as an Exchange Hybrid and not touch the production Exchange 2013 servers.

I installed Exchange 2016 CU20 with April 2021 security patches and got the errors listed above. Exchange Management Shell access was fine. I decided to install an additional Exchange 2016 CU19 server to see if CU20 was buggy. But unfortunately I received the same error on the fresh build of Exchange 2016 CU19 server.

The Exchange 2016 servers did not have rights to the private key of the certificate issued by the internal certificate authority that was in use by the Exchange 2013 servers as the Microsoft Auth Server certificate and the Exchange 2016 servers picked up this cert by default as it was in use in the existing Exchange organisation.

So how did i resolve this issue??

Firstly I created a new Microsoft Server Auth certificate with the following commands

New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName “CN= Microsoft Exchange Server Auth Certificate” -DomainName “*.contoso.com” -FriendlyName “Microsoft Exchange Server Auth Certificate” -Services SMTP

$date = Get-Date

Set-AuthConfig -NewCertificateThumbprint <certificate_thumbprint> –NewCertificateEffectiveDate $date

Set-AuthConfig –PublishCertificate

Set-AuthConfig -ClearPreviousCertificate

IISRESET

Powershell Commands Ref this article

The next thing was to export the newly created certificate and import the certificate into the computer trusted root certification authorities location on each Exchange server.

Next we need to review and run the commands described in this Microsoft KB

Next we rename the sharedwebconfig file in the following directories to sharedwebconfig.bak.
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy

Then follow the steps in this Microsoft KB

But replace the environmental variable in the two commands specified in the article ‘%ExchangeInstallPath%’ with the actual install path as the install path can change from the default locations defending on the Exchange build and the environmental variable ‘%ExchangeInstallPath%’ may not resolve in the Exchange management shell.

Run the commands and then restart the server and all should be fine , at this point you can import a trusted certificate like DigiCert and assign IIS & SMTP services to the certificate.

And run a health check on the Exchange 2016 server and – Get-ServerComponentState