Vue normale

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

How to Use the Extract Sensitivity Labels Graph API

A Graph API is available to extract details of the sensitivity labels assigned to SharePoint Online documents. This article explores how to extract the information from files in a document library and use it to create a report. The nice thing is that once you have the data, you can slice and dice it any way you wish in Excel, Power BI, or whatever tool you prefer.

The post How to Use the Extract Sensitivity Labels Graph API appeared first on Practical 365.

Microsoft Retires AIP Add-On for Office

Need Recedes for Unified Labeling Client

On April 11, Microsoft announced that they will retire the AIP client, aka the Unified Labeling client, aka the AIP add-on for Office, on 11 April 2024. The add-on has been in maintenance mode since January 1, 2022, so its final retirement was only a matter of time. Once retirement happens, users cannot assign sensitivity labels to documents through the add-on.

A Long Road

In 2016, when I first started writing about how to protect Office documents with labels, the labels were called Azure Information Protection labels and users needed to install the add-on to add elements like the information protection bar and the code to apply rights management to documents. The situation was natural because Azure Information Protection was a separate product that targeted Office but had no formal alignment with Office development. The add-on was only available for Office on Windows.

Things changed when Microsoft decided that sensitivity labels were strategically important to Office 365, which meant that they needed to build support for sensitivity labels across the infrastructure in apps like SharePoint Online and Exchange Online and desktop, browser, and mobile apps. Sensitivity label support is now broad and deep across Microsoft 365, including for container management of sites, groups, and teams. Regretfully, sometimes Microsoft demands additional licenses for features that seem very basic, such using the Syntex-SharePoint Advanced Management license to control the assignment of default sensitivity labels to SharePoint document libraries.

In 2019, Microsoft started the process of removing the add-on by incorporating the code to handle sensitivity labels in the Office applications (native mode protection). The goal is to provide the same or better functionality in the out-of-the-box Microsoft 365 apps for enterprise (Office desktop) versions of Word, Excel, and PowerPoint. Microsoft says that the Microsoft 365 apps for enterprise “now have most of the capabilities found in the AIP Unified Labeling add-in for Office as well as advanced capabilities not possible with the AIP Unified Labeling add-in for Office.” The most important of these capabilities are:

  • PDFs exported from the Office apps retain protection applied by sensitivity labels.
  • Sensitivity labels can protect meeting invitations (including attachments) and responses.
  • Account switching.
  • Users cannot disable labeling controls.

Microsoft has long stressed that incorporating code from the Microsoft Information Protection SDK to make applications natively aware of information protection leads to better performance and increased stability. In other words, something that’s built-in is likely to work better than when an application needs to load in external code.

Native protection is only available with the subscription versions of Office. The functionality isn’t supported by perpetual versions of Office like Office 2019.

Making Changes to Ease Migration

Technologies that affect how people work are usually harder to migrate to new platforms than background processing is. Changes to Office applications are good examples of the truth of this assertion (as anyone who remembers the introduction of the ribbon in Office 2007 can attest).

As an example, the add-on features an information protection bar that people like. The Microsoft 365 apps don’t use the information protection bar. Instead, Microsoft has changed the menu and title bars of the Office apps to highlight labels in a different way, including displaying different colors for different labels. The latest tweak is in Outlook desktop, where the latest builds feature a prominent new button to allow users to more easily assign a sensitivity label to emails (Figure 1).

Applying a sensitivity label with Outlook

Unified labeling client
Figure 1: Applying a sensitivity label with Outlook

Other Azure Information Protection Elements

I stopped using the unified labeling client two years ago. However, I have installed the unified labeling client on PCs to get other elements that came with the add-on such as the Azure Information Protection PowerShell module and the ability to classify and protection files from the Windows Explorer. The PowerShell module is especially helpful when the need exists to remove sensitivity labels from files.

Microsoft says that they are not retiring these elements, nor are they retiring the viewers that allow people to view protected content on Windows, iOS, and Android, or the Azure Information Protection Scanner. Microsoft says that following the retirement of the add-on, they will remove it from the installable package available in the Download Center. User will be able to install the new version of the package to access the other elements, which will also be rebranded as Microsoft Purview capabilities.

Time to Move On

The unified labeling client or add-on for Office has served its purpose. It’s time to let it go and migrate as quickly as possible to use the built-in capabilities that exist in Office. Apart from the small fact about the retirement, it’s clear that Microsoft has poured engineering effort into building out the sensitivity label infrastructure across Microsoft 365 for the last several years. Benefit of that work isn’t available to the add-on, which is a good a reason to move on as anything else.


So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Why Some Outlook Clients Encrypt Outbound Messages Differently

Outlook Sensitivity Labels Processed in Different Ways

An observant reader noticed that Outlook clients encrypt messages using sensitivity labels in different ways. If you look at Figure 1, you see three messages sent to the same person using Outlook Mobile, OWA (or Monarch), and Outlook for Windows. The Ultra Confidential sensitivity label protects all messages with encryption, but only the copy sent from Outlook for Windows is protected in the sender’s mailbox. The other copies sent from Outlook Mobile and OWA are protected when they arrive in the recipient mailbox.

