Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierOffice365

How to Create an Emailable Exchange Distribution List with Internal and External Contacts?

Scenario:

If you need a distribution list in Exchange that includes both internal organization contacts and external contacts—without requiring external users to be invited as guest accounts—there’s a simple way to achieve this.

In Exchange Online, external contacts are referred to as Mail Contacts. These allow you to add external email addresses to your organization’s address book, making them available for inclusion in distribution lists. By leveraging Mail Contacts, you can create a fully functional distribution list that includes both internal users and external recipients while keeping everything manageable within Exchange.

Managing email distribution lists efficiently is crucial for organizations that need to communicate with both internal and external contacts. While Exchange Online allows us to create Mail Contacts programmatically using PowerShell scripts or the Exchange Online Management API, automating this process is key—especially when integrating it with Dynamics 365 Marketing Lists.

The Automation Challenge

In my case, I wanted to automatically add new contacts from a specific Dynamics 365 Marketing List to a corresponding Exchange Distribution List. Initially, I considered using Power Automate to invoke a PowerShell script, but that introduced additional complexities:

  • Using Power Automate to trigger an Azure Automation Runbook
  • Managing authentication and execution permissions
  • Handling execution timing and monitoring

A More Efficient Approach: Logic Apps

Instead of relying on Power Automate, I found a better and more streamlined approach—using Azure Logic Apps. Unlike Power Automate, Logic Apps offer built-in functionality to create and execute Runbook Jobs directly within Azure Automation.

What This Blog Covers

In this post, I’ll walk you through:
✅ Setting up an Azure Automation Account
✅ Creating a Runbook to execute a PowerShell script that adds Mail Contacts
✅ Using Azure Logic Apps to trigger the Runbook
✅ Handling authentication across these services

By the end, you’ll have an end-to-end automation setup that seamlessly adds external contacts to Exchange Distribution Lists as soon as they join a Dynamics 365 Marketing List—without requiring manual intervention.

Let’s dive in! 🚀

Step 1: Set up the Azure Automation Account

  1. Log in to Portal Azure https://portal.azure.com/ and in the search box, type Automation Accounts


2. Click on Create, Select your Subscription and Resource group, and type in the Automation Account Name

2. Then click the Advanced Tab, and on the Managed Identities, select User Assign; we will set up the User Managed Identity in the next steps.

3. Click Review and Create.

Step 2: Setup the User Managed Identity

A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Managed identities eliminate the need for developers to manage these credentials.

A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Managed identities eliminate the need for developers to manage these credentials.

While developers can securely store the secrets in Azure Key Vault, services need a way to access Azure Key Vault. Managed identities provide an automatically managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication. Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials.

So Let’s see how to setup the account with the Required Permissions!

  1. On the Search, Type Managed Identities

2. Click Create, Select the subscription, Resource group, and give it a name

3. Then Press Review and Create

4. Open the automation account that we have created in Step no. 1

5. Search for Identity, open the link, select user assigned, and click Add.

6. Add the managed identity that we have just created.

7. Next comes setting the Permissions for the Managed Identity, so go back and open the Managed Identity.

8. Go to Azure Role Assignments and add the Automation Contributor Role; this is required to enable the Logic app to execute the RunBook (we will be creating this in the next step) on the automation account.

9. Grant the Exchange.ManageAsApp API permission for the managed identity to call Exchange Online, Unfortunately, this step can’t be done through the Azure / Entra Portal, so we will be using Graphy API Explorer to achieve this.

Get the Managed Identity’s Object ID

Get Exchange Online Service Principal ID

Open Grap API Explorer, Login ,and run the below query and grap the Exchange online service Principal ID

Method: Get

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '00000002-0000-0ff1-ce00-000000000000'

Assign the Exchange.ManageAsApp Permission

Using Graph Explorer API again, use the below to assign the Exchange.ManageAsApp Permission

POST https://graph.microsoft.com/v1.0/servicePrincipals/{MANAGED_IDENTITY_OBJECT_ID}/appRoleAssignments
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "principalId": "{MANAGED_IDENTITY_OBJECT_ID}",
  "resourceId": "{EXCHANGE_ONLINE_SERVICE_PRINCIPAL_ID}",
  "appRoleId": "dc50a0fb-09a3-484d-be87-e023b12c6440"
}

10. Assign Microsoft Entra roles to the managed identity; you will need to assign the Exchange Administrator Role

In the Search type role and select Microsoft Entra Roles and administrators

11. Open Exchange Administrator Assignments and add the user Managed Identity by clicking the Add Assignments Button .. Global administrator privileges will be required for this.

Step 4: Import Exchange Management Modules

  1. Open the Automation Account that we have created in step 1
  2. Navigate to Shared Resources -> Modules
  3. Click Add Module

4. Click Browse from gallery

  1. Open the Automation Account
  2. Navigate to Process Automation -> Runbooks
  3. Search for PackageManagement and select and choose the Runtime Version 5.1

4. Repeat for Add PowerShellGet and choose Runtime Version 5.1

5. Repeat for ExchangeOnlineManagement and choose Runtime Version 5.1

Step 5: Create a runbook in Azure Automation

  1. Open the Automation Account
  2. Navigate to Process Automation -> Runbooks
  3. Click on Create a runbook. Make sure you are using Runtime Version 5.1 because PowerShell works only for this Version

4. Open the Run Book and click Edit in Portal.

5. Paste the below Powershell Script that connects to exchange

//The below piece of code sets parameters on the run book so that when called from a logic app we can pass these parameters to the run book.
param (
    [string]$MailContactName,
    [string]$MailContactEmail,
    [string]$DistributionList
)
// Connects to Exchange online via the managed Identity that have been setup in step 3
Connect-ExchangeOnline -ManagedIdentity -Organization Organisationdomain.onmicrosoft.com -ManagedIdentityAccountId {Managed Account Identity ID}

//Creates a mail contact in Exchange
New-MailContact -Name $MailContactName -ExternalEmailAddress $MailContactEmail

//Add mail Contact to the Distribution List
Add-DistributionGroupMember -Identity $DistributionList -Member $MailContactEmail

6. After that Click Save and Publish

7. You can then test the runbook by clicking the Test Pane on the Edit in Portal Screen of the runbook, entering the parameters and clicking start.

Step 5: Create the Logic App

So the Logic app will be created in a schedule and can query any enterprise connector like dataverse and then call the runbook that has been created in Step 5

  1. From the Azure Portal , Look for Logic Apps and click Add
  2. Choose the Hosting Plan, and here you can select the Consumption plan

3. Select the subscription, the Resource Group and add the logic app name

4. Click Review and Create and then Create

5. On the created Logic app, search for Identity, Navigate to user assigned and add the Managed identity created in step 2

5. Navigate to the Logic app designer. On the Add Trigger step, choose schedule and set the recurrence schedule. Then, add Action and look for Create Job and select the one under Azure Automation

6. Set the Connection Name and Choose the Authentication Type as Logic Apps Managed Identity

