Password-protected and Azure Information Protection

Leave a comment

As you read Azure Information Protection client administrator guide on file types supported section, it is clearly stated that ‘Any file that is password-protected cannot be natively protected by the Azure Information Protection client. It lists a workaround by changing the default protection level via registry keys. If you’re not onboard with changing the default protection level and changing everyone’s registry keys, perhaps you would consider the following as a workaround.

Before I get to the workaround, it is necessary that I provide a bit of background on how I got here.

I classify an Excel file with RMS (Co-Author) rights, encrypt it with a password, and attach it to an email.

The recipient opens the attachment and sees this error:

“Excel cannot open the file <FileName>.xlsx because the file format or file extension is not valid. Verify that the file has not been corrupted and that the file extension matches the format of the file.”


Here’s the workaround I came up with.

  1. I classify the document with RMS enabled (same as before)
  2. I rename the file to <FileName>.pxlsx
  3. I attach the file to an email
  4. The recipient saves the file locally
  5. The recipient opens Excel, then opens the <FileName>.pxlsx
  6. The recipient provides the password to the file


7. The recipient selects ‘Yes’ in the dialog box


8. The file opens successfully

This is my workaround on this issue. I’m hoping that Microsoft will include password-protected files as one of the supported file formats in the near future.

Thanks for reading!


Persistent Permissions with Azure Rights Management

Leave a comment

We all know that embedded classification and protection follow the data regardless of where it is stored when using Azure Information Protection (AIP) and Azure Rights Management (Azure RMS), but what happens when the classification label is deleted from AIP portal.

Today, I had to create a scoped policy to test automatic classification for a group of pilot users. One of the requirements was to delete the scoped label after the pilot users completed their testing.

I created a scoped label (sub-label), under ‘Confidential’, called ‘Privacy – Read’ which is configured with Azure RMS with View, Reply, and Reply All rights. The label was configured to automatically apply when a Belgium National Number is detected. As you can see in the following two images that automatic classification was applied when the document was created and when it was attached to an email

I deleted the label from my tenant, and reopened the document I created earlier to check its classification label. The document was automatically reclassified as its parent label ‘Confidential’ which has no RMS nor any automatic classification configured. The same document was resent as an attachment to an email.

As you can see, permissions associated with the document persist even though the document was automatically defaulted to the parent label (Confidential) which is not configured for RMS protection.


Thanks for reading!

Azure Information Protection Automatic Classification

Leave a comment

Another interesting behavior I came across when adding conditions and the way labels are applied.

My Confidential AIP labels are configured as shown below.


I configured the parent label (Confidential) to automatically classify documents.


I entered the text below to trigger one of the conditions. I noticed that the document was labeled as ‘Confidential \ Restricted’ which is the last child label listed in my AIP portal. Well, this was, obviously, not what I expected.


To further test if it will always default to the last child label, I reordered the child labels. I moved the ‘Restricted’ child label up and now ‘Anyone (not protected)’ is listed as the last child label.


Just as I expected, the new document was labeled as ‘Confidential \ Anyone (not protected)’ automatically.


In this experience, I learned that I need to configure the conditions at the specific child label level to get the anticipated results.

Thanks for reading!



Azure Information Protection Client Preview – Visual Marking Variables

Leave a comment

I had the opportunity to install the latest release of the new Azure Information Protection client PREVIEW, which can be downloaded here.

One of new features included with this client release is the ability to apply different visual markings for Word, Excel, PowerPoint, and Outlook. I’m not sure how business users will take advantage of this, but I had to try it out.

In my Azure Portal, I configured my Confidential \ All Employees label to apply specific watermark to Word and PowerPoint, and a different watermark to Excel. Keep in mind that watermarks are not supported in Outlook.


When a document is classified as Confidential \ All Employees, the watermark is displayed as:

Word: This content is Confidential


PowerPoint: This content is Confidential


Excel: Confidential


Thanks for reading!


Azure Information Protection Administrator Role

Leave a comment

Great news for organizations that have concerns about granting Global Admin or Security Admin rights to users who need to manage Azure Information Protection policy.

The Azure Active Directory team have added a new role named Information Protection Administrator.  Members of this role can manage Azure Information Protection labels and policies using Azure portal, and use RMS PowerShell

Note that the role is currently in public preview.


Great news!!


Azure Information Protection (AIP) – Forward Permissions

Leave a comment

This post is another one of those “I found interesting” topics.

In Azure Information Protection, I configured users to use Viewer, one of the preset permissions templates. I accepted the default settings that the users have rights to View content, Reply, and Reply all.


I sent an e-mail with an attachment classified as Restricted. This document is encrypted with Azure RMS.

The recipient of the e-mail could NOT print, edit, copy and paste into a different document. However, the recipient COULD forward the e-mail to a different recipient.

After much testing and researching, I found that the Forward option enables users to forward an e-mail message and to add recipients to the To and Cc lines. This right does not apply to documents; only e-mail messages. This information is referenced here.

I hope this helps in case you need to explain this to users during your AIP rollout.

Thanks for reading!


Encrypt E-mail with Attachments

Leave a comment

As I continue to test different settings in Azure Information Protection, I want to share one that I find interesting.

I configured AIP for e-mail message with attachments to automatically apply a label that matches the highest classification of those attachments.

I created an e-mail where a default label ‘Official Use’ is automatically applied to my e-mail message. I then attached a document classified as ‘Restricted’, the classification of my e-mail message automatic changed to ‘Restricted \ All Employees’. This is the expected behavior.

I then sent the e-mail with the attachment to a trusted partner (in this case myself with a different domain) which I have configured ‘Viewer’ rights to view and reply the e-mail and the attachment.

Below is the e-mail message I sent to the trusted partner.


However, when the trusted partner (again, myself with a different domain) received the e-mail and tried to click on the ‘Read the message’ link (image below shows e-mail message received by the trusted partner), the trusted partner received “You do not have permission to view this message.”


After much testing, in order to allow my trusted partner to read the message, I had to change permissions from ‘Viewer’ to ‘Reviewer’ in Azure Information Protection.

As I continue to work with Azure Information Protection, I find myself learning new things every day.

Thanks for reading!


Older Entries