Requirements

Before we go into the details on how to set this up, we first need to ensure that we have everything in place so everything works as expected. Here’s what is needed.

• Azure AD P1 or P2 license for conditional access
• Security Administrator, Conditional Access Administrator or Global Administrator
• SharePoint Administrator or Global Administrator
• Exchange Administrator or Global Administrator
• Microsoft.Online.SharePoint.PowerShell PowerShell Module
• ExchangeOnlineManagement PowerShell Module

To touch a bit on these requirements, we need to ensure we have an Azure AD P1 or P2 license so we can have access to use conditional access policies. This is going to be the foundation of what we’re going to use to either limit or block unmanaged devices from accessing anything in the cloud. Also as of today, Security Administrator, Conditional Access Administrator or Global Administrator are the only roles that are able to modify CA policies. So we will need at least one of those.
 

Exchange Administrator and SharePoint Administrators are needed to be able to set the respective platform policies to limited access. A bit more on that later.

What Classifies as an Unmanaged Device

An unmanaged device is typically a device that is not issued by your organization. It is often synonymous with BYOD (Bring Your Own Device) and can be anything from a personal computer or phone to a machine that you use to access emails while at grandma’s house. The point here is that it doesn’t have any policies and it is not properly governed by the IT department.
 

Limit Browser Access on Unmanaged Devices for M365 Apps

If you don’t want to put a full stop on users accessing M365 resources, you do have the ability to limit what they can do while signed in from an unmanaged device. Simply put, we can enforce policies so users can still sign in using the web only methods, however, they will be blocked from downloading anything to the local machine.
 

For most, this is a great happy medium because it still keeps your data secure to a certain extent and users can access their documents if they don’t have their company issued device around.
 

This is in fact a two-step process so we’ll target SharePoint/OneDrive and Exchange Online now. Then we will finish it off with the CA Policies.

Limited Browser Access for SharePoint Online

If you want to take this in incremental steps you definitely can. Being able to set limited access on specific sites is supported so it’s definitely recommended you take that approach first. In my opinion it will be a good test to set limited access on a few SharePoint sites as well as a few OneDrive sites.
 

Let’s connect to SharePoint Online using the Microsoft.Online.SharePoint.PowerShell PowerShell Module.

Import-Module Microsoft.Online.SharePoint.PowerShell -WarningAction SilentlyContinue
$adminURL = 'https://<tenantname>-admin.sharepoint.com'
Connect-SPOService -Url $adminURL -WarningAction SilentlyContinue

Apply on a Per-Site Basis

Next, let’s take a look at the conditional access property within the Get-SPOSite cmdlet. This is what we’ll use to be able to limit access on specific SharePoint (or OneDrive) sites before we deploy this on the tenant level. By default, this should be set to allow full access. Meaning anyone can access this SharePoint site from anywhere and there wouldn’t be any restrictions in place.

With that out of the way, let’s change the access to allow limited, web only access for this site as well as a OneDrive site. To accomplish this we’re going to use the Set-SPOSite cmdlet along with the -ConditionalAccessPolicy Parameter.
 

This parameter supports the following inputs:

• AllowFullAccess: Allows full access from desktop apps, mobile apps, and the web
• AllowLimitedAccess: Allows limited, web-only access
• BlockAccess: Blocks Access
• AuthenticationContext: Assign an Azure AD authentication context. Must add the AuthenticationContextName

$SiteURL = 'https://thesysadminchannel.sharepoint.com/sites/someproject'
$OneDriveURL = 'https://thesysadminchannel-my.sharepoint.com/personal/buzz_thesysadminchannel_com'

Set-SPOSite -Identity $SiteURL -ConditionalAccessPolicy AllowLimitedAccess
Set-SPOSite -Identity $OneDriveURL -ConditionalAccessPolicy AllowLimitedAccess

$SiteURL, $OneDriveURL | ForEach-Object {Get-SPOSite -Identity $_ | select Title, ConditionalAccessPolicy}

Title          ConditionalAccessPolicy
-----          -----------------------
SomeProject         AllowLimitedAccess
Buzz Lightyear      AllowLimitedAccess

Before you start checking the sites you set the limited access on, note that nothing is limited until we configure the CA policies. It is strongly recommended that you do thorough testing before enabling this at the tenant level. Once you’ve done that and you’re ready to set it as the default, you can do that with another cmdlet. That cmdlet is Set-SPOTenant
 

Apply at the Tenant Level

Now that you’re ready to enable this as the default on the tenant level, there is one thing we need to decide on. That one thing is whether we want to enforce these restrictions on adhoc recipients. What exactly does that mean you say?
 

When the feature is enabled, all external users are going to be in scope of the restrictions and users who are accessing SharePoint Online files with a pass code are going to be blocked.
 

Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess -ApplyAppEnforcedRestrictionsToAdHocRecipients: $false

When completed, we can also check the SharePoint Admin center to see the same thing.

 

