Freitag, 26. November 2021

Step by Step guide - limit access to Teams

Step by Step guide & scenarios to limit access to Teams (SharePoint, Exchange, etc.) from an unmanaged device.

There are already some general articles on this topic in the internet. This article is a concrete step by step guide to implement the following example:
  • Access to teams should only be possible via the browser, which has the advantage that no local log files etc. are written or data is not stored in a local device backup. This is especially important for mobile devices (iOS, Android), as these backups may be stored in further cloud services.
  • Download of files should not be possible. Accessing and editing in the browser shall be possible.
OR
  • Download, access and editing of files should not be possible.

Solution

Services involved in this example:
  • App Restriction (SharePoint & EXO Admin Center)
  • Azure AD Conditional Access
To give separate option to selected users the way described here cannot be used. The reason is that in this example the Conditional Access Policy in the Session section refers to the App Restriction settings in the respective Admin Centers of Exchange and SharePoint - and these are global for the whole tenant. An option for more granular settings is to use PowerShell to apply the App Restriction only to selected SharePoint sites.
Example: Set-SPOSite -Identity https://<SharePoint online URL>/sites/<name of site or OneDrive account> -ConditionalAccessPolicy AllowLimitedAccess

Alternative methods for more selective settings related to specific users, selected Teams, or scenarios such as "access from the corporate network" can be implemented using the following methods:

Step by step guide on the example

SharePoint admin center -> Access control -> Unmanaged devices -> Allow limited, web only access:

This auto generates a Conditional Access Policy:

Settings in the Conditional Access Policy:

User experience in Teams on unmanaged device -> now download available:

User experience in SharePoint on unmanaged device -> now download available:

User can open and edit documents in Teams Web-client:

The document cannot be open in the Office client:

Switching the App Restriction to block access:

The Conditional Access Policy keeps as it is, but the user experience changed:
(Teams chat is still available)

Tips & Tricks

  • It can take several minutes for a Conditional Access policy to take effect / for a change to take effect.
  • For tests in which policies are changed, the following applies: Always log off, close browser / clear browser cache, wait several minutes and then log in again.

Samstag, 30. Oktober 2021

Azure AD Conditional Access | Authentication Context

The Authentication Context feature can be used to add additional and granular security to access apps or data in apps such as SharePoint or Exchange.

Example: Access to SharePoint sites or data in SharePoint is only permitted with devices managed in Intune. This is enforced via a conditional access policy. For special SharePoint sites containing highly sensitive data, access is also only permitted from the company network.

Until now, this was not possible because a conditional access policy always referred to the app as such, i.e. to SharePoint in the example above. With the Authentication Context in a Conditional Access Policy, this scenario is now possible.

Authentication Context

The feature is still in preview. The following limitations apply to the preview:

  • Deleting authentication context definitions is not possible in the preview.
  • The preview is limited to a total of 25 authentication context definitions.

An Authentication Context is created in the Conditional Access menu in the Azure Portal:


The Authentication Context is nothing more than a container:
The Authentication Context feature can then be selected in a Conditional Access Policy in the “Cloud Apps or Actions” menu item.
This adds another option to the already existing cloud apps and user actions.

Using an Authentication Context  

To implement the example from above, a Sensitivity Label is now used. The Authentication Context is configured in the Label:
The label is then assigned to the corresponding SharePoint site. If this SharePoint site is now accessed, the conditional access policy in which the authentication context is stored applies:
The whole process:
Example:
User Stan Laurel logs into Office 365 and goes to the SharePoint app:
Now he selects the SharePoint site "SPO Authentication Context DEMO" and then gets the message that access is not possible.
However, the reason here is not permissions, but that a conditional access policy, as described above, only allows access from the company network.

Sonntag, 29. August 2021

My Analytics, Workplace Analytics & Delve - or from the backend perspective Office Graph & Microsoft Graph

The analytics features in Microsoft 365 remain a sensitive topic for works councils and data privacy officers. This article describes the options currently available to customize these apps.

Overview and history of Office Graph & Microsoft Graph

