{"id":1546,"date":"2020-03-01T16:49:11","date_gmt":"2020-03-01T16:49:11","guid":{"rendered":"http:\/\/www.myfatblog.co.uk\/?p=1546"},"modified":"2020-03-01T16:49:11","modified_gmt":"2020-03-01T16:49:11","slug":"configuring-conditional-access-site-sensitivity","status":"publish","type":"post","link":"http:\/\/www.myfatblog.co.uk\/index.php\/2020\/03\/configuring-conditional-access-site-sensitivity\/","title":{"rendered":"Configuring your tenant Conditional Access for Site Sensitivity Labels in Office 365"},"content":{"rendered":"

In my post yesterday about the public preview of Site Sensitivity Labels in office 365<\/a>, I said I\u2019d do another post about how these work and what\u2019s required to get these working in your tenant. This is kind of important as the current documentation does NOT tell you what to configure in Conditional Access to get this working. You must also have Azure AD P1 licenses for everyone who will be subject to Site Sensitivity label as it required Azure AD Conditional Access to work.<\/p>\n

Just an FYI.. you must have Azure AD P1 for anyone subject to site sensitivity labels as it requires Azure AD Conditional Access to work!<\/p><\/blockquote>\n

If like me you\u2019ve been using Site Scoped Conditional Access policies in SharePoint for sometime (Launched in Oct 2017<\/a>!), then you may already have the required rules in Azure AD Conditional Access, as these were required to enable that functionality and these group scoped rules work in exactly the same way.<\/p>\n

For those of you not familiar with Conditional Access, it\u2019s a way of creating a set of policies that can be targeted at all or a subset of your users to control access to Azure AD Protected applications based on things like Who the user is, where they are logging in from, what device they are using and depending on your license even how \u201cRisky\u201d their logon is considered using AI derived algorithms.<\/p>\n

For the purposes of what we want to achieve, we\u2019re going to create a Conditional Access rule that covers the following key points:<\/p>\n

    \n
  1. Is targeted at a Single Test User.<\/li>\n
  2. Tests to see if the user is outside of the \u201cTrusted locations\u201d (e.g. outside the corporate perimeter)<\/li>\n
  3. If the rule applies, access will be granted but final control will be passed to the application for it to control access (in this case SharePoint)<\/li>\n<\/ol>\n

    It\u2019s that final stage that provides SharePoint the granular control over whether to allow the user in with Full or limited access, or to just block them outright. This maps directly to the ConditionalAccessPolicy property that can be configured on an SPSite object through PowerShell, with the following values.<\/p>\n

    \"Site<\/a><\/p>\n

    Looking at the sites created during both Teams creation and SharePoint site creation with sensitivity labels, I\u2019m seeing the same properties being configured under the hood, so it\u2019s safe to assume the mechanisms of both this and classic Site Scoped access policies are the same.<\/p>\n

    These map directly to the permissions found in the Sensitivity Label configuration for Sites and Groups:<\/p>\n

    \"Site<\/a><\/p>\n

    Assuming that we\u2019ve created our site sensitivity labels and created a new Team, Group or Site using them, or decorated a SharePoint site with the conditional access policy shown above, how do we create the conditional access policy to enforce those behaviours?<\/p>\n