_______________________________
In This Chapter
- Message Hygiene
- Data Loss Prevention
- Journaling
- Azure Information Protection
- Office 365 Message Encryption
_______________________________
In the previous chapter we covered some of the basics of Simple Mail Transport Protocol (SMTP) in Exchange Online and how we can work with it in PowerShell. This chapter will cover the more advanced components of SMTP in Exchange Online – message hygiene, Data Loss Prevention (DLP), Journaling and Rights Management. Additional tasks that can be done with PowerShell may require additional licensing in Exchange. Some of the features talked about may need additional licensing in order to utilize them in Office 365.
This chapter covers enterprise level features that are more likely to be used by larger messaging environments. Generally larger environments dictate more strict compliance requirements rather than smaller environments. Legal departments tend to be larger and more structured with policies in place for protecting all forms of communication and email is heavily regulated.
DLP is an interesting feature that was introduced into Exchange Server 2013, continued in Exchange Server 2016 as well as Exchange Online. This features allows for more advanced transport rules for processing emails containing potentially sensitive information in them. Additional knowledge of Regular Expressions (RegEx) and compliance regulations may be needed in order to make the most of this feature. RegEx allows for more complex transport criteria.
The Journaling feature is a feature commonly used in Exchange. Typically Journaling is used for compliance, business continuity or discovery purposes. Messages can only be journaled to a destination external to Office 365. This is a key component to keep in mind if you are moving to Office 365 from Exchange on-premises.
Rights Management is a particularly interesting feature that also requires some licensing outside of Exchange Online. While Rights Management will be covered with respect to Exchange Online and will include the requisite background services and configuration. We will set up policies and then apply them to emails only.
Lastly, we'll cover Message Hygiene which entails configuring Exchange Online Protection, DMARC, DKIM, SPF and more.
Message Hygiene is a nebulous topic, but one of importance from an administration and user perspective. According to some sources, 60% of all email is SPAM, making this an important component of any mail system. For administrators reducing the amount of Spam or malware that enters Exchange makes for less supports calls, fixing or troubleshooting issues with email. For the end user, a reduced amount of bad messages makes for a better experience. In this chapter will cover external controls, Malware filters and Exchange Online Protection (EOP).
In order to block Spam prior to the message being delivered to any Exchange Mailbox, there are some additional things we can enable to help control Message Hygiene.
- Domain Key Identified Mail (DKIM) – Allows a recipient of a message to verify the sender of the message. Requires a third party product like PowerMTA, DkimX or a DKIM Transport / Signing Agent. Signs the email with a digital signature that is verifiable with via the signers public key.
- Domain Message Authentication Reporting & Conformance (DMARC) – A Special TXT DNS record used by servers on how to handle DKIM or SPF failures and where those failures are reported.
- Sender Policy Framework (SPF) Record – A special DNS record that provides a list of valid SMTP servers for your domain.
- Exchange Online Protection (EOP) – Built-in service for providing Message Hygiene for Exchange Online.
** Note ** Only one of the above can be configured with PowerShell, but these items should be on your list to begin protecting Exchange Online. SPF and DMARC both require external DNS records to be configured. A good article on this can be found by Microsoft - https://blogs.technet.microsoft.com/fasttracktips/2016/07/16/spf-dkim-dmarc-and-exchange-online/.
For DKIM, there are options to configure this feature either in the Exchange Admin Center or with PowerShell. For PowerShell we can see what cmdlets are available first:
Get-Command *DKIM*
We can review the default configuration for DKIM:
Get-DkimSigningConfig
More information about the actual DKIM configuration can be revealed using Format-List (FL) instead of the default Format-Table (FT).
Get-DkimSigningConfig | Fl
Some of the most important pieces of the configuration are listed in the red square:
Enabling DKIM for a domain is quick and easy:
Set-DkimSigningConfig -Enabled:$True -Identity 'PracticalPowerShell.com'
Make sure you have created your two CNAME records that are needed for proper DKIM operation.
Beyond the external control above, Exchange Online also provides it's own anti-malware / anti-virus service called Exchange Online Protection or EOP. EOP provides layers of protection, some are configurable in your specific tenant, while many others are inherent to the service and are not exposed for configuration purposes. Similar to how other third-party providers will scan messages as they arrive at their servers, EOP will scan messages looking for known payloads, attack patterns and more. The configurable portion of EOP allows for these types of filtering:
- Malware - configure notifications and how to handle certain file types.
- Connection Filters - consists of IP Allow and IP Block lists for controlling who can send email to you.
- Spam Filters - provides quite a few configurable options like Bulk SPAM controls, domain/email block and allow lists, international SPAM controls, as well as a set of more advanced controls.
- Outbound SPAM - configure notifications if outbound SPAM is detected.
Now that we know the available configurable options for EOP, how do we modify or configure these settings with PowerShell?
PowerShell
First off, we'll start with the Malware Filter configuration:
Get-Command *MalwareFilter*
In Exchange Online, the Malware configuration consists of two parts, Malware Filter Policy and Malware Filter Rules. The Rules roll up and can be associated with a Policy in order to be applied. There are no requirements to use the Malware Filter Rules as we can see that none are provided in a brand new tenant.
Malware Filter Policies
In a brand new tenant, there are no defined Malware Rules in EOP. If we were to run 'Get-MalwareFilterRule', no results would be returned. However, there is a default policy, the same one you see in the Exchange Admin Center, and the 'Get-MalwareFilterPolicy | Fl' cmdlet will display that configuration:
We can configure this Malware Filter Policy using PowerShell, so let's review some examples of this configuration:
Get-Help Set-MalwareFilterPolicy -Examples
Example
Management has decided they would like to change the way malware messages are processed by EOP. First they would like to have Administrators notified when a malware messages is detected. Next, if the sender is internal, they would like to notify that user if a malware message was sent from their account. Lastly they would like to notify an external sender if their message contained malware as well. How can we do this? First, we would need to review the full Get-Help for the Set-MalwareFilterPolicy cmdlet.
Parameters we can use:
First step is to allow custom notifications, set a From address and a display name for that address:
-CustomNotifications $True
-CustomFromAddress [email protected]
-CustomFromName 'Big Box IT Admins'
Next, we have the internal message notifications for any messages sent by your Exchange Online mailboxes. We will enable notifications to administrators, the sender (internal), which admin email address to use and a custom subject and body for the notification.
-EnableInternalSenderAdminNotifications $True
-EnableInternalSenderNotifications $True
-InternalSenderAdminAddress [email protected]
-CustomInternalBody 'Dear user, you have recently sent out a message that contains malware. Please contact the IT Department.'
-CustomInternalSubject 'Malware detected!'
Next, we have the external message notifications for any messages sent to your Exchange Online mailboxes. We will enable notifications to administrators, the sender (external), which admin email address to use and a custom subject and body for the notification.
-EnableExternalSenderAdminNotifications $True
-EnableExternalSenderNotifications $True
-ExternalSenderAdminAddress [email protected]
-CustomExternalBody 'Dear sender, you have recently sent out a message that contains malware. Please contact our IT Department @ [email protected]'
-CustomExternalSubject 'Malware detected!'
Combining all of the options makes for one very long one-liner:
Set-MalwareFilterPolicy Default -CustomNotifications $True -CustomFromAddress [email protected] -CustomFromName 'Big Box IT Admins' -EnableInternalSenderAdminNotifications $True -EnableInternalSenderNotifications $True -InternalSenderAdminAddress [email protected] -CustomInternalBody 'Dear user, you have recently sent out a message that contains malware. Please contact the IT Department.' -CustomInternalSubject 'Malware detected!' -EnableExternalSenderAdminNotifications $True -EnableExternalSenderNotifications $True -ExternalSenderAdminAddress [email protected] -CustomExternalBody 'Dear sender, you have recently sent out a message that contains malware. Please contact our IT Department @ [email protected]' -CustomExternalSubject 'Malware detected!'
These changes should then be verified:
Malware Filter Rules
To enhance the Malware Policies there are Malware Rules that can add to the Policies. Rules can be used like Access Control Lists (ACLs) and determine who is affected by a particular Malware Policy by blocking or allowing particular accounts or groups.
Get-Help New-MalwareFilterRule -Examples
Example
In the previous example we configured notifications for emails that were detected as malware. The notifications were configured for any internal or external message and there were no restrictions placed on which mailboxes this would apply to and thus all mailboxes are affected. What if we wanted to restrict this policy to the IT department only, possibly for testing before putting the Malware Policy into production. If we review the full Get-Help for the New-MalwareFileRule we see one option that we can use:
-SentToMemberOf
-MalwareFilterPolicy
This enabled us to create the rule, assign it to the policy and then apply it only to the IT Admins group (with the provided SMTP address):
New-MalwareFilterRule -Name "IT Admin Testing Rule" -SentToMemberOf [email protected] -MalwareFilterPolicy Default
** Note ** You cannot apply a Malware Filter Rule to the Default Malware Filter Policy.
Connection Filters
Connection Filters are used to specifically block or allow certain email server IPs from connecting to your Office 365 tenant. These types of filters are good for either allowing a trusted source, like a partner organization, to connect or to block a server that is either currently sending Spam to your tenant or has done so in the past. Microsoft already has extensive lists for blocked IPs due to its own internal parameters. You are more likely to use an allow IP connections than block when using EOP.
PowerShell
In order to configure these settings, we first need to find the cmdlets needed in PowerShell that will allow us to do so. We'll use the noun phrase 'ConnectionFilter' to find the relevant cmdlets:
Get-Command *ConnectionFilter*
First, if we run the Get-HostedConnectionFilterPolicy we see that the default policy is not configured with any settings:
Now let's review some examples for configuring this filter:
Get-Help Set-HostedConnectionFilterPolicy -Examples
Example
Engineers on the Messaging Team have been tracking the IP connections made by SMTP servers and were able to connect Spam and Malware attacks by these bad IPs. On the reverse side the Messaging Team also has a list of known good SMTP servers from clients, partners and other sources. They are now in the process of preparing EOP as their new protection service before they move mailboxes to their new Exchange Online tenant.
In order to configure the IP Allow and IP Block lists, we need to run the Set-HostedConnectionFilterPolicy cmdlet in order to do so. Here is a sample of what they would need to configure:
Set-HostedConnectionFilterPolicy Default -IPAllowList 64.34.23.43,23.100.100.1 -IPBlockList 64.34.23.44,23.100.100.2
We can verify the settings have been applied:
Get-HostedConnectionFilterPolicy Default
After applying these settings, one of the engineers realized they had their lists mixed, how can they reverse the settings? First we'll wipe out all settings to ensure no duplicates or odd values are retained:
Set-HostedConnectionFilterPolicy Default -IPAllowList $Null -IPBlockList $Null
Get-HostedConnectionFilterPolicy Default
Set-HostedConnectionFilterPolicy Default -IPBlockList 64.34.23.43,23.100.100.1 -IPAllowList 64.34.23.44,23.100.100.2
Get-HostedConnectionFilterPolicy Default
Spam Filter
The Spam Filters in Exchange Online are quite varied and can be a bit confusing. Trying to find PowerShell cmdlets for configuring these settings can be confusing as well. That is because there is no cmdlet that is listed as a Spam Filter cmdlet. How do we find the cmdlet for it? We use the 'Show Command Logging' feature that we covered in Appendix B. By using that and changing one setting in the Spam Filter we see that changing the Spam Filter requires the 'Set-HostedContentFilterPolicy' cmdlet. Let's see what other cmdlets we have that share the same noun phrase:
Get-Command *HostedContentFilter*
Looks like we have a lot of configuration cmdlets to choose from to make adjustments to the Spam Filter. Similar to the Malware Policies and Rules we covered earlier in the chapter, the Spam Filter has Rules and Policies as well. So we can configure more Rules and Policies depending on our need. Let's start out with the default Spam Filter Policy to see what is configured and what we can configure with PowerShell.
Get-HostedContentFilterPolicy
So we have one Spam Policy that we can configure called 'Default'. Let's review this in more detail:
Get-HostedContentFilterPolicy | Fl
As we can see from the screenshot above of a brand new tenant, there are a lot of settings that are off and not set. These are off for a reason as turning them on could potentially block legitimate emails if you do not understand what the settings do. However, there is a provided mechanism for testing settings as some of the parameters have possible values of On, Off and Test. This last one is important if there is some uncertainty as to what the setting will do in production. Microsoft provides a good description of these options and their effects on filtering here:
https://technet.microsoft.com/en-us/library/jj200684(v=exchg.150).aspx
** Note ** There are a couple of these settings in the Spam Filter that show 'MoveToJmf':
The 'MoveToJmf' setting is just an abbreviated 'Move To Junk Mail Filter'; though it isn't clear why this had to be abbreviated for this property.
Example
Let's say we want to configure our Spam Filter to test a few parameters. To help analyze the impact of the change, we need to set the 'TestModeAction' parameter to either 'AddXHeader' or 'BccMessage Redirect'. This will allow us to either tag the message with a X-Header we can track or to have a copy of the message sent to a certain address for analysis. For this example we will use an X-Header and change the MarkAsSpamFormTagsInHtml, MarkAsSpamFramesInHtml and MarkAsSpamEmbedTagsInHtml parameters all to 'Test'.
Set-HostedContentFilterPolicy Default -MarkAsSpamFormTagsInHtml Test -MarkAsSpamFramesInHtml Test -MarkAsSpamEmbedTagsInHtml Test -TestModeAction BccMessage -TestModeBccToRecipients [email protected]
Now if a message matches any of these settings, a copy will be BCC'd to the email address specified in the 'TestModeBccToRecipients' parameter in our cmdlet.
Outbound Spam
Exchange Online Protection has an interesting feature that looks for Outbound Spam for your Exchange Online tenant. While the feature is useful, there isn't a lot we can configure. We can notify some admins of the emails that are outbound Spam or we can add some BCC recipients to the message. There isn't much else to this particular feature.
PowerShell
There aren't a lot of configuration settings and thus not a lot of PowerShell cmdlets available to configure it. Let's take a look at what we can do:
Get-Command *HostedOutbound*
So, we can Get and we can Set out Outbound Spam settings. First we can check to see what is set by default on the Outbound Spam configuration:
Get-HostedOutboundSpamFilterPolicy | Fl
Now that we see what our defaults are, let's look to configure this feature with the Set cmdlet that is available to us:
Get-Help Set-HostedOutboundSpamFilterPolicy -Examples
Sample Scenario
Take for example an organization that is worried about Spam being sent outbound from their organization and would like have the administrators of Exchange Online notified if outbound Spam does get sent. For us to do so, we need to configure two parameters:
- NotifyOutboundSpam - This is by default set to 'False', so no notifications are sent
- NotifyOutboundSpamRecipients - This property is blank because the first one is set to False
We just need a recipient for notifications and then we can configure the Outbound Spam settings:
Set-HostedOutboundSpamFilterPolicy Default -NotifyOutboundSpam $True -NotifyOutboundSpamRecipients '[email protected]'
We can run the 'Get-HostedOutboundSpamFilterPolicy | Fl' one-liner to verify our configuration worked:
Using Transport Rules for Spam Protection
In addition to using EOP and other features in Exchange Online, a more rudimentary method still exists for blocking unwanted emails - Transport Rules. While this may seem like an inelegant solution, using transport rules to control SPAM is used by many corporations today. These Transport Rules could be simple or complex, depending on the desired results. As a starting point we can use an article written by Microsoft on the subject:
https://technet.microsoft.com/en-us/library/dn720438(v=exchg.150).aspx
The above article provides us with some examples of what can be done, however these are done in the EAC and not in PowerShell. Referring back to Chapter 10's section on Transport Rules, we can construct some rules to control SPAM using techniques like RegEx.
Data Loss Prevention (DLP) is a growing feature request among many types of organizations. The draw for these companies is that the DLP provides another line of defense for loss of corporate sensitive data. Key among features built into Exchange Server’s DLP are the predefined sensitive data types provided by Microsoft and that DLP can be customized for an environment with templates and policy tips. For the end user, DLP is invisible for some scenarios, for example when administrators are testing rules, when a DLP policy stops a message from either reaching the end user or exiting Exchange DLP is only visible when a Policy Tip is configured to make the end user aware of the information that was being sent out.
** Note ** DLP requires at least an E3 license in order to use in Exchange Online. A bigger note is that DLP may eventually be pulled from Exchange Online and you will only be able to configure this in the Security and Compliance Center.
- 40 Sensitive Data Types
- Policy Tips – for OWA and Outlook
- Document Fingerprinting
- Coordinates with Transport Rules
- Customization – Templates
- ‘Test Mode’ – without affecting users
First, we’ll start with the cmdlets that are available for DLP:
Get-Command *DLP*
Exchange Online has no DLP policies defined by default. This can be verified with 'Get-DLPPolicy' on a brand new Exchange Online tenant.
DLP Templates are one of the building blocks for DLP in Exchange Online. To begin with the process, first use a Template that is custom created or a Microsoft Template. A DLP Policy is built based on that Template and then the DLP Policy is used in a Transport Rule.
With Exchange Online, Microsoft has included a few DLP Templates to speed up deployment of DLP:
Get-DlpPolicyTemplate | Ft –Auto
Creating Custom DLP Templates can be done with PowerShell or with an XML editor as there is no option to do so in the EAC. Whichever way the template is created it can be imported into Office 365 with PowerShell. The surprise here for anyone working with this on-premises is that in Office 365, this functionality has been removed from Exchange Online and is now only in the Security and Compliance Center.
Times have changed. The XML file is no longer something we can import into Exchange Online. With Microsoft’s emphasis on the Security and Compliance Center and the de-emphasis of the crossover features in Exchange Online, this would seem to be a natural progression. If we attempt to connect to Exchange Online and import the new data type with the New-ClassificationRuleCollection, we see that this function has been neutered and unusable:
So what to do? We need to connect PowerShell to the Security and Compliance Center. We need to run these three lines in PowerShell:
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session
Once connected to the Security and Compliance Center we can now check out how to do the same tasks we used to do in Exchange Online. First we can use the information from the error message to find the new cmdlets:
Get-Command *DlpSensitiveInformationType*
So, now that we have the correct cmdlets, how do we add the data type in the new Security and Compliance Center?
Get-Help New-DlpSensitiveInformationTypeRulePackage -Examples
From the above example, we see that an XML file is needed in order to create/import a DLP Template into Exchange. Creating an XML file takes a bit of time and is somewhat complicated. These XML files can be created with a PowerShell script that has a series of questions. This script was written by one of the authors of the book and can be found here:
https://justaucguy.wordpress.com/2015/01/27/dlp-custom-xml-generation-script/
In practical terms, creating a one-off XML file is easier if you can use the Microsoft help and TechNet pages that are provided. Skipping forward, assuming an XML file has been created (BigBox-PII.XML) we can import the template using the example above for guidance.
$Directory = "C:XmlScriptConfidentialInformation.xml"
New-DlpSensitiveInformationTypeRulePackage -FileData ([Byte[]]$(Get-Content -Path $Directory -Encoding Byte -ReadCount 0))
Once the template is created, we can proceed to the creating of a DLP Policy based off of this template. There is no real limit to the number of templates that can be created. The advantage of a custom XML for a custom template is that a RegEx query can be used to query for custom criteria – bank account numbers, custom card numbers, etc. The process for DLP rules is the same from here on whether the XML file is a custom or predefined template.
DLP policies are built off of either the built-in templates provided by Microsoft (see above) or custom templates like the one created in the example on this page. Transport Rules use DLP policies as matching criteria for SMTP messages traversing through Exchange Online. Pre-canned templates exist for more common data types (financial data for Canada, UK or the US).
Creating a new DLP Policy with PowerShell requires the ‘New-DLPPolicy’ cmdlet. Here is an example of the cmdlet:
Get-Help New-DlpPolicy –Examples
Other options that are available for configuring a new DLP Policy that should be considered are:
- Mode <Audit | AuditAndNotify | Enforce> - How the policy notifies the end users
- State <Enabled | Disabled> - Policies are enabled by default
Sample Policy creations of these two new DLP Policies will be based off of an existing Microsoft templates (“Japan Financial Data”) and a template we created in the previous section (“Big Box PII”):
New-DlpPolicy -Name "Big Box Personal Info" -Template "Big Box PII"
New-DlpPolicy -Name "Japanese Subsidiary Finance Data" -Template "Japan Financial Data"
The Japanese DLP Policy did generate a notification when it was created:
Once created, verifying the policies is the next step:
Get-DlpPolicy | ft -Auto
Now there are two DLP policies that can be called by Transport Rules to affect messages that meet the policy’s criteria.
Policy Tips are like any other Exchange Tips (MailTips is one example) that provide a visual indicator of a problem or something that the end user (the message sender) should be aware of. DLP Policy Tips will work in either Outlook or OWA. For Outlook, make sure that the latest version of Outlook 2013 or 2016 are used in order to get the most out of the tips. Outlook can cache DLP information and any changes that are made may show up immediately. Previous versions of Outlook do not work with Policy Tips, nor a standalone installation of Outlook.
** Note ** Policy tips do not work if the full Office Suite is also not installed. Standalone Outlook will not work with Policy Tips - https://support.microsoft.com/en-us/kb/2823263.
With regards to PowerShell and Policy Tips, the wording of the tip can be customized and the tip can be turned on or off depending on the scenario. For example, a DLP Policy, tied to a Transport Rule that looks for sensitive data, can be flagged for ‘Testing with no Policy Tips’. To configure the rule, we need to look at options for this rule (‘mode’ parameter):
Get-Help Set-TransportRule –Full
Using the switch ‘-Mode Audit’ and no Policy Tips would be visible to the end user. For either ‘-Mode AuditAndNotify’ or ‘-Mode Enforce’, policy tips would be visible in the mail client if a message matches the rule (and the associated DLP Policy). Policy Tips can also be customized. If, instead of the pre-canned tips, there is a need for a custom message for end users, these can be done with PowerShell. First, what cmdlets are available:
Get-Command *PolicyTip*
First, we start with what is already configured for Policy Tips:
Get-PolicyTipConfig
As expected, no results are to be found. We will need to create our own set of Policy Tips to notify end users with these custom messages.
Get-Help New-PolicyTipConfig –Examples
The most important parameter is ‘-Value’ as it determines what the end message will be provided to the end user. Notice that the second example provides a URL for the end user. This might be more appropriate if there is a fully fleshed out policy for these restricted attachments or PII. When creating a new Policy Tip, the name of the tip needs to reference two criteria: the locale and the action to be performed. A working example for the English language would be:
-Name “enNotifyOnly”
If for example the wrong name is chosen, then a lot of errors are generated:
A complete cmdlet would look like this:
New-PolicyTipConfig -Name enNotifyOnly -Value ‘This message contains private information that should not be shared outside of this company.’
To verify the cmdlet worked:
Get-PolicyTipConfig | ft –Auto
Other possible actions are RejectOverride and Reject. Reject will block the message completely whereas RejectOverride allows for an override if the user puts “Override” in the subject line of the message.
New-PolicyTipConfig -Name enRejectOverride -Value ‘This message contains private information that should not be shared outside of this company.’
DLP’s Document Fingerprinting feature allows for DLP to search for very specific content that is sent through e-mail, in this case a matching attachment. The fingerprint is basically a hash of the properties of the document in question. The document itself is not stored in Exchange. Outlook will also evaluate a document locally and the document is not sent over the wire between Exchange and Outlook. The process is similar to creating a template, with the source being a document to import. Then build Transport Rules around the document to restrict, allow or log when a rule processes the e-mail. Below is a scenario which will provide a better idea as to what can be done with this, and what PowerShell can provide.
Scenario
HR has some confidential forms that are to be used internally by the company. They’ve provided IT with three forms that need to prevent from being emailed to anyone external to the organization. First, place a copy of the document on the Exchange server so that it can be imported for creating the DLP Policy. Any form or document to be ‘fingerprinted' should be blank so that no information interferes with the evaluation.
For PowerShell cmdlets, start with Get-Content (used to store the file in a variable) and then use New-FingerPrint to create the fingerprint based off the content from the Get-Content variable. Follow this by creating a new Data Classification to be used by Transport Rules later.
There are three forms to be protected:
- EmployeePII-Form.docx
- Employee-Review-2016.docx
- Termination-RequestForm.docx
Next, store the document content in a variable in preparation for Transport Rules to use the content. Let’s walk through the process of taking these documents and creating Transport Rules to handle them:
Import each individual document into a separate variable to be used by New-Fingerprint:
$HRDoc1 = Get-Content "C:DocumentsHREmployeePII-Form.docx" -Encoding Byte
$HRDoc2 = Get-Content "C:DocumentsHREmployee-Review-2016.docx" -Encoding Byte
$HRDoc3 = Get-Content "C:DocumentsHRTermination-RequestForm.docx" -Encoding Byte
Notice that the documents are encoded as a ‘byte’ type document. According to the help file on the ‘Get-Help’ cmdlet, there are a few data types that can be used:
ASCII, BigEndianUnicode, Byte, String, Unicode, UTF7, UTF8 and Unknown.
In choosing a Word document (which is a binary file) we need to choose ‘byte’ for the encoding to properly ingest the hash from the file. The ‘Get-Content’ cmdlet does have other parameters, but for the purposes of fingerprinting itself, no others are required. Simply put in a location of the file and what encoding to use for the document for fingerprinting and store that in a variable.
Create a fingerprint based off the document stored in each variable:
$HRDoc1_Fingerprint = New-Fingerprint -FileData $HRDoc1 -Description "Employee PII Form"
$HRDoc2_Fingerprint = New-Fingerprint -FileData $HRDoc2 -Description "Employee Review 2016"
$HRDoc3_Fingerprint = New-Fingerprint -FileData $HRDoc3 -Description "Termination Request Form"
** No cmdlet can query Fingerprints that were created, to see the fingerprints raw data, you can simply ‘dump’ the variable contents to the PowerShell window:
$HRDoc1_Fingerprint | fl
The New-Fingerprint cmdlet has even less options than the Get-Content cmdlet and examples from the cmdlet use only the two parameters chosen above – FileData and Description. FileData references the document stored in the variable.
Now that the Fingerprint has been created, it can be used by the New-DataClassification cmdlet to create a data classification for a Transport Rule:
New-DataClassification -Name "HR Confidential Form 1" -Fingerprints $HRDoc1_Fingerprint -Description "Message contains confidential employee information."
New-DataClassification -Name "HR Confidential Form 2" -Fingerprints $HRDoc2_Fingerprint -Description "Message contains confidential employee information."
New-DataClassification -Name "HR Confidential Form 3" -Fingerprints $HRDoc3_Fingerprint -Description "Message contains confidential employee information."
The New-DataClassification cmdlet can be used to create individual classifications or it can group multiple Fingerprints together into one classification as the parameter used for this is ‘Fingerprints’ not ‘Fingerprint’. Make sure to separate multiple Fingerprints with a comma.
** Note ** Document Fingerprints can also be added to existing data classifications using the Set-DataClassification cmdlet and the –Fingerprints parameter:
Set-DataClassification -Name "HR Confidential Form 3" -FingerPrints $HRDoc3_Fingerprint
To verify the Fingerprints were successful in being converted to an Exchange Data Classifications, run the following:
Get-DataClassification
Notice the header fields of Invariant Name, Localized Name, Publisher and Classification Type. The other Data Classification entries show the Publisher to be Microsoft and the Classification Type to be Entity. Can we change ours to something more meaningful? First, what other cmdlets are available for Data Classifications:
Get-Command *DataClass*
Upon reviewing the parameters for these cmdlets reveals that this cannot be changed. The Classification type is set once a Fingerprint is used. The publisher simply matches the name of the server it was created on.
Continuing on the Fingerprints are created and stored as new Data Classifications. This Data Classification can be used by a Transport Rule to block these emails (and their attachments) from leaving Exchange.
New-TransportRule -Name ‘Notify :External Recipient BigBox confidential’ -RejectMessageReasonText 'This file is restricted and may not be emailed outside the company.' -NotifySender $Null -Mode Enforce -SentToScope NotInOrganization -MessageContainsDataClassification @{Name=’ HR Confidential Form 1’}
New-TransportRule -Name ‘Notify :External Recipient BigBox confidential #2’ -RejectMessageReasonText 'This file is restricted and may not be emailed outside the company.' -NotifySender $Null -Mode Enforce -SentToScope NotInOrganization -MessageContainsDataClassification @{Name=’ HR Confidential Form 2’}
New-TransportRule -Name ‘Notify :External Recipient BigBox confidential #3’ -RejectMessageReasonText 'This file is restricted and may not be emailed outside the company.' -NotifySender $Null -Mode Enforce -SentToScope NotInOrganization -MessageContainsDataClassification @{Name=’ HR Confidential Form 3’}
Verify Transport Rules were created:
Get-TransportRule
How does this work in practice? First, a message created in OWA is created with one of the three HR documents attached and addresses to an external recipient:
Notice the Policy Tip at the top of the email as well as the fact that the document itself has a red exclamation point to indicate that it has been recognized by its content. If a user is unsure why this is occurring, there is a ‘Learn More’ button at the top which provides this tidbit (as well as an option for feedback). The option shown is based on which Action was chosen in the Policy Tip.
After the message is sent, an NDR is generated:
Going back to PowerShell, how can these DLP flagged messages be tracked? There are three cmdlets that may be of use to us:
Get-DlpDetailReport
Get-DlpDetectionsReport
Get-DlpIncidentDetailReport
What other ways can the Document Fingerprinting feature be used? Maybe in a set of documents that should never leave HR or be sent in email or some intellectual property documents (patent forms) that should never leave R&D or never even be sent through email. These scenarios can also be controlled via the Document Fingerprinting feature. Each scenario should be created with its own unique fingerprint, data classification and Transport Rules to keep track of each particular scenario in a company. This will make troubleshooting much easier if issues or discrepancies occur (document is updated or message is or is not delivered).
Journaling is the process of making a copy of an email and storing it in a location routed via an email address. A message can be journaled to a local database or an external service. Either method is supported using the Journaling Rule cmdlets below. Messages can be journaled for compliance or for business continuity. Business continuity is one of the features external services tote as a reason to use their product.
** Note ** Journaling in Office 365 must use an external recipient.
For journaling, a small subset of cmdlets is available for managing Journal Rules in Exchange Server 2016:
Get-Command *journ*
By default, there are no Journal rules configured by default which can be confirmed by running ‘Get-JournalRule’ in a new Exchange Server environment.
** Note ** Before a Journal Rule is creates, we also need to configure where Non-Delivery Reports (NDR) go for Journal reports that cannot be delivered to their destination. This setting can be configured with the 'Set-TransportConfig' cmdlet like so:
Set-TransportConfig -JournalingReportNdrTo '[email protected]'
Now we can begin exploring PowerShell Journaling, create some Journaling rules using the ‘New-JournalRule’ cmdlet. See below for an example:
New-JournalRule
Commonly Used Options
JournalEmailAddress - The recipient address of the journaled message (external only)
Name - Name of the new Journal Rule
Enabled <$True | $False> - Whether the rule is enabled or not
Recipient <SmtpAddress>
Scope <Internal | External | Global>
- Global - Global rules process all email messages that pass through a Transport service.
- This includes email messages that were already processed by the external and internal rules.
- Internal - Internal rules process email messages sent to and received by recipients in your organization.
- External - External rules process email messages sent to recipients or from senders outside your organization.
Sample One-Liner
New-JournalRule -Name "CFO Journaling" -JournalEmailAddress "[email protected]" -Recipient [email protected] -Enabled $True
Example Usage
As the email administrator of the legal department determined that with a new implementation of Exchange Online, all messages need to be journaled. The reason for the Journaling is to comply with the current government regulations for email retention.
New-JournalRule -Name "All Messages" -JournalEmailAddress "[email protected]"-Scope Global -Enabled $True
Script Scenario
You work for a company with 12,000 users. There are offices all over the world with major concentrations of users in the US and Europe. There are different compliance requirements for the different regions.
All the users from Europe need to be journaled for new compliance regulations, separate from current archiving and business continuity of the US branch. The users are in three different countries and the legal department wants each group to be journaled to a country specific journaling provider - one for each country. Your IT manager wants separate rules and a way to track the configuration. HR provides a complete list of users to help verify that the correct employees are being journaled.
Here are the steps that need to be taken in order to make this possible:
- Configure a recipient to receive NDRs that could potentially be generated if the journaled message is not delivered
- Identify users with the correct CustomAttribute1 value based on their country
- Create a Journal rule for the particular country and use the group created in the previous step
The creation of the group is critical because the rules use that as a basic for determining which users to journal where.
CSV File Format
Mailbox,CustomAttribute
Damian,1
DStork,2
TestUser01,3
TUser02,1
Script
First we need to create some Dynamic Distribution Groups so that we can apply the Journal Rules for everyone in that group:
# Create Dynamic list of users and a Journal Rule that uses that group
New-DynamicDistributionGroup -Name GermanyJournaling -RecipientFilter {(CustomAttribute1 -eq "1")}
$Smtp = ((Get-DynamicDistributionGroup GermanyJournaling).PrimarySmtpAddress).Address
New-JournalRule -Name "Journaling for Germany mailboxes" -JournalEmailAddress "Journaling-Germany" -Scope Global -Recipient $Smtp -Enabled $True
# Create Dynamic list of users and a Journal Rule that uses that group
New-DynamicDistributionGroup -Name ItalyJournaling -RecipientFilter {(CustomAttribute1 -eq "2")}
$Smtp = ((Get-DynamicDistributionGroup ItalyJournaling).PrimarySmtpAddress).Address
New-JournalRule -Name "Journaling for Italy mailboxes" -JournalEmailAddress "Journaling-Italy" -Scope Global -Recipient $Smtp -Enabled $True
# Create Dynamic list of users and a Journal Rule that uses that group
New-DynamicDistributionGroup -Name PolandJournaling -RecipientFilter {(CustomAttribute1 -eq "3")}
$Smtp = ((Get-DynamicDistributionGroup PolandJournaling).PrimarySmtpAddress).Address
New-JournalRule -Name "Journaling for Poland mailboxes" -JournalEmailAddress "Journaling-Poland" -Scope Global -Recipient $smtp -Enabled $True
Sample Output
With the above setup, any email that goes to a user who is in the Dynamic Distribution List for a particular country will have their messages journaled to a external journaling provider for their locality.
Now that the Journaling is in place, how can we verify that Journaling is working as expected? There are a few places where we can verify the proper operation of the Journaling setup can be verified – contents of the Journaling mailbox (check with the external hosting service), Message Trace or Mailbox Statistics:
Message Trace
Following in the footsteps of Chapter 10, a review of message traces can provide information on how many messages are getting delivered to a Journaling mailbox like so:
Get-Messagetrace -StartDate 3/1/18 -EndDate 3/9/18 | where {$_.SenderAddress -like 'MicrosoftExchange*'} | ft Received,SenderAddress,Subject,Status
** Note ** Like a lot of queries in Exchange, using the correct date format is important. The date is in the US format of MM/DD/YY. If another format is used like YY/MM/DD, an error message will be generated:
A successful search will generate these results:
Knowing what rules are in place can be important if there is a need to troubleshoot a Journaling process, especially if there is an external product or process that is analyzing these messages. Understanding what destination email address is being used to journal for what recipient(s). ‘Get-JournalRule’ is the cmdlet to provide the needed information:
Get-JournalRule | ft Name, JournalEmailAddress, Scope, Enabled –Auto
Why disable a Journaling Rule? Normally the disabling of Journaling Rules is done when the original need has past or a new rule needs to be created or if a different destination server or to who to journal. The Disable-Journal cmdlet is the cmdlet for the job. First we need to use the Get-JournalRule on the rule to be disabled and then pipe ‘|’ that journal rule to the ‘Disable-JournalRule’ cmdlet:
Get-JournalRule "Journaling for Germany mailboxes" | Disable-JournalRule
After disabling the rule, verify that the rule is disabled:
Get-JournalRule
Enabled is now set to ‘False’.
If the rule needs to be re-enabled, simply use the same process as the Disable-JournalRule:
Get-JournalRule "Journaling for Germany mailboxes" | Enable-JournalRule
This cmdlet does not provide any feedback, only by running Get-JournalRule will you be able to verify if the rule is enabled again.
Removing a rule is similar to disabling the Journaling Rule – use the Get-JournalRule and pass that information along to the Remove-JournalRule:
Get-JournalRule "Journaling for Germany mailboxes" | Remove-JournalRule
Rights Management in Exchange 2016 relies on Active Directory Right Management Services (ADRMS) as an additional security feature that can be added. Exchange refers to RMS as Information Rights Services or IRM.
Rights Management for Exchange Online is now known as Azure Information Protection (AIP). For the customer, Exchange Online and AIP do not require any physical servers, just licensing is needed to activate scenarios. In this scenario we need to turn on a few items, configure some settings and then we'll be able to start working with the Rights Management service and protect emails that pass through Exchange Online.
Rights Management - this is the general concept of protecting messages sent from Exchange (online or on-premises) to external or internal recipients and controlling what actions can be performed on the messages. These actions could include encrypting the messages, prevent the message from being forwarded or
Azure Information Protection (AIP) - AIP is the Office 365 iteration of Rights Management and it can be applied to Exchange Online messaging. In addition, we can also configure AIP to apply templates and rules against other workloads in Office 365.
As we review AIP and Exchange Online, you will see references to older terminology like IRM for PowerShell cmdlets. Just remember that the end goal is to protect emails within Exchange Online.
First, we need to enable the Rights Management feature in our tenant. This feature is off by default and enabling it will open up a couple of features being discussed in this chapter - Azure Information Protection and Office 365 Message Encryption.
In order to enable this feature we need to perform a few steps:
(1) Enable Rights Management
Once we pull up Azure Information Protection, we get a small window to the right:
This link will then take us to your Azure Portal and specifically to the Rights Management controls:
For Information Protection we should also log into our Windows Azure portal to enable the Azure Information Protection feature. Once we have our tenant prepared we can dive into the PowerShell side of AIP.
First, in Exchange Online, we have some cmdlets that we can use to verify the Rights Management configuration. We'll start with cmdlets with 'IRM' in them, these three letters stand for Information Rights Management. As we'll see below, there are only three cmdlets that deal with this feature.
Get-Command *irm*
From the above, we will explore the current IRM configuration in Exchange Online:
Get-IRMConfiguration
Notice that by default that IRM is enabled for client access on the Exchange server. However notice that only External Licensing is enabled and that the IRM configuration is not published. Below is a list of parameters that can be configured for IRM:
Get-Help Set-IRMConfiguration -Full
Parameters
ClientAccessServerEnabled <$true | $false> - this option turns on IRM for OWA and ActiveSync
Confirm [<SwitchParameter>]
DomainController <Fqdn>
EDiscoverySuperUserEnabled <$true | $false> -
ExternalLicensingEnabled <$true | $false> - enable or disable IRM for messages sent to external recipients
Force <SwitchParameter>
InternalLicensingEnabled <$true | $false> -
JournalReportDecryptionEnabled <$true | $false>
LicensingLocation <MultiValuedProperty>
PublishingLocation <Uri>
RefreshServerCertificates <SwitchParameter>
RMSOnlineKeySharingLocation <Uri>
SearchEnabled <$true | $false>
TransportDecryptionSetting <Disabled | Optional | Mandatory>
When further customizing the IRM configuration, the following setting should also be considered:
eDiscoverySuperUserEnabled – If this is set to true, users with eDiscovery privileges can access IRM protected emails.
SearchEnabled – On by default, it enables OWA to search for IRM messages.
InternalLicensingEnabled – Allows for the use of RMS on internal emails.
JournalReportDecryptionEnabled – If journaling is present in Exchange, any IRM messages that are journaled have an unencrypted copy stored with the Journal message.
For a scenario where internal messages should be protected by IRM and legal needs to perform legal discovery on emails that are IRM protected, the IRM configuration should be updated like so:
Set-IRMConfiguration –eDiscoverySuperUserEnabled $True –InternalLicensingEnabled $True
Once configured, RMS is ready to use internally and templates and configuration within RMS should be configured. Both internal and external licensing can be enabled in the same configuration if need be.
Set-IRMConfiguration -InternalLicensingEnabled $True -ExternalLicensingEnabled $False
In addition to configuring the IRM settings, the same settings can be tested / verified using the Test-IRMConfiguration cmdlet. To test the configuration for external recipients, the following syntax can be used:
Test-IRMConfiguration -Recipient [email protected] -Sender [email protected]
The test will go through a series of steps:
And a final result at the end:
In order to apply an Information Protection template to an email, we need to create one. These can only be created in the Security and Compliance Center and published for use by Exchange in this console. This is outside our scope, however you can find more about these AIP templates here:
https://docs.microsoft.com/en-us/information-protection/deploy-use/configure-policy-templates
PowerShell
To now apply the AIP Template to an email. This requires a new Transport Rule which will specify the criteria needed to trigger it, like any other Transport Rule, and then an AIP Template is set to apply to these messages.
Get-Help New-TransportRule -Full
From here we can see there is an option called 'ApplyRightsProtectionTemplate' which will be useful for applying an AIP template. We also have conditions like 'SentToScope', 'SubjectMatchPatterns' and From. In our sample, we can apply an 'AIP Template' called 'Highly Confidential All Employees'. We will also pick a from address as well as a sent to an external email address and we get this:
New-TransportRule -From @([Microsoft.Exchange.Management.ControlPanel.PeopleIdentity]) -SentToScope 'NotInOrganization' -SubjectMatchesPatterns @('"Highly Confidential"') -ApplyRightsProtectionTemplate 'Highly Confidential All Employees' -Name 'Highly Confidential - AIP' -StopRuleProcessing:$False -Mode 'Enforce' -Comments ' ' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header'
So in order to apply AIP to messages, create an AIP Template we need an AIP Template and a corresponding Transport Rule to protect messages.
Transport Rules can be created to utilize RMS to protected messages in Exchange Online. However, Outlook Protection Rules will protect messages at the Outlook level even before the email has left the Outlook client. These rules are created in Exchange Online and downloaded to the Outlook client via Exchange Web Services (EWS). This means that when an email is sent via Outlook and an Outlook Protection Rule has been applied, the message is already protected before it enters the Transport pipeline and on to its destination. The end-user will also know this has occurred whereas a Transport Rule would be invisible to the end user as it's applied in flight instead of in the client.
PowerShell
Let's review the PowerShell cmdlets for Outlook Protection Rules:
Get-Command *OutlookProt*
Like many other protections in Exchange, there are no Outlook Rules by default which can be verified with the Get-OutlookProtectionRule cmdlet. In order to get started let’s review the New-OutlookProtectionRule examples:
Get-Help New-OutlookProtectionRule –Examples
Other parameters to consider when working with Outlook Protection Rules are –ApplyRightsProtectionTemplate, SentTo, SentToScope, UserCanOverride and Enabled. A sample command would look like this:
New-OutlookProtectionRule -Name "R and D" -SentTo [email protected] -ApplyRightsProtectionTemplate "Big Box – Outlook Rule 1” -UserCanOverride $False
Mobile protection via IRM is enabled when the ‘ClientAccessServerEnabled’ setting is configured for $True:
Set-IRMConfiguration –ClientAccessServerEnabled $True
Now ActiveSync devices can be protected as well. Microsoft also recommends that certain settings for the Microsoft ActiveSync policy should also be configured:
DevicePasswordEnabled - $True
RequireDeviceEncryption - $True
AllowNonProvisionableDevices - $False
Depending on the name of the ActiveSync policy being applied to your mobile devices, the one-liners to make these changes might be a bit different. In the case below, we will modify the default policy to these settings:
Get-MobileDeviceMailboxPolicy | Where {$_.IsDefault -eq "True"} | Set-MobileDeviceMailboxPolicy -PasswordEnabled $True -RequireDeviceEncryption $True -AllowNonProvisionableDevices $False
If IRM is not enabled on the mobile device policy, that should be enabled as well:
Get-MobileDeviceMailboxPolicy | Where {$_.IsDefault -eq "True"} | Set-MobileDeviceMailboxPolicy –IRMEnabled $True
Mobile devices users can now perform the following actions:
Same Message Tracking applies to mobile devices as would have been present with OWA and Outlook client emails.
Office 365 Message Encryption (OME)
Another useful feature that is built into Exchange Online is the encryption feature. This feature allows us to configure the secure sending of emails to external recipients without the worry or risk of its interception and deciphering its contents. How is that possible? It's because the message never truly leaves Exchange Online. All that is sent is a link to the email for the intended recipient to validate and then access.
As with all thing Microsoft and especially Exchange Online, the OME process now contains a potential enhancement in the form of AIP. The new experience changes the experience for those using and receiving encrypted messages. Some considerations for this new method:
Licensing considerations
The original OME is included in E3 licenses and can also be purchased separately for tenants that do not use E3. AIP is also included in subscriptions with E3 making the usage of it an easy move for those using OME now. If, however, you do not have an E3 subscription, AIP can be purchased as a separate line item and there are additional license levels if a company needs the more advance functionality it provides:
https://azure.microsoft.com/en-us/pricing/details/information-protection/
Microsoft Guidance on OME and AIP:
OME in Motion:
In order to set up Office 365 Message Encryption we need to perform these tasks:
(1) Enable Rights Management (See the previous Azure Information Protection section).
(2) PowerShell Configuration
First step is to set an RMS key location. If you are in North America, we can use the below one-liner:
Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc
If you are in a different part of the world, refer to this chart from Microsoft for your ' RMSOnlineKeySharingLocation' value:
|
Location |
RMS key sharing location |
|
North America |
https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc |
|
European Union |
https://sp-rms.eu.aadrm.com/TenantManagement/ServicePartner.svc |
|
Asia |
https://sp-rms.ap.aadrm.com/TenantManagement/ServicePartner.svc |
|
South America |
https://sp-rms.sa.aadrm.com/TenantManagement/ServicePartner.svc |
|
Office 365 for Government |
https://sp-rms.govus.aadrm.com/TenantManagement/ServicePartner.svc1 |
Next we need to import the configuration from RMS Online:
Import-RMSTrustedPublishingDomain -RMSOnline -Name "RMS Online"
Next we can test to make sure all is set up correctly:
Test-IRMConfiguration –Sender [email protected]
Next we enable licensing for internal usage:
Set-IRMConfiguration -InternalLicensingEnabled $True
Lastly we verify the configuration is in place:
Get-IRMConfiguration
Transport Rules
Microsoft has made many improvements in this area and we will cover the new options available for the end user as well as other configuration options that are available. In the past it used to be required that Exchange Online Transport Rules would need to be created in order to make OME work properly. However we now have a 'Protect' button in Outlook on the Web for Exchange Online and the Outlook client also has the RMS protection plug-in that can also be used to protect the messages. This is what is currently what is available in Outlook on the Web:
PowerShell
In order for Message Encryption to work for all users we'll need to create a pair of Transport Rules. One rule will encrypt the message to external senders while the other will decrypt replies from external sources if the message is encrypted.
Encrypt
New-TransportRule -SentToScope 'NotInOrganization' -SubjectContainsWords @('Encrypt') -ApplyOME:$True -Name 'Message Encryption - Sensitive' -StopRuleProcessing:$false -Mode 'Enforce' -Comments '' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header'
Decrypt
For decryption we simply look for any message from an external sender and remove any encryption that may have been applied.
New-TransportRule -FromScope 'NotInOrganization' -RemoveOME:$true -Name 'Remove Decryption - External Sender' -StopRuleProcessing:$False -Mode 'Enforce' -Comments '' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header'
Branding
The last configuration item we can do for Office 365 Encrypted Messages is to change the branding or look of the messages that are sent.
Get-Command *OMECon*
So we have the usual Get and Set cmdlet pair for the OME configuration. Let's see what the default OME configuration is:
Get-OMEConfiguration
We can see that all of the values we need for branding are currently blank. How do we make them 'un-blank'?
For the logo specified below, make sure you are aware of size limitations:
We can configure a sample OME configuration with this one-liner:
Set-OMEConfiguration -Identity "Big Box OME Configuration" -Image (Get-Content "C:BigBoxLogo.Jpg" -Encoding byte) -Emailtext "Encrypted message from the Big Box Corporation." -PortalText "Big Box Corporation secure email portal." -DisclaimerText "This message is intended only for the recipient. Delete this if it was not addressed to you."
Basically this cmdlet configures a few features for your Message Encryption in Office 365:
- Image - Placed at the bottom of the encrypted email
- Email Text - Part of the message body for the encrypted email
- Portal Text - What the recipient sees
- Disclaimer Text - More information about the encrypted message
One thing to remember about the configuration is that we can configure multiple OME configurations and apply them to different people and thus have different ways of enabling encryption in Exchange Online.
Now if we were to send an email, with the subject line of 'Encrypt', then the message will be encrypted and the recipient of this message will see the following:
The PortalText shows up when trying to open the email and the email portal email looks like:
This we now have a branded experience for our encrypted messaging.