7. Select the Subscription, Resource Group, Automation Account, Run book and pass the required Parameters

8. Save and test the Logic App

Resources:

https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

Allow use of custom scripts in SharePoint Online using PowerShell

SharePoint online is a powerful platform that allows users to create and manage websites and content, collaborate with others, and more. However, SharePoint out-of-the-box features may not always meet the specific needs of your organization.

Fortunately, SharePoint online allows the use of custom scripts, which can be used to enhance the platform’s functionality and customize it to your specific needs.

When you allow the use of custom scripts in SharePoint online sites, users gain access to a wide range of features and functionalities. Here are some of the key capabilities that become available:

  • Web Parts: Users can use classic experience web parts like Script Editor, Content Editor (and lot more) using which they can create custom web parts using client-side scripting languages like JavaScript or TypeScript.
  • Use of Save Site as Template, Save document library as template, etc. features in SharePoint.
  • Use of Solution Gallery, Theme Gallery, Sandbox solutions, HTML Field Security, etc. settings in SharePoint sites.
  • Uploading files types that are blocked by default like .asmx .ascx .aspx .htc .jar .master .swf .xap .xsf

Let’s see how you can allow or prevent use of custom scripts in SharePoint Online sites using different PowerShell tools:

Using SharePoint Online PowerShell

Use below SharePoint Online PowerShell script to check if custom scripts are enabled or disabled for a SharePoint online site and then to allow use of custom scripts for specified SharePoint online site:

# SharePoint online admin center URL
$adminCenterUrl = "https://contoso-admin.sharepoint.com/"

# SharePoint online site URL
$siteUrl = "https://contoso.sharepoint.com/sites/SPConnect"

# Connect to SharePoint online admin center
Connect-SPOService -Url $adminCenterUrl

# Allow custom scripts on SharePoint online site
Set-SPOSite $siteUrl -DenyAddAndCustomizePages 0

# Verify that custom scripts are enabled on SharePoint online site
Get-SPOSite $siteUrl | select DenyAddAndCustomizePages

Using PnP PowerShell

You can use below PnP PowerShell script to allow or prevent use of custom scripts in SharePoint online site:

# SharePoint online site URL
$siteUrl = "https://contoso.sharepoint.com/sites/SPConnect"

# Connect to SharePoint online site
Connect-PnPOnline -Url $siteUrl -Interactive

# Allow custom scripts on SharePoint online site
Set-PnPSite -NoScriptSite $false

# Prevent custom scripts on SharePoint online site
Set-PnPSite -NoScriptSite $true

Using CLI For Microsoft 365

Use below CLI for Microsoft 365 script to allow use of custom scripts in SharePoint online site collection:

# SharePoint online site URL
$siteUrl = "https://contoso.sharepoint.com/sites/SPConnect"

# Connect to SharePoint online tenant
$m365Status = m365 status
if ($m365Status -match "Logged Out") {
    m365 login
}

# Allow custom scripts on SharePoint online site collection
m365 spo site set --url $siteUrl --noScriptSite $false

Conclusion

Enabling custom script support for SharePoint online sites can enhance the platform’s functionality and enable users to customize site to their specific needs. However, it’s important to carefully consider the potential security risks before enabling this feature, check: security considerations of allowing custom scripts in SharePoint.

Learn more

Azure AD Connect Cyber attacks, New AI features for industry, Fun Teams Features & more: Practical 365 Podcast S3 E25

In the show this week, Paul and Steve discuss a cyber attack reported against Azure AD Connect that inflicted a vast amount of damage to a business, Snapchat filters in Teams, two new changes to the Graph API and Microsoft Teams Rooms on Android, and more!

The post Azure AD Connect Cyber attacks, New AI features for industry, Fun Teams Features & more: Practical 365 Podcast S3 E25 appeared first on Practical 365.

Microsoft Launches Security Copilot

Microsoft's announcement of Security Copilot is more interesting in some respects than Microsoft 365 Copilot because it promises to help organizations defend themselves better. Of course, we don't know much yet about how Security Copilot will work in the real world, but if Microsoft delivers what it says, Security Copilot could be quite a tool in the battle against the bad guys.

The post Microsoft Launches Security Copilot appeared first on Practical 365.

Limit who can create Microsoft Teams – Quick tutorial

For governance reason you need to configure who can create Office 365 Groups in Outlook, Teams or SharePoint Site ?

There are no out of the box way to disable in two click. For SharePoint Sites, it is possible to disable the creation by everybody from the SharePoint admin.

But why disabling Teams Creation for everybody ?

If not, you could end up with so many Teams without business context, way to know when to archive them and without knowing who is the main responsible for this workplace. Some companies want this to test out the product but once you want to ensure two groups doesn’t serve the same purpose : Office 365 Admin needs to block the creation authorization that every users have by default.

So below is a procedure for the Office 365 Admin, to restrict who can create Office 365 Groups.

This is a summary of this microsoft article

To go further, Chris Obrien has created a tutorial to allow users to request Office 365 Groups using SharePoint list and Flow

Tutorial objective

Limit who can create Office 365 Groups. Groups are created when you create a new TEAM / Planner / Outlook Group / SharePoint Site

Pre requisite

  • Global admin access
  • Office 365 Admin center access
  • PowerShell

Steps

For info, you will need to add users to a security group, to allow only certain people to add office 365 Groups

Step Detail
Install PowershellGet Install-Module -Name PowerShellGet -Force
Install or re install azureADPreview Uninstall-Module AzureADPreview

Install-Module -Name PowerShellGet -Force

Create security group, https://admin.microsoft.com/AdminPortal/Home#/groups

New > Security Group

Add inside the group who can create office 365 Groups Filter security groups only

Click the group, click edit

  Import-Module AzureADPreview

Connect-AzureAD

Run those commands

 

If you get an error in last command, ignore it

Get-AzureADGroup -SearchString “Office 365 Groups Admins”

$Template = Get-AzureADDirectorySettingTemplate | where {$_.DisplayName -eq ‘Group.Unified’}

$Setting = $Template.CreateDirectorySetting()

New-AzureADDirectorySetting -DirectorySetting $Setting

  $Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ).id
  $Setting[“GroupCreationAllowedGroupId”] = (Get-AzureADGroup -SearchString “Office 365 Groups Admins”).objectid

Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ).id -DirectorySetting $Setting

Verify that your group can create Office 365 Groups

It shows the id of your group

(Get-AzureADDirectorySetting).Values
If you want to cancel this configuration, run this command $SettingId = Get-AzureADDirectorySetting -All $True | where-object {$_.DisplayName -eq “Group.Unified”}

Remove-AzureADDirectorySetting –Id $SettingId.Id

Verify by trying to create a team or planner, with a non admin account


Wrap up

Disabling Teams Creation for everybody is the pre-requisite for Digital Workplace Team to implement a request system for Teams, Office 365 Groups.

The post Limit who can create Microsoft Teams – Quick tutorial appeared first on Collabmania.