Outlook lists three messages from different clients with different outcomes from Outlook sensitivity labels
Figure 1: Outlook lists three messages from different clients

The obvious question is why this situation happens. Shouldn’t all Outlook clients produce the same result? Alas, this is not the case. As explained in Microsoft documentation, “When a sensitivity label is configured with encryption, the encryption process depends on the client platform.” In effect, Outlook desktop is the only client that contains the code necessary to encrypt an outbound message.

Other Outlook clients rely on passing messages through the Exchange Online transport service. The transport service has super-user capabilities and can apply the necessary protection. When transport detects that a message has a sensitivity label with encryption that isn’t yet protected, it does the necessary work to protect the message by placing the message and its attachments in a rpmsg “wrapper” before sending the message on to the next hop in its journey.

Client Processing for Protected Messages

The rpmsg wrapper is how Outlook sensitivity labels impose rights management for protected messages. The receiving client must unpack the message from the wrapper and respect the rights assigned to the recipient by the publishing license that’s included in the wrapper. The receiving client sends the publishing license to the information protection service to obtain a use license that allows the client to open the message.

Clients perform the processing to allow users to read protected messages without being prompted for credentials. If the client can’t obtain a use license, it displays information from the rpmsg to direct the user to the Office 365 Message Encryption (OME) Portal. If the user can prove their rights to open the message by signing into the OME portal with an account included in the recipient list, they can view the message contents online.

The reason why two out of the three messages are unencrypted in the Sent Items folder is that these are the messages that clients didn’t protect. Outlook desktop protected the other message before it submitted the item to transport. In

all cases, the sender can be confident that the message was fully protected when it left the transport service for onward routing.

Clients and the MIP SDK

Microsoft could incorporate the code (using the Microsoft Information Protection SDK) to protect messages in OWA and Outlook mobile. However, this approach doesn’t seem to make sense. Apart from the extra complexity introduced into the client code base, OWA can only be used online. Outlook mobile clients could protect files, but they usually work in a connected mode (either Wi-Fi or a cellular network). Outlook desktop has always been able to work offline, so its developers incorporated the code to process protected inbound and outbound messages when working offline.

Growing Use of Outlook Sensitivity Labels

The number of messages protected by Outlook sensitivity labels is steadily increasing. I do not have firm data to back this assertion, just anecdotal evidence from customer interactions. Microsoft continues to pour engineering effort into making sensitivity labels more accessible and useful, so I expect the trend to continue. And when your tenant starts to use sensitivity labels to protect email, you’ll know why some Outlook clients protect messages in a different manner to others.


Learn about using Exchange Online, Outlook clients, and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Using PowerShell to Generate a Report About Sensitivity Label Settings

You can manage sensitivity label settings through the Microsoft Purview compliance portal, but it's hard to see all the settings for labels in a consumable manner. This article describes how to use PowerShell to extract and report sensitivity label settings, including highlighting rights assignments that might be out of date. It's an example of just how useful PowerShell is to Microsoft 365 administrators.

The post Using PowerShell to Generate a Report About Sensitivity Label Settings appeared first on Practical 365.

Azure Information Protection – Nouveau Module PowerShell remplaçant AADRM

Microsoft a officialisé la sortie d’un nouveau module Powershell pour administrer Azure Information Protection : AIPService. Dans le même temps l’éditeur à annoncé la fin de la prise en charge du Module AADRM pour le 15 juillet 2020. AADRM est maintenant obsolète et remplacé par le module AIPService, qui fournit la même fonctionnalité avec les cmdlets […]

The post Azure Information Protection – Nouveau Module PowerShell remplaçant AADRM appeared first on Les2T.

Microsoft Tech Summit 2018 Paris – Protégez vos données avec Azure Information Protection

J’animerai le 14 mars prochain une session au Microsoft Tech Summit 2018 à Paris. Pendant une heure, nous discuterons des nouvelles fonctionnalités en matière de détection, classification et protection des données partagées au sein de votre organisation grâce à Azure Information Protection.

N’hésitez pas à vous inscrire dès maintenant, l’événement est gratuit !

 

A Sneak Peek at Application Management for Edge

This blog has been active for at least six years. To this day, I probably receive more questions about BYOD and the various options we have for management with regard to personal devices, than any other topic that I have written about. I think this just goes to show the types of challenges and questions that consultants and service providers face in the wild. It is also telling because I would have expected by now to see these types of questions taper off as the market “figured it out,” so to speak.

But we haven’t quite figured it out yet. Especially for Windows devices (ironically). Part of the problem, I think, is that we can approach the BYOD concerns in several different ways, so folks need help navigating their choices. While we have many tools available which can help us to enable BYOD experiences, unfortunately, every solution has its trade-offs. Some good, some not so good.

For example, take Windows Information Protection (a.k.a. MAM for Windows). This solution can be difficult to configure, and has a fairly large impact on user experience. Certainly it is not something you would casually roll out without some pretty decent planning and testing in advance, not to mention communication and expectation-setting with your user base. Plus, you’ll often find yourself needing to do maintenancy-things like update your approved network locations and cloud resources list, so that certain websites can be considered “inside the corporate fence” and play well with all of your corporate-protected applications.