At the time of its initial release in 2014, Office Graph was the backend for Delve, among other things. The Office Graph has since evolved and the Microsoft Graph was joined. To provide a coherent Microsoft Graph schema, Microsoft introduced an itemInsights entity that inherits all the properties of the existing officeGraphInsights resource. Currently, for backward compatibility reasons, the officeGraphInsights entity is still available. Generally, the "insights" generated by the Microsoft Graph can be disabled for the entire tenant or per Azure AD group in the Admin Center:


More details about this and the options with PowerShell / API are described in this Microsoft article: Customizing item insights privacy in Microsoft Graph. Currently, August 2021, the options described in the article are still in "Preview" status.

The apps My Analytics, Workplace Analytics & Delve

All three apps aggregate and analyze users' actions in Microsoft 365 to give individual users a system-wide view of what's happening in Microsoft 365.
Delve: The Delve app mines all documents that a user is actively working on and attempts to analyze correlations between their own work and that of other users. The goal is to show users correlations and common work areas with other users. The following always is true:
  • Security by Design. Everyone only sees what they have access to.
  • Private signals can only be seen by the person himself, e.g. which content might be interesting for him. This cannot be impersonated in the sense of: please show me what is interesting for John Doe.
  • Public Signals only show what can also be found in other ways, e.g. via search.
Delve can be customized by each user: The "Show Documents in Delve" setting is available at the following link: https://delve.office.com/ 
If a user deactivates this function, however, his signals are still collected by the Office Graph / Microsoft Graph and are available to other users who also have access to the affected documents. Only the user himself will not see any reports about the documents he is working on or has access to after deactivation.

The Office Graph / Microsoft Graph also creates the overview and reports for the user under office.com and in apps like Outlook or Microsoft Teams. The following functions / customizations are available here:
  • Meeting Insights: When a user calls up an appointment in their calendar, Outlook displays other content relevant to that appointment. This can include mails and files in the mailbox, files from OneDrive or SharePoint for which the user has at least read permission. Meeting Insights can currently only be switched on or off for the entire tenant.
  • Item Insights: This feature creates recommendations based on user interaction/common tasks in Microsoft 365. These recommendations can include documents or other types of content and are displayed in People Cards (Contacts), Delve, Office.com, and other locations. Item Insights can be turned on or off per Azure AD group.
The Office Graph can also be disabled completely, as described here: Control access to Delve. This will then affect many other features such as:
  • SharePoint Home
  • SharePoint Activities
  • OneDrive Suggestions
  • Copy / Pats Functions
  • etc.
My Analytics: My Analytics creates an overview of the complete working day and provides reports on how long the user has spent on mails, meetings and other things. The My Analytics function can be controlled via the license. If a user is not assigned the license for this app, the function is not available.
My Analytics, like the Delve app, cannot be impersonated and reports are only available to the individual user to view
The My Analytics app can also be configured per user:
The following applies here:
  • If the app as a whole is deactivated, the user will no longer be able to access his dashboards in My Analytics. The Insights Outlook add-ins are then also no longer available.
  • Inline suggestions and weekly digests will no longer be generated.
  • Email activity will no longer be included in the count for other users' email open rates.
Workplace Analytics: In Workplace Analytics, data from daily work in Microsoft 365 is used to identify patterns. Data protection is considered here by default, by only presenting data anonymized and aggregated at the group level.
The Workplace Analytics function can also be controlled via the license. If a user is not assigned the license for this app, his data will not be collected and analyzed. Workplace Analytics can currently only be licensed via an EA. For details, see: Requirements for Workplace Analytics

Workplace Analytics offers the following options for configuration:
  • Sources: Administrators and analysts use these to verify that Microsoft 365 and organizational data has been uploaded correctly to Workplace Analytics.
  • Upload: Administrators use this to prepare and upload organization and customer data.
  • Administrator Settings: Administrators use this to configure system default settings, privacy settings, and manager settings.
  • Analytics Settings: Analysts use this to customize meeting exclusion rules that help ensure data accuracy.