Practical Protection: Dr. Jekyll and Mrs. Hybrid

Hybrid work is really a mixed blessing—while it offers a lot of fantastic benefits for people who are able to take advantage of it, it can introduce some new and unpleasant security issues that you need to be prepared to deal with. This article dives into these new risks and how you can avoid them.

The post Practical Protection: Dr. Jekyll and Mrs. Hybrid appeared first on Practical 365.

Five Things Microsoft 365 Security Administrators Should Do in 2023

Microsoft 365 security is a big topic. Focus is important when it comes to getting things done. In this article, we suggest five areas that administrators could work on during 2023 to improve the security posture of their tenant. You might already have established full control over some of these areas. Even if you have, it's still good to consider if you can improve security.

The post Five Things Microsoft 365 Security Administrators Should Do in 2023 appeared first on Practical 365.

A friendly reminder about least privilege access and other simple stuff

I just spent an exhausting 36 or so hours helping a customer out of a really bad situation. Well, technically they aren’t out of the woods yet, but things are clearing up anyway. And I am at the point now where I exit, handing off the bulk of remaining tasks to their internal team. I won’t go into the gory details (the customer did give me permission to share VERY limited information, but I am going to keep it even more generic here). What I will tell you is that it all came down, once again, to negligence of cyber essentials. Specifically, I want to take this opportunity to remind my readers about the importance of least privilege access and basic hygiene especially for admin accounts. I believe this is probably one of the most often overlooked items in terms of basic principles of cybersecurity. And I still don’t know why.

On the one hand, I get it: we do not always have time to dot every “i” or cross every “t”: how many of us can truly say with a straight face that we are 100% certain every single user and service account under our care has only the access required for its specific function, and no more? I think the number is very small.

But you know what? I am not going to ask you to wipe out your calendar in order to tackle a full audit and access review of all the accounts and permissions in your environment. Nope, not today. All I want you to do is mind some of the most basic rules of least privilege access, paying special attention to your “superuser” or “global admin” accounts.

Many organizations take a laissez-faire attitude when it comes to admin or “super-user” privileges in their environment. Especially as regards third-party apps. For example, it is not uncommon for employees to randomly adopt software packages or subscriptions and manage them independently of IT. Oftentimes, this is happening without any knowledge or consent from business owners, IT stakeholders, or other management (this is so-called “Shadow IT”). Worse yet, whenever I audit Microsoft 365 tenants, I regularly find that too many people have full global administrator privileges here as well, and those permissions often exist on “everyday” accounts which are also used for email and file sharing.

So here are the (bare minimum) five rules I wish everyone would follow with respect to their admin accounts, and yes, you have time to do this list:

  1. Minimize the number of accounts with Global administrator privilege: Microsoft recommends a maximum of 5 global admin accounts. This should be achievable in an SMB environment. Use built-in RBAC roles to limit privileges as needed (e.g., delegate Billing administrator, Helpdesk administrator, etc.). Find a list of Azure AD roles and permissions here.
  2. Make sure privileged accounts are separate from normal user accounts: Primary user accounts with access to apps and email should not be used for administrative purposes; for example, if Mary Contrary is an employee with an email address and UPN of Mary.Contrary@contoso.com, she should use a completely separate account for performing administrative tasks such as Mary.Admin@contoso.onmicrosoft.com.
  3. Do not reuse admin credentials across domains or services: This is a big one. I know, I know: it is so much easier to rely on muscle memory everywhere you work, but seriously, you have to stop this egregious practice. We have password managers for a reason. This rule applies to using the same credentials in multiple cloud apps, in different on-premises domains, and/or in Microsoft 365 tenants, as well as the all-too-common scenario where the same identity is used as an admin account on-prem and in the cloud through Directory Synchronization (Azure AD Connect / Cloud sync). Just do not do this. Do not do any of this.
  4. Require strong authentications for ALL your admin accounts: Yes, this includes emergency access accounts. Even if you are excluding admin accounts from every Conditional Access policy in Azure AD, you should still plan on using something to protect that account (per-user MFA with an alternate sign-in method, anything). Read more about emergency access accounts here: Manage emergency access admin accounts.
  5. If you are a Microsoft partner managing lots of tenants, implement GDAP: Granular Delegated Admin Privileges (or GDAP) replaces legacy DAP, and allows partners to manage least privilege access, so that their employees no longer have to use only the Global admin role to help customers with everyday tasks and subscription-related requests. Learn more about GDAP here. Consider using Lighthouse to make this process easier across multiple tenants.

Is there more you can do? Absolutely. For example, if you buy an Azure AD P2 subscription for just your administrative accounts, you could implement Privileged Identity Management to enable “Just-in-time” access when making administrative changes to a tenant. You could also (and probably should) remove admin privileges on desktop computers. You can also review my last post to be sure your strong authentication policies are all up-to-date.

So yes, there is always more you can do, more money you can spend, etc. But guess what? The story I referenced at the beginning of this article could have been avoided easily by minding certain items (more than one) in the above list. So always, always start with the basics, and then go forward from there. I often find that the essentials do not get implemented because there is a larger “to-do” list that includes items which, even if they are very good ideas, are just “biting off too much,” and this prevents the low-hanging fruit from becoming properly prioritized. Or maybe it is because these things are perceived as so “easy” or “obvious” that they never get double and triple checked. I dunno. But the same stuff seems to come up a lot.

Okay, end of rant.

I also just noticed that this is my first blog post in 2023, and it’s already the end of January. Wow. What a way to start the Year of Rabbit. Anyway, Happy New Year Everyone!

The post A friendly reminder about least privilege access and other simple stuff appeared first on ITProMentor.

Practical Protection: Why You Might Want to Get Rid of Ads 

With an increase in ads being used to deliver malware, there is now a practical reason to consider blocking ads on your corporate network. Paul Robichaux offers 4 solutions to protecting your org from these pesty attacks.

The post Practical Protection: Why You Might Want to Get Rid of Ads  appeared first on Practical 365.

But have you turned multifactor authentication ALL the way on?

Do you remember just a short time ago, Microsoft would claim that switching on Multi-factor Authentication (MFA) prevents 99.9% of identity-based attacks? Well, the times they are a-changin. I do not know what they would report today for a percentage of attacks which are thwarted by MFA alone, but I can tell you it wouldn’t be 99.9%. I think most of you reading this blog have probably even experienced or heard by now of an attack where MFA was enabled, but the bad guy got in anyway.

The current state of affairs was inevitable of course: when we move our defenses up, the evildoers don’t just throw in the towel and go away, they simply adapt their methods. Thus, we have seen a steady rise during the pandemic years of more sophisticated phishing techniques, where users are tricked into giving up, approving, or passing time-bound access codes onto a third-party. We also see a rise of Man-in-the-Middle (MITM) attacks where a user interacts with fake (but very convincing) login pages that include MFA prompts and everything.

So what are we to do?

