Tag Archives: microsoft 365

M365 Data Desired State Configuration (DSC) M365 Data Use Cases

Posted on by
Reply

The Microsoft website : https://microsoft365dsc.com/ explains all things, regarding Microsoft DSC, including configuration, export, import, synchronisation etc..

Microsoft have made things a lot easier compared to earlier versions of Microsoft365 DSC. It is now possible to select which configuration policies can be backed up and re-used from the numerous M365 technologies via the Microsoft365DSC Portal: https://export.microsoft365dsc.com

This blog post will focus on the most common M365 configurations that can be re-used in multiple M365 tenants, to speed up deployment and also remove human error, which can often occur from manual configuration.

Where to start

Browse to https://export.microsoft365dsc.com/ and then select the configuration items per M365 technology, that you would like to re-use in, another M365 tenant, tenants’ or a research and development M365 tenant.

Microsoft Entra ID \ Azure Active Directory

The items highlighted in yellow, could be potentially be used per M365 tenant, tenants’ or a research and development M365 tenant.

Items : Highlighted in red

Microsoft have recently added, conditional access templates, which was a very welcome addition, however, I still prefer to use PowerShell to implement Conditional Access Policies, which can be unique per organisation.


Exchange Online

The items highlighted in yellow, could potentially be used per M365 tenant.
I do not like using the Exchange Online, standard and strict protection templates, as they cannot be re-configured.

My preference is to run an Exchange Online Orca Report and then review the recommendations and tweak the configuration per organisation. Microsoft Exchange Online security policies should always come first.

Intune

Intune DSC, for me, this is by far the most beneficial use case.

Device security ( Jeffrey Appel’s : Defender for Endpoint – Ultimate Blog Series)
Jeffrey’s blog series, doesn’t just focus on Microsoft Defender for Endpoint configurations, it includes a lot of Windows 10 and later, hardening policies, which should be used in every organisation. It takes a long time to configure these policies! M365 DSC can, re-use these configurations polices, if Jeffrey, updates his blog series, the change can be made in a research and development M365 tenant, tested and then pushed to a production tenant.

The following images that contain items highlighted in yellow , could be potentially used per M365 tenant.

Additional M365 DSC modules

  • Office 365 : do not re-use per M365 tenant
  • OneDrive: do not re-use per tenant, however an Intune ‘IntuneDeviceConfigurationAdminisrativeTemplatePolicyWindows10; can be re-used to configure One Drive for Business configuration and governance
  • Planner : do not re-use
  • Power Platform : do not re-use
  • Security and Compliance: do not re-use, (unique per organisation)
  • SharePoint : do not re-use, (unique per organisation)

Teams

The following images that contain items highlighted in yellow , could be potentially be used per M365 tenant

Summary

This blog post , attempted to highlight the practical and beneficial usage of M365 DSC.

An IT services provider can, standardise configurations in line with best practices and re-use these configurations per customer.

Microsoft consistently drives innovation and adaptability to meet evolving industry demands.

An organisation can test emerging M365 technologies in a research and development M365 tenant, and when the organisation has completed testing etc, the configuration can be synchronised to the organisation’s production tenant or tenants’, which can control and mitigate risks, with regards, simply allowing an M365 tenant accept all new and emerging technology features from Microsoft. It can also accelerate the adoption of new and emerging technology features from Microsoft, when an organisation has fully tested these new features and is ready to deploy the new features in their production tenant or tenants’

If anyone, or any organisation would like some further assistance with this, please get in touch with me via LinkedIn : https://www.linkedin.com/in/seanofarrelll/

Just in Time Access for M365 Purview Roles

Posted on by
Reply

Microsoft’s unwavering commitment to security and compliance has consistently driven innovation and adaptability to meet evolving industry demands. Their dedicated security and compliance portals have left the legacy portal, portal.office.com, in the not too distant past.

One common frustration for M365 administrators is the inability to assign the following roles within Microsoft Privileged Identity Management:

  • Microsoft Purview roles’
  • Microsoft Defender roles’
  • Microsoft Dynamic roles’

    This blog post will primarily delve into the assignment of Microsoft Purview roles. The image below showcases the default role assignment choices available in Microsoft Privileged Identity Management.

Microsoft Purview Roles

Microsoft has invested significantly in their portal redesign at compliance.microsoft.com. In traditional scenarios, IT administrators often find themselves tasked with configuring, executing, exporting e-discovery case results, and subsequently reporting to compliance officers, data protection officers, or HR departments. However, entrusting IT admins with these compliance tasks raises initial concerns about data protection. It’s imperative that IT admins remain unaware of sensitive information contained within e-discovery case results, as these results might encompass IT admin staff within the search criteria.

As of the time of this post, there are approximately 95 role groups within M365 Purview. Here are some practical use cases illustrating how these roles can be assigned to fulfil various compliance roles and organizational requirements:

  • e-discovery
  • Insider Risk Management
  • Privacy Management
  • Data Investigator

How to Assign Microsoft Purview Roles to Microsoft Entra ID Groups

Note: For the purposed of this blogpost, I created a Microsoft CDX tenant, all users and screenshots are fictional.

1: Create a Microsoft Entra id group. Important, to not add any members or owners

2: Login to Microsoft Entra Privileged Identity Management and select Groups.

3.Seclect Discover Groups

4.Search for the previously created group and then select manage groups

5.Select groups in Privileged Identity Management

6. Click on assignment, add members to eligible assignments, this is why , we did not need to add any group members in step 1

7. Click on settings and member

8. Edit the member settings

9. Set hours to 4, require justification on activation, require approval to activate and then finally select the approver. The approver may be different per role that requires activation.

10. Create a role group in the compliance.microsoft.com portal : Microsoft Purview Permissions

11. Name the role group

12. Add the roles.

Select all roles

13. Choose groups and add the group that was created previously

14. Now the end user Adele Vance can login to https://entra.microsoft.com /identity governance / Privileged Identity Management and select ‘Activate just in time’

15. The user then selects group, activate and provides a business justification.

16. The group owner and admin , receives an email notification, that there is a pending just in time access request and can choose to approve or deny the request.

17. The compliance officer can then login to complicane.microsoft.com and perform his\her compliance activities. During my testing, no license was required for the compliance officer. I am sure Microsoft would insist that the compliance officer has an M365 E5 or E5 compliance add-on license:)

Summary

The technical steps outlined in this blogpost, enable organisations to apply Privileged Identity Management policies to roles \ permissions control in services like

  • Microsoft Purview roles’
  • Microsoft Defender roles’
  • Microsoft Dynamic roles’

M365 Purview roles are not available in M365 roles or Microsoft Entra ID Privileged Identity Management, for really good reasons. M365 Purview role \ permission elevation , can be typically required for legal disputes.

Every organisation, should consider compliance and governance with a cloud transformation journey where services, data and line of business workflows, transition from on-premises to Microsoft cloud services.

If anyone, or any organisation would like some further assistance with this, please get in touch with me via LinkedIn : https://www.linkedin.com/in/seanofarrelll/

Securing M365 mail routing : SCENARIO 3

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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