By the way: The Viva Insights feature also uses data from the Microsoft Graph, combines it with its AI and creates the corresponding dashboard. The apps My Analytics and Viva Insights will be merged in the future:













Sonntag, 8. August 2021

Guest users in Azure AD - available options and scenarios

The easiest way to give an external person access to a Microsoft 365 service is to invite him as a guest user via Azure AD. If an external person is invited directly via Teams, SharePoint, PowerBI, etc., this also automatically results in a guest user in Azure AD.
However, this is not the only option. Technically, there are different ways to do it:
  1. A user is invited as a guest. The authenticating instance is either another Azure AD, or an IDP supported by Azure AD. Well known examples are Google and Facebook. More details are described here: Identity Providers for External Identities
  2. The second option is that the user is created in the local AD or in the Azure AD. This is the case if customers or partners already have accounts in the local AD that should now also be used to access cloud resources, or if a company wants to manage guest users completely itself. The IDP is then also the own AD / Azure AD for the guest user.
  3. A guest user who logs in via one-time passcode. Details are described in this article: Onetime Passcode Authentication to access Microsoft 365 Group resources
In Azure AD's, a guest user from the first or the third scenario technically looks like this: John.Smith_gmail.com#EXT#@tenantname.onmicrosoft.com. However, the user logs in normally as John.Smith@gmail.com.
A user created via the second scenario, however, also technically has a UPN that follows the "normal" layout: Jane.Doe@tenantname.onmicrosoft.com.

What makes a user a guest user?

Which instance does the authentication says nothing about whether a user is technically a guest user or a member. The value "UserType" which can be set via PowerShell determines whether an account is defined as a guest or as a member.
Example:

Connect-MsolService
Set-MsolUser -UserPrincipalName "John.Smith@gmail.com" -UserType Member

This makes the user John.Smith@gmail.com, who was invited as a guest, a full member in Azure AD. This user can now also be added to a Microsoft Team as a member or owner.

The other way a user from the on-premises AD or Azure AD can be configured as a guest user.
Example:

Connect-MsolService
Set-MsolUser -UserPrincipalName "Jane.Doe@tenantname.onmicrosoft.com" -UserType Guest

When a user is changed from a guest to a member, he must also be licensed. If a user is newly created or synchronized via AAD Connect, it is always a member of Azure AD. Via "-UserType Guest" he can be turned into a guest account and does not need to be licensed anymore.
Microsoft article about this:

Examples

Example 1 - Account in Azure AD is reconfigured from member to guest user:

Example 2 - Account in Azure AD is reconfigured from guest user to member:




Samstag, 7. August 2021

Use app enforced restrictions vs. Use Conditional Access App Control

Blocking downloads or at least blocking them on unmanaged devices is a common requirement in the context of Microsoft Teams and SharePoint. Different features can be used to implement such requirements.

App Enforced Restrictions

Generally, these settings can be configured in the SharePoint Admin Center:
If this setting is used, the system automatically creates two conditional access policies in Azure AD:
These policies can be customized and thus also used as a starting point for a more detailed conditional access policy that, for example, only applies to selected users or groups.