First, do not be discouraged: this process of “one-upmanship” is only natural. The good news is that having more than one proof of identity in place is still the foundation from which you must build. Moving away from passwords and towards MFA or even passwordless authentication is still the right path, but you have to be willing to stay nimble and introduce additional iterative changes as we move forward in time.

The tools to do the job are already available and waiting for you. In the world of Azure AD and Microsoft 365, this means revisiting our Conditional Access (CA) policies and reconsidering our authentication methods.

I assume most of my readers already know about the Security Defaults, or these four equivalent CA policies:

Once you have these basic scenarios covered, we have number of other holes to plug. In the following paragraphs, I will recommend some additional settings and policies to further cement your foundation and prevent some of the latest attack methods we have been seeing in the wild, with a bit of commentary explaining each.

1. Update your authentication methods (number matching, etc.)

Microsoft recommends updating your policies for the Microsoft Authenticator app so that users are required to do number matching when logging into cloud resources. In other words, instead of just tapping “Approve” when the app notification comes up (which many people will do quickly by automatic reflex, or eventually after a flood of continuous prompts), they will be forced to identify the correct number which is being displayed to them.

Number matching

This helps prevent what Microsoft calls “MFA fatigue,” or illegitimate authorizations due to automatic muscle memory.

This setting will become the default experience on February 27 of 2023, but you can turn it on sooner if you like from Protect & secure > Authentication methods > Microsoft Authenticator in the Entra portal. On the Configure tab, you can move from Microsoft managed to Enabled.

Enable number matching

You can also choose to turn on Show the application name…, as well as the option to Show geographic location… These toggles will give the user more context about the sign-in attempt whenever an authenticator prompt occurs. Be sure to save any changes you make on this screen.

Back on the Enable and Target tab, you can optionally move to passwordless Authentication mode, where the authenticator app is the primary authentication method instead of the password. This experience will use the number matching challenge by default, and it will also reduce password prompts in general.

Move to passwordless

2. Enable Temporary Access Pass

I also recommend turning on Temporary Access Pass, which is also found under your Authentication methods. This allows administrators to grant time-bound access codes for sign-in purposes, particularly when the end user is unable to use their multi-factor device, or if they need to update their authentication methods at https://aka.ms/mysecurityinfo.

Temporary Access Pass (TAP)

For example, imagine that one of your users had to get a new phone and they no longer have access to the authenticator app from their old phone anymore.

Once this policy is configured, administrators can go issue TAPs to any user right from the Azure AD or Microsoft Entra portal. The same process can also be used during the initial onboarding, when users go to set up their authentication methods for the first time.

Issuing a TAP

3. Protect registration of security information

If you enabled TAP as I suggested above, then you should also enable a Conditional Access policy called Securing security info registration, which means that in order to access the security info registration page, a user will need a valid TAP issued by their administrator. I suggest you also have a process in place for requesting and distributing these TAPs securely, in order to prevent illegitimate requests from going through; for example, confirmation of identity via a phone call or video chat with the helpdesk.

This policy is also available from the CA templates (under Identities):

Securing security info registration

Note that the templated policy also excludes any trusted locations that you specified (so that users could set up their authentication methods from the corporate offices, but not from home or some other public wi-fi, for example).

4. Require MFA to register or join devices

Certain scenarios are not covered by the CA policies outlined earlier. One such scenario is the registration or joining of devices to Azure AD. There is a special policy just for that purpose that you must deploy.

This can also be found as a setting under Devices > Device settings in the Azure AD admin center. But these days Microsoft recommends using the equivalent CA policy in its place (therefore the option on this page should be set to No rather than Yes).

Device setting to Require MFA (deprecated)

For some reason the required settings for this CA policy are not detailed on Microsoft Learn, even though Microsoft recommends moving to it, but here are the settings you will need:

  • Users: All users, exclude emergency access accounts
  • Cloud apps or actions: User action > Register or join devices
  • Conditions: None
  • Access Controls: Grant > Multi-factor authentication

5. Require MFA for Intune enrollment

MFA for Intune enrollment is a separate requirement and not something that is completely covered by any of the above policies. For example, a device which has already been authenticated for another application may be able to enroll without being prompted again unless this policy is in place.

I spoke with someone on Microsoft’s DART team recently, and he explained how this loophole had been used in the wild: in many organizations where CA has been previously implemented, a managed device tends to have greater access than unmanaged devices, with fewer prompts for MFA. But if an unmanaged device has even a little bit of access already, it is possible in some cases to elevate the device by enrolling it without encountering another MFA challenge. At this point the sphere of access has been expanded. Keeping this next policy in place will prevent this unauthorized ‘escalation’ scenario.

  • Users: All users, exclude emergency access accounts
  • Cloud apps or actions: Cloud apps > Microsoft Intune Enrollment
  • Conditions: None
  • Access Controls:
    • Grant > Multi-factor authentication
    • Session > Sign-in frequency set to Every time

6. Add device-based CA policies

This is something I have long advocated for. I recommend turning on a device-based access policy for at least Office 365. This way, access to corporate resources such as email can become contingent on registering devices with Azure AD or even enrolling your devices with Intune. The two primary benefits here are:

  1. You get pretty decent assurances that the inventory of devices you see in the portal is reflective of the actual physical devices out in the world (having an accurate and up-to-date inventory is necessary for good security), and,
  2. many of the current Man-in-the-Middle attacks are instantly thwarted, because the “middle” devices that are being used by attackers are not part of your inventory of pre-registered or enrolled devices.

Therefore, even if an attacker successfully phishes someone in your organization and tricks your end users into round-tripping an MFA code or approval notification, the unauthorized access request access would be denied by the device authentication requirement.

There are a couple of different approaches to accomplish a device-based authentication policy, but most organizations will aim for “Require compliant devices,” which looks like this:

  • Users:
    • All users (or a targeted group of your choice)
    • Exclude emergency access accounts
  • Cloud apps or actions:
    • Cloud apps > Office 365
  • Conditions:
    • Device platform: Select the platforms you intend to protect
  • Access controls:
    • Grant > Require device to be marked as compliant

With this policy in place, it is also necessary to prepare Compliance policies within Intune for each device platform you intend to support. End users must then download and sign-in to the Company portal app in order to complete device enrollment. The details around setting up Intune and enrolling devices is beyond the scope of this article, but I can recommend my courses or written guides on these topics for more information.

However, we must recognize that some organizations are not yet ready to implement Intune, or even if they are, they will not be ready to require device compliance across the board right away, and that is okay. In this case, I can recommend another policy which will prevent unauthorized device access based on device filters. We call this policy “Block unregistered devices.”

Block unregistered devices using filters

  • Users:
    • All users (or a targeted group of your choice)
    • Exclude Emergency access accounts and all Guest & External users
  • Cloud apps or actions:
    • Cloud apps > Office 365
  • Conditions:
    • Device filters:
      • Exclude devices where trustType Equals Azure AD Joined, Azure AD Registered, or Hybrid Azure AD Joined
    • Access controls:
      • Block access

