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.”

PasswordProtected-RMS

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

PasswordPFile

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

PasswordPFilePrompt

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!

Advertisements

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.

PersistentPermissions

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.

LabelOrder

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

LabelConditions

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.

ConditionChild

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.

LabelOrderAfter

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

ConditionLastChild

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 1.21.203.0 – Visual Marking Variables

Leave a comment

I had the opportunity to install the latest release of the new Azure Information Protection client PREVIEW 1.21.203.0, 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.

AIPPreviewVisualMarkings

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

Word: This content is Confidential

AIPPreviewWord

PowerPoint: This content is Confidential

AIPPreviewPowerPoint

Excel: Confidential

AIPPreviewExcel

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.

AIPAdministrator

Great news!!

G Suite Sync with Microsoft Outlook and RMS

Leave a comment

Today I had the opportunity to try out sending RMS protected messages to external recipients who use native Exchange-Outlook and G Suite Sync with Outlook.

I send a message to the external recipients from Outlook.

The external recipient with Outlook (I’ll call her Carmen) already has AIP client installed and RMS enabled in her tenant. The message opens with no issues.

The external recipient with G Suite Sync and Outlook (I’ll call him Ben) receives the message with the following text in the reading pane.

This message with restricted permission cannot be viewed in the reading pane until you verify your credentials. Open the item to read its contents and verify your credentials.

After double clicking on the message, the message below is displayed. Note that the sender is MOD Administrator from the sender tenant.

RMSProtectedMessage

After the Ben verifies his credentials, the email message is displayed.

So far so good.

Carmen replies all from Outlook; all is normal.

Ben replies all from his Outlook client; the original sender (MOD Administrator) and Carmen see this:

ReplyFromGSuite

However, when Ben replies all from Gmail via the Web browser, he sees the following message:

“You’ll automatically get an email copy of this message.” along with the label and the owner of the messages.

The original sender (MOD Administrator) and Carmen can view the message with no issues.

Ben, however, sees that the message comes from Office365@messaging.microsoft.com, not from his email address.

RMSReplyAllMessage

After the Ben verifies his credentials, the email message is displayed.

In summary – if you are using G Suite Sync with Outlook and responding to an encrypted message, be aware that your recipients may not be able to view your responses.

Thanks for reading!

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.

AIPViewerPermissions

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!

Older Entries