The first screenshot above also shows the following message: We will automatically change the "Apps that don't use modern authentication" setting to block access (because these apps can't enforce this device-based restriction). The background is that apps that do not use modern authentication cannot enforce any device-based setting. If such apps remain allowed, the created conditional access policies can be bypassed.

Another information in the screenshot above makes clear that not all detailed settings are available via the UI in the SharePoint Admin Center: "If you don't want to limit or block access organization-wide, you can do so for specific sites". The link behind "Learn how" is to the documentation of the options via PowerShell.

Example: Set-SPOSite -Identity https://<SharePoint online URL>/sites/<name of site or OneDrive account> -ConditionalAccessPolicy AllowLimitedAccess

Options with Sensitivity Label

The solution via Sensitivity Label means that the settings in the SharePoint Admin Center are no longer used. The label offers the same options as for example "Allow limited, web-only access":
This setting has the following effect both in the SharePoint Admin Center and in the label configuration:
Users on unmanaged devices can only access the designated website through the browser, without being able to download, print, or sync files. They also cannot access content through apps, including Office desktop apps.
In this scenario, the corresponding label is assigned to one or more SharePoint sites. The label then enforces the configured setting. If the label and the settings in the SharePoint Admin Center conflict, the label wins.

With both options, it is thus possible to prevent downloading content from pages explicitly configured using PowerShell or labeled with a sensitivity label that enforces web-only access. It may take 5-10 minutes for the policy to take effect. It will not take effect for users who are already signed in from unmanaged devices.

Limitations of the solution with App Enforced Restrictions

The following restrictions apply when using App Enforced Restrictions:
  • If you limit access on unmanaged devices, users on managed devices must use one of the supported OS and browser combinations, or they will also have limited access.
  • If you limit access and edit a site from an unmanaged device, image web parts won't display images that you upload to the site assets library or directly to the web part.
  • If you're using classic SharePoint site templates, site images may not render correctly. This is because the policy prevents the original image files from being downloaded to the browser.
  • When Access Control for Unmanaged Devices in SharePoint is set to Allow limited, web-only access, SharePoint files cannot be downloaded but they can be previewed. The previews of Office files work in SharePoint but the previews do not work in Microsoft Yammer.

Use Conditional Access App Control

To create rules more granular / with advanced options, "Block Download" can also be enforced with Cloud App Security. This is done by using the "Conditional Access App Control" options in Conditional Access in Azure AD:
Cloud App Security then acts as a broker that is in front of the access to Office 365:

This also allows scenarios such as assigning a sensitivity label as soon as a document is downloaded.

Further options:
  • Add file filters to the policy: Extension, File Name, File Size, Sensitivity Label
  • Inspection Method: Can be used to configure include or exclude conditions 
  • Actions: Block, Protect (Apply sensitivity label to downloads & monitor all activities), require step-up authentication like MFA etc.,
  • Configure Alerts
Further details and how to implement the solution are described in this blogpost: Secure your environment by Conditional Access & App Controls

What is the difference between "Use app enforced restrictions" and "Use Conditional Access App Control"?

If the focus is only to prevent downloading on a unmanaged device, this can be achieved with both methods. The method via Microsoft Cloud App Security offers more detailed options, is not limited to SharePoint and Exchange, and does not have the limitations of App Enforced Restrictions. (see Limitations of the solution with App Enforced Restrictions) Another significant difference is the license required in each case. App Enforced Restrictions in combination with Azure AD Conditional Access required only an Azure AD P1 license. The Conditional Access App Control solution requires a Cloud App Security license for all affected users.








Dienstag, 8. Juni 2021

Sensitivity Labels & Default sharing link type

You can configure the default sharing link type for SharePoint and One Drive for Business in the SharePoint Admin Center:


With PowerShell you now can associate a default sharing link type to a sensitivity label.
Example:
If you have a label called "TOP SECRET". You could already configure this label to stop external sharing on sites associated with this label:

Now you can fine tune even this and specify the default sharing link type usingt PowerShell:
  • Set-Label -Identity 'TOP SECRET' -AdvancedSettings @{DefaultSharingScope ="SpecificPeople"}
  • Set-Label -Identity 'TOP SECRET' -AdvancedSettings @{DefaultShareLinkPermission ="Edit"}

This feature is now (06/08/2021) in public preview.


Montag, 7. Juni 2021

Customize Built-In Classifiers

As part of data classification in Microsoft 365 compliance center you can now customize built-in classifiers (sensitive information types) to meet organization's needs.
This update includes:

  • Ability to edit custom dictionaries

  • New validation functions like for example…:
    • Custom checksum validator
    • Date validator
    • Luhn check (The Luhn algorithm will detect any single-digit error, as well as almost all transpositions of adjacent digits.)
    • Etc.
  • Ability to define Proximity at pattern and element level
Rollout will begin mid-June and is expected to be complete by mid-July 2021.
For all of you who wants to start with custom sensitive information types; this feature is already here: https://docs.microsoft.com/en-us/microsoft-365/compliance/create-a-custom-sensitive-information-type