In this case you do not need to have devices enrolled with Intune, however, the devices must be registered or joined to Azure AD before they can gain access to data in Microsoft 365 services such as Exchange or SharePoint Online.

I also recommend blocking device platforms that you do not intend to support, which I have outlined here (Microsoft has also since added this to their “common” CA policies on Learn); this policy does not require enrollment or compliance checks, either. These policies are sometimes an easier place to start out.

7. MFA for guests

Generally speaking, I like to keep my “guest-specific” policies separate from my internal user policies. Therefore, any policies targeting internal users will normally exclude guest & external users. If I want to deploy policies specifically against guests, those will be their own policies that I can turn on or off without impacting my “standard user” CA policies.

MFA for guests

You will notice that there is one such policy available via the templates provided by Microsoft: Require multifactor authentication for guest access.

However, before enabling this policy, I tell all my customers to enable the cross-tenant MFA settings. In case you didn’t know about these, navigate in the Microsoft Entra portal to External Identities > Cross-tenant access settings. Click Edit inbound defaults then go to the Trust settings tab.

Cross-tenant MFA settings

By checking these boxes, you are telling your tenant to respect MFA claims that have already been validated in other Azure AD tenants. In other words, if you deploy a Conditional Access policy in your own tenant that requires MFA for guests, those guests will not be double prompted if they have already satisfied MFA claims in their own (home) tenant. Completing this step also happens to be a pre-requisite for our last recommendation (though I have no idea why this is so).

8. Require stronger authentication

If your organization is ready to adopt passwordless methods of authentication using the Microsoft authenticator app, and/or FIDO2 keys such as Yubikey, then you have another option to consider. This past fall just prior to Ignite, we gained the ability to distinguish between authentication methods based on authentication strength.

Previously, any type of MFA was treated equally by Conditional Access requirements: so an SMS code was considered just as good as the authenticator app or even a FIDO2 key. But in reality, not all authentication methods are created equally. With a FIDO2 key for example, the key material is non-exportable. In other words, an attacker would have to physically steal your key in order to use it to gain access as you. It is therefore considered “phish resistant.”

I suggest taking a crawl-walk-run approach; if you are considering switching to stronger authentication you may want to identify specific use cases or groups to pilot the experience before pushing it out org-wide. For example, if you have to distribute physical keys, how does that process work? What happens if someone loses a key? Etc. These questions will be easier to sort out on a smaller scale, which will help you develop a system for more widespread adoption.

Here is an example of upgrading a policy where you require stronger authentication for specific admin roles:

  • Users: Select users and groups > Directory roles (select any groups or roles you require)
  • Cloud apps or actions: All cloud apps
  • Conditions: None
  • Access controls: Require authentication strength (select your desired strength)

Upgrade your authentication strength

Note that you may have additional steps to configure the passwordless or FIDO2 experiences before enabling these CA policies.

9. Fancier subscription, fancier options

If you are the lucky owner of the more expensive E5 subscription, then you also have access to “risk-based” Conditional Access policies, as well as a bunch of other upgrades that are well beyond the scope of this article. Once again, the Conditional Access templates are the easiest way to get moving on some of these features.

E5 risk-based policies

Note: If you buy licenses to support these features for just your administrator accounts (as some organizations do), just be sure that when you deploy the policies, they are scoped to only those users who are licensed for the features. This way, you stay in compliance with Microsoft’s licensing guidelines.

Conclusion

The principles of Zero Trust remain unchanged. In the past, we would have simply enabled MFA, or the equivalent of Security Defaults, and felt that we had fulfilled the spirit of the “Verify Explicitly” pillar, but as we have seen, that may not be enough anymore on its own.

Zero Trust Principles

As the game has changed, so have our tools. In order to have more confidence that our “Verify Explicitly” principle is being met, we just want to put in place a few additional measures, for example:

  • get users to slow down by adding a number-matching requirement on the Authenticator app
  • better protect the MFA registration process itself with Temporary Access Pass
  • require a strong authentication challenge anytime a device is registered, joined or enrolled for management
  • evaluate the device as part of your authentication challenge
  • even require a stronger level of authentication such as phish-resistant, hardware-based FIDO2 keys

And of course, do not forget to address the other two pillars of Zero Trust, either! I will soon release updates to my famous Best Practices Checklists and other written guides to reflect more of what we learned over the last year. If you already own a copy, then congrats! Your free updates will be arriving sometime in the next month or so. If you want to join thousands of other happy readers, I encourage you to subscribe, check out the store, or even consider joining our SquareOne community.

We are living in a different world now than the one we had 10 or even just 5 years ago. I wonder what it will look like 5 or 10 years from now? It’s part of what makes our jobs stay evergreen, I suppose. Staying up to date in the day-to-day and month-to-month, of course, is going to be the key challenge for most of us. I suppose this article, too, could go out of date pretty quickly after its printing. But do not be discouraged: it just means that we must always be aware, ready, and willing to make iterative changes over time.

If you see any omissions in the policies or settings I discussed in this article, be sure to comment below! We would love to learn from you out there in the audience, as well!

The post But have you turned multifactor authentication ALL the way on? appeared first on ITProMentor.

Reader Question: How can I set up a “Deny-by-Default” Conditional Access Policy?

It has been a while since I took a question from a reader and turned it into a blog post. It is one of my favorite things to do here on ITProMentor, but the “busy-ness” of life has taken me away from the keyboard a lot in recent months. Now that I am (mostly) settled in a new home, I plan to rekindle some of these old joys.

This one came from Devin, who lives in the U.K.:

Hi Alex, I hope this message finds you well. I watched a recorded presentation of yours where you compared Conditional Access to a “Firewall for the Cloud,” but you mentioned that there are important differences. Specifically, you made the point that most firewalls have a “deny-all” rule by default, and it is up to the administrator to open the inbound ports that are necessary. In Conditional Access, you said it is almost the exact opposite, where everything is open by default, and you have to tell the system what you want closed.

This got me thinking, wouldn’t it be possible to start by creating a “deny-all” rule and then add other rules in front of that, to open the specific applications and access scenarios that you wanted, and no more? Wouldn’t this be more in line with the whole ‘Zero Trust’ concept?

Thanks for your insights!

–Devin, U.K.

Great question Devin, and I am glad that you asked it. No analogy is perfect, and it is actually because of these imperfections that the “firewall” comparison can be so illuminating. This will give us the chance to clarify a few things about Azure AD Conditional Access in general, and as well, offer some potential solutions to certain problems.

The first thing to remember is that Conditional Access differs from firewalls in another important way: there is no “ordering” to the rules. I cannot place one rule “in front of” another. All rules are evaluated simultaneously in Conditional Access. So, if I create a rule that says, “Block X,” it does not matter if that rule is located further up or down in my list. It will always be evaluated the same way. “X” will always be blocked.