Finally, since doing this will automatically create a conditional access policy on our behalf, I would recommend disabling that and crafting one by hand so we can fine tune it to our liking.

Limited Browser Access for Exchange Online

Much like the SharePoint Online scenario, we can also limit browser access for users who are trying to access their email when on an unmanaged device. This setting is done using the OwaMailboxPolicy and is configurable for specific mailboxes or at the tenant level. Before we take a look at each one, we need to connect to Exchange Online via PowerShell.

Connect-ExchangeOnline -UserPrincipalName user@domain.com -ShowBanner: $false

Apply on a Per-Mailbox Basis

Again, it’s always a great idea to test on a few people to ensure you’re able to get the results you want. There’s nothing worse than enabling a policy and having to revert back because of incidents that could have very well been avoided if it was properly tested.
 

To set the limited access on a few mailboxes we’re going to need to create a new OwaMailboxPolicy and then set the same conditional access parameter to readonly.
 
In case you’re interested, here is what the supported inputs are for that parameter:

• Off: No conditional access policy is applied to Outlook on the web. This is the default value
• ReadOnly: Users can’t download attachments to their local computer, and can’t enable Offline Mode on non-compliant computers. They can still view attachments in the browser
• ReadOnlyPlusAttachmentsBlocked: All restrictions from ReadOnly apply, but users can’t view attachments in the browser

$OwaPolicy = New-OwaMailboxPolicy -Name LimitAccess
Set-OwaMailboxPolicy -Identity LimitAccess -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True Off
LimitAccess                  False ReadOnly

With the OwaMailboxPolicy now created, let’s apply that policy to a few users so we can do our testing. To apply we will use the Set-CASMailbox cmdlet.

Set-CASMailbox darth -OwaMailboxPolicy LimitAccess
Get-CASMailbox darth | select DisplayName, OwaMailboxPolicy

DisplayName OwaMailboxPolicy
----------- ----------------
Darth Vader LimitAccess

Apply at the Tenant Level

After we’ve tested for a bit, we can now apply this as the default setting at the tenant level. To accomplish this, we will use the Set-OwaMailboxPolicy and and modify the “OwaMailboxPolicy-Default” to use the readonly conditional access policy.
 

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True ReadOnly
LimitAccess                  False ReadOnly

Block Unmanaged Devices Using Conditional Access

If you’re wondering why nothing has changed after setting the SharePoint or Exchange settings, it’s because your conditional access policies are the tools that are going to be enforcing these restrictions. The platform settings are the underlying scoping policies, however the conditional access policies are the overlying restriction setting. Since we ended up setting both platform restrictions at the tenant level, the users we add (and ONLY those users) in the conditional access policy should have this setting enforced. Hopefully that clears up any confusion.
 

Similar to the default SharePoint policies that were automatically created, there are 2 policies we need to create so we can block unmanaged devices as well as restrict browser access if they’re not on an IT issued device. We can use those as rough templates to get us started.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA015: Block Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: All Cloud Apps (or M365 Apps for testing)
• Exclude: None



• Under Conditions: No Changes needed (or exclude iOS and Android Devices for testing)
• Under Grant:
• Require device to be marked as compliant: Checked
• Require Hybrid Microsoft Entra joined device: Checked
• Require one of the selected controls: Is selected



• Under Sessions: No Changes needed

Restrict Browser Access on Unmanaged Devices Using Conditional Access

Earlier we setup the policies on Exchange Online and SharePoint to be able to limit browser access while using an unmanaged device. The policy on that platform is set, however, as mentioned earlier, we need to be able to enforce this using conditional access policies. Let’s do that now.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA016: Restrict Browser Access to Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: Office 365
• Exclude: None



• Under Conditions:
• Client Apps → Browser: Checked



• Under Grant: No changes needed
• Under Sessions:
• Use app enforced restrictions: Checked

Incognito Mode and Browser Extensions

One important item to call out is that your users can continue to have issues even though their device is compliant or Hybrid Azure AD Joined. This is because certain browsers don’t have the functionality built-in to send the device payload so the CA policy can properly evaluate it.
 

• Edge: Functionality is built-in so testing with Edge is always recommended
• Chrome: Windows 10 accounts extension is required for Chrome v111+
• FireFox: FireFox Windows SSO is required
• Incognito Mode: extensions should be abled for incognito mode as well

If you’re STILL having issues after ensure your device is in the proper state and you have the proper extensions installed, one thing that I’ve learned is clear the cache and cookies and that resolves most of the issues.
 

Conclusion

Hopefully this article on how to limit or restrict browser access to Microsoft 365 apps as well as block unmanaged devices using conditional access was insightful. This should help add a bit more strength to your overall security posture so that’s always a good thing.
 

This policy is very powerful so you need to make sure you do some thorough testing before enabling the policy globally. Another policy I would highly recommend is to Enable Authentication Strengths Using Conditional Access so you can set higher profile apps to use phishing resistant MFA.

The post Block Unmanaged Devices Using Conditional Access appeared first on the Sysadmin Channel.