Adding new cloud apps to WIP

And even after all that effort, you’ll still notice some serious limitations and drawbacks to the solution. To make matters worse, it is my understanding that Microsoft is stepping away from further development on WIP; when I have asked them about possible improvements to the product, they have pointed me toward Endpoint DLP as an alternative (thanks but no thanks…it’s an E5 solution anyway).

Therefore, I generally recommend against WIP, and suggest that customers either block personal Windows device access outright, or use an alternative approach like requiring device enrollment and full management (which does open another can of worms) or settling for the “Limited web access” experience via Conditional Access / App enforced restrictions.

In short, no matter which path you walk down with regard to Windows devices, every option seems riddled with gotchas and caveats that put a sour taste in your mouth. (And may I just add that it is absolutely maddening that Windows–Microsoft’s own product–still has a less mature and less functional app management solution than iOS and Android? I mean MAM for mobile devices is awesome–so why does it still suck on Microsoft’s own OS?!)

Anyway, soon we will have another option, and this one looks more promising (fingers crossed). It’s called Application Management for Edge. I believe it was first announced publicly here. There was also a digital event where they teased a bit of this functionality in a short demo (see the 11:20 mark in the IT Management and Hybrid Work breakout). Some notes from my observations:

Notice the new policy type

First, we see in the demo that there will be a new App protection policy type in Endpoint Manager (Apps > App protection policies). It appears the current policy we have will be renamed to Windows Information Protection, and we will be given a new option called Windows.

You can only select Edge at first

Based on these screenshots from the demo, only the Edge app is going to be available at first, but I am hoping that in the future we will see other Microsoft 365 apps (for the desktop) added here as well, including Word, Excel, PowerPoint, Teams, etc. (I have no idea if this is true but it would be awesome if so).

In any event, being able to target the Edge browser has some important benefits. First, we can enable a better web access experience that is tied to a corporate Edge profile, rather than a pre-defined network boundary, where we have to add all of our “protected” websites and apps to a list in advance. Then, it appears we will have the ability to set Data protection boundaries between the corporate profile and personal profiles, just like we experience with App protection policies on mobile devices (and it is about time)!

Set boundaries on data flow

We even have Health checks, and I spy that Minimum OS version as well as Defender’s Max allowed device threat level integration will be included off the bat as well, where the threat level on the device can become a bar for access to corporate data.

Configure health checks

Once the policy is implemented, the end user experience looks pretty slick so far  (and it doesn’t say this anywhere but I wonder if there is a Conditional Access policy requirement at play here as well, take a look and let me know what you think):

Access blocked from personal profile

When a user attempts to access a corporate resource such as email from a personal profile in Edge, they are blocked, and given an option to Switch Microsoft Edge profiles.

Sign in with the corporate profile

They sort of gloss over this prompt in the demo video, but when you sign in with a corporate profile, there appears to be an option to enroll your device in order to “Stay signed in to all your apps.” There is a checkbox here, “Allow my organization to manage my device.” Then at the bottom is an option “No, sign into this app only.” If you click OK without checking the box, I assume that would have the same effect as clicking the No… option.

Hopefully we will get an opportunity to remove this prompt entirely, in cases where we do not want users enrolling personal devices (I would suggest that blocking personal enrollment via device restrictions should automatically remove this screen from the end user’s view, but I suspect that it would still remain, so the end user who is restricted from enrolling could get an error if they attempt to check the box–we’ll see if Microsoft is smart enough to improve this flow before it is released to Public preview).

Health checks complete

We can see that the health checks have passed, the policies have applied, and the profile is now available on the device.

Notice the corporate contextClearly, we can see the user is now signed in with a corporate profile (and I suspect that this means any site the user visits under the corporate profile would be within the “corporate boundary,” without us having to manage a list of apps and websites in a “network boundary” within a policy somewhere).

Finally, we can see the policy in action, blocking a copy/paste action:

Block copy/paste policy in action

All in all, a massive, MASSIVE improvement over the legacy WIP experience: easier to set up for the administrator, and easier for the end user, as well. Although, until they add client app support for the desktop apps, this solution appears to be limited to web-only access at first, which is somewhat similar to the experience we have always had with Limited web access (using Conditional Access App-enforced restrictions). Still, I am optimistic that we will find this “profile-based” app management solution allows for more granularity and flexibility as development continues. I am excited to see this released to pubic preview (I haven’t seen a date on that yet), and of course, everything the future holds beyond it.

(I just hope this new policy will be included with Business Premium, and not held behind the E5 paywall!)

 

The post A Sneak Peek at Application Management for Edge appeared first on ITProMentor.

Microsoft Tech Summit 2018 Paris – Protégez vos données avec Azure Information Protection

J’animerai le 14 mars prochain une session au Microsoft Tech Summit 2018 à Paris. Pendant une heure, nous discuterons des nouvelles fonctionnalités en matière de détection, classification et protection des données partagées au sein de votre organisation grâce à Azure Information Protection.

N’hésitez pas à vous inscrire dès maintenant, l’événement est gratuit !

 

❌
❌