This also implies that any “block” control always will always win over any “grant” control. Therefore, if I created one rule that said, “Block access to Email” (scoped to All users) and another one that said, “Grant access to email but require MFA” (either scoped to All users, or enabled for a specific security group), then guess what happens? Access is still blocked. In order to get the desired effect with these two policies, you would need to create a security group called something like “Email allowed users” and add that security group to the “Exclude” tab on the Block access… policy.

So, the answer to your question is both yes and no: it is possible to create “Deny-by-default” rules, but not exactly in the way you suggested. But in fact, this type of design (writing explicit block rules for everything then making many exclusions) would be unnecessary for most organizations. I will explain why shortly.

First, just notice that writing your “default deny” rule or rules quickly increases the complexity of your implementation. For example, you would need to manage double the policies and several security groups and exclusions for every access scenario you wanted to open/allow.

  • Deny mobile access for all users / Allow mobile access for approved users
  • Deny browser access from the desktop / Allow browser access from the desktop
  • Deny client app access from the desktop / Allow client app access from the desktop
  • Deny access to administrative services / Allow admin access
  • Deny all guest access / Allow guest access to approved apps
  • Etc.

I think these designs tend to get messy very quickly. You might say, so what? Why not do it this way?

Before we answer that question, let’s take a closer look at one of the other concepts I normally address during my talks on Conditional Access: the two so-called “Architecture types.”

Open (or targeted) architecture: This means targeting your policies to address specific access scenarios.  For example: “Require MFA for access to Office 365,” or “Require managed devices for access to Email.” In this architecture, you are putting specific requirements around certain applications or access scenarios, while leaving others “open” or unguarded (i.e.. you do not have policies covering “All cloud apps”).

Closed (or universal) architecture: This means targeting your policies as broadly as possible, for example All users / All cloud apps, e.g.: “Block legacy authentication globally,” or “Require MFA for all users.”

Closed architecture is better aligned to the concepts of Zero Trust since you are not leaving any “holes” or scenarios free of the constraints imposed by the policy. Note that it is also possible to combine these architecture types into a single policy set. For example, you may have a universal requirement for MFA across all cloud apps, but you only require managed devices for access to email, or certain other applications. That is completely fine and up to each individual organization.

Why Closed Architecture is more like Deny-By-Default

Now, let’s assume your goal is ultimate Zero Trust protection across all cloud apps, and that you want to impose both a multi-factor as well as a managed device requirement everywhere. In this case we require multiple policies for various reasons (e.g., easier troubleshooting, better for making more granular exclusions, and covering various access scenarios).

To begin, we need several policies enforcing the MFA requirement:

  • Block all legacy authentication: legacy authentication is vulnerable to password spray and replay attacks, and it does not support MFA challenges, so we should eliminate it for all users and all cloud apps.
  • MFA required for all admins: it is a best practice to have a policy covering this scenario even if you plan to place the same requirement against all users; that way, if the policy for standard users changes or needs to be temporarily disabled, admins are still protected.
  • MFA required for all users: This is your universal MFA requirement for everyone
  • MFA to register/join devices: We have a separate “User action” to control this behavior, as it is not covered by the “All cloud apps” selection above.
  • Secure the security info registration page: We have a separate “User action” to control this behavior, as it is not covered by the “All cloud apps” selection above. Also, it is recommended to enable the Temporary Access Pass option so that users can still get in to edit authentication methods with help from an administrator, even in the absence of another factor such as a mobile app or hardware token.
  • MFA for guests: Note that we can also trust MFA claims from other tenants, so that users are not double-prompted. If you have a policy for the guest access scenario, be sure to modify your default trust settings from Azure AD > External identities > Cross-tenant access settings.

And we need another policy set enforcing device-based requirements, for example:

I suggest that this configuration achieves the “Deny-by-default” posture that we want, without needing to add another “Block” policy on top of it, with additional exceptions, etc. Let me explain why.

When you create a policy with access controls that say, “Grant access” and “Require X, Y or Z” then you could also read this policy as saying,  “Access is denied unless X, Y or Z can be met/satisfied.” Therefore, if you do not satisfy MFA, or do no have a managed device, and your policy explicitly says those things are required, then guess what? No access for you!* This is already “deny by default.”

(*By the way, if you target “All cloud apps” with a compliant device requirement, then you must also exclude the Intune enrollment app or else you will be unable to enroll new devices. It’s like a chicken-and-egg problem: you can’t get enrolled in the first place to become evaluated for compliance if there is a compliance requirement in order to get enrolled. Note there may be other impacts as well with other cloud apps when enabling closed policies.)

Additional Deny-by-default rules

Another popular policy set is to have broad “location-based” rules that “deny-by-default” except from approved countries or locations. Example:

  • Block access from non-domestic countries: this policy is usually scoped to All cloud apps (closed), with a Block access control placed against All locations, excluding a named location containing the domestic country (e.g. USA, or wherever you live). Optionally, you can also use filters for devices to exclude managed devices (that way you can travel with devices that are already enrolled/managed)

And you can apply this concept to device platforms as well:

Anecdotal story

Let me briefly relate another story that hopefully clarifies the point further. This one combines the concepts of Open architecture with a “Deny-by-Default” policy (for a specific application: email).

Recently a non-profit organization contacted me with a very particular request. They wanted to use Closed architecture for their core policies (i.e., block legacy auth & require MFA), and at the same time use Open architecture for their device-based policies, especially for personal (mobile) devices. The main concern was around corporate email on personal devices. Okay, that’s no problem, and in fact is very common. Here is the catch. They had a very specific on-boarding process whereby a user would not be allowed to gain access to their corporate email using a mobile app until they had completed an E-safety training module. HR would assign them to a security group shortly after passing the exam, and they would thereupon be granted access (but not before then). It was basically a carrot for completing the course material.

They did not want a closed architecture because the scope for this requirement was no wider than email (Exchange Online). However, they still needed a “fail closed” policy set for this application because they did not want a user to gain access on mobile devices before passing the exam. So here is what we did: We implemented the usual policy set for block legacy auth, MFA requirements, etc. Then for the device-based requirement, we only targeted Exchange Online, and used a security group called “Allowed to access email on mobile devices.” We then created two policies:

The first policy was called “Block access to email on mobile devices” and it was configured as follows:

  • Users and groups:
    Include: All users
    Exclude: Allowed to access email + Emergency access accounts
  • Cloud apps: Office 365 Exchange Online
  • Conditions: Device platform > iOS & Android
  • Access controls: Block access

Then the second policy was called “Allow access to email on mobile and desktop apps” and it was configured as follows:

  • Users and groups:
    Include: All users
  • Exclude: Emergency access accounts
  • Cloud apps: Office 365 Exchange Online
  • Conditions: Client apps > Mobile apps and desktop clients
  • Access controls: Grant access w/ Compliant device or Approved App or App protection policy

Remember that all other access scenarios around this application are already covered by our “closed architecture” design for the MFA requirement, etc. This is an additional requirement that says access is granted only when the device is managed (MDM), or the app is protected (MAM), and when the user belongs to the proper security group (indicating they passed the E-safety course).

