Azure Information Protection (AIP) – Forward Permissions

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!

Advertisements

Encrypt E-mail with Attachments

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.

EmailRestrictedAttachment

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

EncryptedMessage

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!

Protect and Manage Sharing of Sensitive Documents

In my previous post, Classifying and Protecting Data in Office 365, I created an AIP (Azure Information Protection) label / policy that applied a footer text with “Sensitivity: Confidential”.

In this post, I’ll describe how you can take advantage of the properties stored in the document, by applying a rule to protect information sharing.

For example, to protect documents from being sent to external organizations via e-mail, you can configure a rule in Exchange to detect the document properties with a sensitivity label. Here’s an example of the configuration I created.

Exchange Mail Flow Rule

When a user within your organization attempts to send an e-mail with an attachment labeled with ‘Confidential’, the mail flow rule blocks it and the message sender receives the following delivery failure message as seen below (with the recipients e-mail addresses grayed out).

BlockedByMailFlowRule

However, if you need to send to your trusted partners or customers, you can add their specific domains to the exception list in the mail flow rule. In the example below, I added one trusted domain to the rule.

MailflowException

With this exception, I was able to send the document labelled with ‘Confidential’ to the external recipients with the domain specified.

With the latest and greatest changes to AIP, and Office 365 Message Encryption capabilities, announced during the recent Microsoft Ignite Conference, the user experience of protecting and sharing your documents may be different than what is written in this post. I’ll continue provide updates and new information becomes available.

If you’re interested in learning more about data classification and protecting your organization’s information assets, feel free to connect with us at http://www.centricconsulting.com.

Retention and AIP Protected Documents

This is a follow up to my previous post (Which Office 365 Retention Policy Should You Use?).

Before I jump in, I want to provide additional information on documents stored in my SharePoint site.

I configured Azure Information Protection labels and published them. Note that All Employees sub-label of Restricted label is configured with protection. I created several documents, applied these labels manually and automatically, and uploaded them to SharePoint.

AIP Labels2

After applying retention policies to these documents (my previous post), one thing I noticed after the retention policies automatically applied to these documents, two of my documents classified as ‘Restricted All Employees‘ have no policies applied to them.  I waited additional days thinking that I was just too impatient.  After several days, still nothing.

AIP RMS Enabled

I have always known that AIP protected documents are not viewable in Office Web Apps, but I couldn’t understand why retention policies were not able to apply to these documents.

After researching more on this behavior, I’ve learned that SharePoint is not able to index AIP protected documents.  Because of this there are no metadata available for the retention policies to query on these documents.

I hope this helps explaining why O365 retention and SharePoint don’t always give you the expected results.

Which Office 365 Retention Policy Should You Use?

As I started to work on applying retention policies to documents stored in SharePoint using Office 365 Security & Compliance Center, I was confused why the retention policies were not working as I had hoped.

My objective was to have retention policies automatically applied to documents stored in SharePoint without needing the end-user to select the correct retention policy. I created several labels and policies under Classifications, configured one of them to detect content that contains specific words or phrases, and set them to auto-apply to my SharePoint site.  It gave me a warning that it may take up to seven (7) days for the label to apply.

ClassificationsLabels2

I waited for seven days, but nothing showed up in my SharePoint site.

After a bit of digging I found that label policies created under Classifications only appear for users to manually select from SharePoint.

SharePointLabelPolicies2

Since this did not meet my objective, I deleted these label policies from O365 Security & Compliance Center.

After more research and testing, I found that in order to achieve my objective, I had to create the retention policies under Data Governance.

DataGovernanceRetention

Again, I had to wait.  But this time it only took one day for the policies to auto-apply.

AutoApplyRetentionPolicies

In summary, if you want users to manually select retention policy, use Label Policies under Classifications.  If you want an automated method, use Retention under Data Governance.  I hope this helps others who have tried to make sense of which retention policy method to use.