Microsoft recently updated Microsoft Office to their Office 365 Message Encryption (OME), specifically with how it relates to Azure RMS. This greatly simplifies the ability to send an encrypted email from within the Outlook desktop application. If you implemented a process like the one identified in this original article, you may wish to consider simplifying your process.
Who does this affect? Azure RMS licensed organizations with Office 2016 Pro Plus that implemented encrypted email ability similar to the process in this original article.
Why should you care? It supports the latest encryption changes from Microsoft, and the ability to send encrypted emails that can be decrypted automatically in the Outlook mobile app, Outlook for the Web, and viewed via a single link in Outlook Desktop (users no longer need to download an html file and then open it).
To make changes to support these newest features, you will have to undo any custom changes you made and ensure your target computers are on Office release 1807 or newer. Specifically, the following changes should be made if you created a process similar to the process outlined in this original article:
- Update your transport rule in Exchange Online to use the new encryption technology. You want the action to be “Apply Office 365 Message Encryption and rights protection” and not be “Apply the Previous Version of OME”.
- Ensure your IRM Configuration shows AutomaticServiceUpdateEnabled = True by running Connect-AADRMService and then Get-IRMConfiguration against your Azure tenant.
- Ensure your onboarding policy is set to the group or users you want via Get-AadrmOnboardingControlPolicy. In this example, to apply to all users in the tenant run: Set-AadrmOnboardingControlPolicy -UseRmsUserLicense $False -Scope All
- Test your configuration against a user. Run Test-IRMConfiguration -Sender <email alias>. It will show templates available to the user, which will include the new Encrypt template.
- Remove the GPO settings that deploy the MessageClassifications.xml file you created, as well as the three registry settings AdminClassificationPath, EnableClassifications, and TrustClassifications. Remember to switch the policy settings to Delete from Update/Replace/Create. Otherwise, the registry settings and files will remain on the target computers. Once you verified it is fully deployed, you can delete the GPO object if no other settings are being controlled by it.
- Ensure users who want to encrypt from Outlook desktop are on Office build 1807 or newer. Your users may not be on the Monthly Channel for office updates. If this is the case you will either:
- Switch channels for specific users and then force Office to look for updates.
- Change your Office 365 tenant global setting to set all Office applications to the monthly channel, and then rollout a GPO change to change the Update Branch for all computers. The GPO change requires the Office 2016 templates to be imported into your central store. The policy is found under Computer Configuration > Policies > Administrative Templates > Microsoft Office 2016 (Machine) > Updates. The Policy Name is Update Branch. Enable the policy, and type Monthly as the setting. There is not a dropdown.
- Update documentation to show new screens/settings. For example, once properly implemented, Encrypt will show in the dropdown on a new email > options > Permission. If you are not seeing this and still see your old configuration you created using the xml file and registry settings, ensure those are removed from the target computer and verify the build number of Office on the computer.
End of Update
Office 365 message encryption is an easy-to-use security tool that businesses can leverage if they’re using Exchange Online. This is a great tool for a company that doesn’t want to go through the complications of implementing S/MIME encryption.
In a simple scenario, all an Administrator needs to do is modify the Exchange Online rules and create a rule based on a sender, recipient, word in the subject line, etc. Based on criteria, the action to choose on the rule is just “Apply Office 365 Message Encryption”. So for example, one can create a rule that if an associate puts the word “Encrypt” the subject of an email, that message will automatically encrypt.
In a slightly more complicated to scenario to implement, it would be ideal for your associates to have a single click to apply encryption to any outgoing email message. This click could come from the Outlook client, or from within the Outlook Web App. Simplifying this process helps to reduce error and will increase adoption of email message encryption. It is this scenario that this blog details how to implement in your environment, specifically, using exchange message classifications and message permission options.
The end game is to have an easy experience for associates to simply “click a button” and know that their outgoing email will be encrypted.
Skillsets and Assumptions
- You’re utilizing Exchange Online and Office 365. On-premise exchange is not required.
- You have a general familiarity with Exchange Online Rules
- You know how to connect to your Exchange Online environment via PowerShell and run simple commands
- You know how to push out files and registry changes via Group Policy
- You are not required to apply additional Azure Rights Management (ARM) or leveraging ARM for your implementation.
Step by Step
1. Decide what your end users will see when they want to encrypt an email. When they choose from Options>Permissions in a new email, what will they see? Will the option say “Encrypt Message” or “Send Encrypted”, etc.
2. Setup the Message Classification in Exchange Online
- Connect to your Exchange Online environment using PowerShell
- Run Get-MessageClassification to view a list of your current classifications. If your Exchange Online environment is simple, you likely won’t have any classifications returned.
- Create a new message classification for encrypted emails. For example: New-MessageClassification ApplyEncryption -DisplayName “Apply Message Encryption” -SenderDescription “This email will be encrypted using Microsoft Office 365 Encryption.” -RecipientDescription “The sender has selected to send you an encrypted email using Microsoft Office 365 Encryption.” Note: Locale will be your default locale, if your organization is locale-specific you may want to consider locale-specific versions of the message classification.
- Run Get-MessageClassification to verify your results. If successful, your new classification will be returned along with any pre-existing classifications.
- Obtain and record the Guid identification of the new classification and record this identifier down for later by retrieving the ClassificationID of the new classification you created. (Get-MessageClassification –Identity ApplyEncryption).ClassificationID
3. Setup a new rule in the Exchange Admin Center. The rule name does not need to match any description names. Choose “The message is classified as…” option and choose the new classification you created on the server. For the action, choose “Encrypt the message with Office 365 Message Encryption”. Add any auditing options or additional conditions/actions as needed by your environment. Note: You may need to create your rule by using the “Apply Rights Management…” selection from the add rule dropdown on the main Rules page.
4. After a certain amount of time (sometimes up to 24 hours) the new classification should start to appear for associates under “Set Permissions” when they create new messages in O365 Mail. If this is all you need, you can stop here. However, most associates also use the Outlook client.
5. Create the Message Classification XML file that will be pushed to Outlook clients using Group Policy.
- Export your existing Message Classifications using Export-OutlookClassifications.ps1 > C:\MessageClassficiations.xml on your on premise exchange server, then modify the resulting XML file to include only those classifications you care to appear in the Outlook clients. OR
- If you do not have an on premise exchange server or have a small environment, just make a small XML file in Notepad or other text editor and save it as something like MessageClassifications.xml.
- Be sure to give the classification Name an identical name to what you used for the DisplayName property when creating the classification (for consistency).
- Set the Description to your SenderDescription when you created the classification (for consistency).
- Set the Guid property to the ClassificationID of the message classification that you created in the earlier steps.
6. Create registry changes that will tell Outlook to use the created Message Classification XML file.
- Determine a location where the XML file will reside on client computers.Typically in the Outlook program folder or a shared folder/directory on the computer. For this example, I am simplifying and just pretending that I will be pushing out the XML file to C:\Windows.
- You will need to modify or add the following registry information at HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Policy
- AdminClassificationPath – String – the path to where you will be pushing the MessageClassifications.xml file out to on client computers
- EnableClassifications – DWORD 1
- TrustClassifications – DWORD 1
- Note: If you’re running a mixed Office environment, you will need to edit additional registry keys for however many versions you are supporting. Don’t forget to use an AdminClassificationPath that is accessible to all users of the computer(s).
7. Create a Group Policy object to push your MessageClassifications.xml and the above registry changes out to client computers. Be sure that the XML file source is somewhere that all users can access on your network and that the XML destination is a local destination on client computers that are accessible to all users of the workstation(s). Once pushed out to all your clients, the option to encrypt a message will appear in Outlook. If this does not appear or is not working, the first place to check is to make sure the guid listed in the XML file matches the ClassificationID guid on the classification you created in Exchange Online.
I recommend doing this a test group of users/computers before doing a companywide rollout. Even before that phase happens, be sure to test, test, test! This is encryption we’re talking about here, so it’s important that it works right every time. I’m sure there are a lot of ways to automate these steps, and you’ll definitely want to do some reading up on that if your organization is large enough to benefit from the automation.
Once you start digging more, you’ll find a plethora of other things you can do with Office365 encryption, such as automatic decryption rules and automatic encryption rules based on words or patterns (such as a SSN) in email messages. I encourage you to explore these and implement what would be appropriate for your company.
If you would like to take this process a step further and implement Azure Rights Management (ARM), you can further restrict messages to take greater control over confidential messages. But that’s a blog for another day.