Now, in my opinion this configuration is not any “safer” or “more secure” than simply deploying the second policy and forgoing the first policy altogether. The reason we deployed both policies wasn’t “because security” or “because deny-by-default,” rather, we did this specifically to enable the custom workflow that they wanted to have, with the training pre-requisite. That’s it.

Conclusion

If your goal is to align your Conditional Access strategy as closely as possible with a ‘Zero Trust’ model, then you should probably be aiming for Closed architecture. However, a closed architecture approach may not be right for every organization and every application/access scenario. Whenever I implement Conditional Access, I always push closed policies for the basics: blocking legacy auth and enforcing MFA. After that, I think it is a good idea to begin evaluating device-based policies with regard to corporate email access specifically, and go further where it makes sense, even all the way to a closed policy set, especially in high-sensitivity or high-security environments. Just be aware there may be other impacts to certain applications (e.g. Intune enrollment, etc.).

Hopefully this cleared up the confusion for you, Devin. Thanks for writing in.

The post Reader Question: How can I set up a “Deny-by-Default” Conditional Access Policy? appeared first on ITProMentor.

Selling the Digital Transformation Journey: Security & Compliance

When I talk to customers about their Digital Transformation Journey, I always like to give them the “10,000 foot view” so to speak. I suggest that we explore two different angles or “big pictures”  in order to paint an image that customers can then imagine themselves into. The first picture is Security & Compliance, and the second is Productivity & The Modern Workplace. Let’s start by examining the first.

With regard to Security & Compliance, we have to set the stage a bit: why should customers care about this stuff? After all, cybersecurity initiatives typically struggle to get funding and other traction, especially in the small and mid-sized business where resources are more scarce to begin with.

The structure of your pitch

You will often see security vendors at conferences begin their presentations with scary statistics about how many breaches occur each year, and how the cost of an average breach has been steadily increasing year-over-year; I find this type of information to have a very limited effect on people. If something like that is going to be your angle, it is far more effective to relate real-life stories, and the “closer to home” each story hits, the better (yet some orgs will refuse to act until it is their own home which is hit, and they become one of those stories you end up telling to others).

But selling customers on the importance of security & compliance should not be based on scare tactics, anyway. You also have to paint a picture of value. Give them a preview of what it looks like to live in the new world you want to guide them into. Remember that all changes are going to be met with some resistance (this is only natural), yet these changes are ones that must take place sooner or later. Plus, you can highlight new features such as Sensitivity labels, which grant users new superpowers they’ve never had before. In general, it is much more difficult to prod people from behind into the darkness than it is to coax them into the light, leading from the front. In other words, carrots are better than sticks.

The corollary in this message which you must communicate explicitly is that you have already walked this path yourself, and you have no regrets about doing so. You will also take them down this path, and it will go just as smoothly, or even better, since you already know the pitfalls and dangers that lie along the way. As you paint this canvas, also be sure to highlight how the new tools or capabilities would have prevented or mitigated the problems you shared earlier in your anecdotal stories.

In addition to sharing relatable anecdotes and painting the preview or picture I want them to inhabit, I normally make it very clear that this past decade has seen such a radical shift in the cyber landscape, that I can no longer afford to waste my time with customers who will not take this journey seriously. If they cannot even be bothered to implement a basic level of cyber hygiene such as CIS Implementation Group 1, then they are essentially begging to be compromised, and simply I cannot give my precious attention to folks who will not even address the most essential of risks, and therefore any further engagement is off the table. This is also why I suggest beginning your new engagements from Security & Compliance rather than Productivity & The Modern Workplace.

Let me be clear: this might mean you have to fire some existing customers, even long-standing ones. But that’s okay: you are going to replace them with better ones (the ones who will actually listen to you and trust your recommendations). Notice this is different from either a stick or a carrot. It is more like a “filter” or disqualifier.  Holding up this barrier is only fair to them, and enormously helpful for you, plus it sends a very strong message (it projects confidence in your own practice).

So let’s review: you should plan your Security & Compliance pitch using these key components:

  1. Relatable anecdotes from the wild (and the closer to home the better)
  2. A preview or “picture” of where your customer is heading and the new capabilities you will bring to them
  3. An ultimatum / disqualifier

So what does good look like?

Once you have a prospect’s attention, you will need a simple and engaging way to explain your Security & Compliance offering to them. If you are primarily selling solutions built on top of Microsoft 365, as I am, then I suggest leveraging the concepts, marketing and language that Microsoft themselves have already produced. For example you will see them speak and write frequently about “Zero Trust,” and what that phrase means to them.

They have also published some detailed documentation such as the Zero Trust Deployment Plan, which is targeted for Enterprise (read: E5) customers. You can simplify this for SMB a bit further, as I have done here:

Follow our simple 3-tiered approach to Zero Trust

There is no need to reinvent the wheel (that’s what Microsoft’s materials are there for). Plus, if a customer decides to “spot check” your pitch, they would find solid validation with a quick Google search.

Aren’t Security and Compliance different things? Why not two offerings?

You can sell separate offerings if you want to, sure. Remember that a “compliant” environment is not necessarily a secure one. On the other hand, the items that are generally called for in a high-regulation, compliance-intensive scenario most often exist because of concerns around data security. For this reason, I always suggest that you approach your engagements from a “Security-First” mindset. When you build a good, secure foundation, you will very often find that compliance is a breeze thereafter, and this is because most compliance requirements will map back to common cybersecurity frameworks such as NIST anyway.

And yes, I am aware that in some cases “compliance requirements” actually contradict the latest cybersecurity guidance. The most common example I see thrown around is password complexity & rotation requirements, which are moot after the implementation of a good Zero Trust baseline including Multi-Factor Authentication and other identity protection systems. Look, I have gotten into with auditors before: I have found that the spirit behind the law is more important than meeting the letter of the law itself. So with regard to this particular example, the point is not to put people through the discomfort of changing passwords every 90 days, the point is to protect them from credential theft and identity compromise. We have better, more sophisticated ways of doing that now which are more comfortable, so why would we go backwards? I have fought this battle and won on more than one occasion (so that we could end password rotations), and I won because I supported my claims with reputable references.

Anyway, my original point is that you can splinter off a cybersecurity essentials baseline offering, and then have “compliance” add-ons for helping organizations meet more specific requirements such as PCI, HIPAA, GDPR, etc. as needed. Some service providers will specialize around a particular vertical, and get to know their requirements really well, and then just focus on those (then a single, flat-rate Security & Compliance offering makes a lot of sense). How you bundle this stuff and sell it to your customers is largely up to you. I would not say there is just one right answer here.

Conclusion

Once your customer has committed to the Security & Compliance journey, then you are off to a very good relationship indeed. From here, you can begin to explore the next big picture, which is improving productivity and modernizing outdated, tired business practices. This will require a new change of frame, so to speak, and another pitch. But this second journey is going to be taking place against a more secure background than what you had before (this actually makes life easier and less stressful for both you and your customer). Without the first journey, you could jeopardize all of your subsequent efforts in the second: the modern workplace transformation should be undergirded by that Security-first foundation.

If you enjoyed this blog post and would like to see more content like it, which goes into greater detail and gives you an opportunity to work with myself and other peers who are implementing these solutions for customers, I would suggest you check out our SquareOne Practice Development Group.

After you get your customers onboarded to your “Security-First” services, the next step is helping them to complete their digital transformation and maximize the value they invested into the modern workplace. But that is a topic for another day.

The post Selling the Digital Transformation Journey: Security & Compliance appeared first on ITProMentor.

What are the limitations with Microsoft Defender for Business Standalone?

Most of my readers will already be familiar with Microsoft Defender for Business (MDB), which is included with Microsoft 365 Business Premium. And a majority of those will be deploying MDB as one part of a broader security solution which includes other services within the Business Premium bundle. But a subset of folks have asked about the “Standalone” version of Microsoft Defender for Business.

Yes, it is true, there is indeed a standalone version (USD $3/user/month), which was announced last month. The use case? Consider a scenario where the customer is using a different productivity platform such as Google Workspace, or they haven’t yet made the transition to other Microsoft 365 services. Using the standalone SKU, you could theoretically onboard devices and start providing protection, ahead of deploying other services, and with far less upfront licensing commitment.

Some of the MDB-related services will function much in the same way as you are used to with the full product, however, you should be aware that certain services would only be available with an Intune license (Microsoft Endpoint Manager). For example, the “Automatic onboarding” option during the first-run wizard experience requires devices to be enrolled with Endpoint Manager already. As well, certain functionality in the Microsoft 365 Lighthouse product may rely on the presence of the Intune licenses in order to work. At the same time, some functionality within Endpoint Manager will still be available, even without the “complete” license set. In fact, just enough of the MEM product is activated to make basic policy deployment possible for the “standalone” scenario. Clear as mud, right?

Show me

Let’s take a look at an example where I have onboarded a new “standalone” device into a tenant where I also happen to have some “fully licensed” Microsoft 365 Business Premium users.

In the first place, I need to actually purchase and assign the standalone license product to the correct users. For this purpose, I created a new user named “Mark Twain” in my tenant, and assigned the MDB standalone product.

Assign the MDB standalone license

Next, we want to check on a couple of settings related to this scenario. Begin by navigating to Settings > Endpoints from the Microsoft 365 Defender Security Center, and click on Enforcement scope.

Enable the features in Defender security center

You will want to turn On the setting called Use MDE to enforce security configuration settings from MEM and select the OS choices below (and yes: Windows Server support is coming soon to the Business product).

Then, check Microsoft Endpoint Manager by navigating to Endpoint Security > Microsoft Defender for Endpoint.

Enable the features in MEM

Be sure that the option Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations is switched to On, and Save settings if necessary.

With those settings in place, let’s onboard a device named “Workstation10” using the local script method (you could also use GPO or other methods, but just note that you cannot use MEM to onboard the device in this scenario since the requisite license is not available and the device is not enrolled into the service).

Run the local onboarding script

Okay, now that the script has been run, we expect the device to show up in our inventory. Let’s take a look. We should be able to see it from the Defender Security Center:

See the device from the Defender Security Center

Yep. And as well, from Endpoint Manager:

See the device in MEM

You will notice in both cases that there is a column called Managed by which will indicate whether the device is being managed by Intune or MDE (which is the Enterprise term for MDB). Those devices which are managed by MDE are the so-called “standalone” devices. You will also notice that not all the data are available for standalone devices, because they are not enrolled with Intune (therefore things like Compliance cannot be evaluated).

Finally, you will notice that we can still take all the same actions against standalone devices, such as Isolate device, Restrict app execution, Run antivirus scan, Collect investigation package, Initiate Live Response Session, etc.

Same device actions are available for standalone devices

I will also add that in addition to the device inventory and device actions, the Vulnerability management functionality that we have via the Microsoft 365 Defender Security Center is still available and visible for standalone devices.

TVM data is available for standalone devices

Assigning policies

Let’s say you want to assign policies to your standalone devices. We can either use the Microsoft 365 Defender Security Center (you will find it under Configuration management > Device configuration), or we can use MEM. Since the purpose of this blog is to highlight the boundaries and limitations of MEM with regard to these standalone devices, let’s examine the option to assign policies from Endpoint Manager.

Start by creating a Dynamic device-based security group. Go to Groups, and create a new group. Name it something descriptive like “MDB Standalone Devices” or similar. Then, use the following expression to capture the devices managed by MDE:

  • (device.systemLabels -contains “MDEJoined”) or (device.systemLabels -contains “MDEManaged”)

Create a dynamic device group

(Note: I have also observed that using the “All devices” option works as well when making assignments, but it can be useful to have a group that can identify for you which devices are managed by MDE/MDB, and not yet onboarded to MEM.)

Next we can create a policy and assign it to our new security group. The following policy types are supported currently:

  • Antivirus
  • Firewall
  • Firewall rules
  • Endpoint Detection & Response

I suspect we will see additional policy types supported in the future (e.g., Attack Surface Reduction), but at the time of this writing, the above is all that is included.

I created a simple Antivirus policy. Again this could also be achieved from the Microsoft 365 Defender Security Center, but I have elected to manage my policies in MEM instead for the purposes of demonstration.

Antivirus policy is applied successfully

Now, if I try to create and assign a policy that isn’t yet supported, such as Attack Surface Reduction rules, what happens?

ASR policy stuck in pending state

As of now, we see that it just remains in a perpetual “Pending” state. I hope to see support for more policies soon, though. Fingers crossed.

Takeaways

So can the standalone product do everything that the MDB product can when bundled with a more complete subscription set such as Business Premium? No.

Certain policies and functionality would require the “full” license bundle including Azure AD Premium and Intune/MEM. For example, if you want to unlock features like the Conditional Access integration, and measure device Compliance, or if you want to view and managing additional device attributes. But it appears that Microsoft is attempting to open “just enough” functionality here to support a sort of “lite” management scenario of the MDE/MDB product via MEM, even if you don’t have an Intune license. (It is always best of course if you can move into the full experience with the complete license bundle).

In my opinion, we should at least get support for Attack Surface Reduction rules added both to the MEM for standalone scenario, as well as receive a new way to deploy these policies from the Defender portal (like we have with Antivirus and Firewall policies today). I do not know if/when this will happen, but my hope is that we will see it yet this year.

And that is basically the whole story in a nutshell, as of right now. Hopefully that cleared up some of the more confusing points. If we get additional functionality in the future, I will be sure to report back.

The post What are the limitations with Microsoft Defender for Business Standalone? appeared first on ITProMentor.

Dataverse Record Level Security

Record (row) level security in Canvas or Model-driven apps. Using Dataverse security models.

dataverse-record-level-security-yt-thumbnail

jcook127001

Record ownership across business units (Preview)

❌
❌