Configuring Office 365 Message Encryption

Configuring Office 365 Message encryption in exchange online helps organization to secure their sensitive information based on transport rules in Exchange online. Before we start configuring Office 365 message encryption, i hope you have a good understanding of what message encryption is and what it can do for you and why we need message encryption. If not, then please read my blog post of Office 365 Encryption Option.

Office 365 Message Encryption is a policy based control of your emails sensitive information and it’s a replacement for Exchange Hosted Encryption Service.

Configuring Office 365 Message Encryption

Before we start configuring Office 365 Message encryption, please make sure you understand the requirements for message encryption as described below.

  • We have Office 365 tenant setup.
  • We’ve the required license. Office 365 Message Encryption requires the purchase of Microsoft Azure Rights Management, which is available for $2.00 per user per month.

Microsoft Azure Rights Management service is already included in E3, E4, A3 and A4 licenses. We’re using E3 license in our lab which qualify us to setup Message encryption in office 365.

  •  We’ve a supported client device. Office 365 encrypted messages can be viewed on any client device that has support to open HTML attachments in a browser that support Form Post.
  • We can encrypt a message of up to 150 megabytes size. For more details about message size limits, see Exchange Online Limits.

To start configuring office 365 message encryption, first step is to activate Azure Rights Management. To activate Azure Rights Management, Navigate to Service Settings –> Rights Management –> Click on Manage

Configuring Office 365 Message Encryption

Configuring Office 365 Message EncryptionEnsure that Rights Management is activated, If not, click on Activate. Once Rights Management is activated. We’re only left with two more steps to configure message encryption. For encryption configuration the administrator must have the required permissions. Administrator must have Compliance Management, Record Management and Organization Management rights in Exchange online. Alternatively, you can download the Azure AD Rights Management Tool from TechNet.

After installing the Azure AD management tool, run the following cmdlet to set the execution policy to RemoteSigned. Default value is Restricted.

  • After setting up execution policy to RemoteSigned, Connect with your exchange online PowerShell.
  • Configure RMS key sharing location in Exchange online. Use the key sharing URL corresponding to your location.
  • Run the following cmdlet to configure the sharing key location. My location is North America and I’ve selected the key for NA.

3

  • Import the Trusted Publisher Domain from RMS Online. To do so, run the cmdlet Import-RMSTrustedPublishingDomain -RMSOnline -Name “RMS Online”.
  • Run “Test-IRMConfiguration -RMSOnline” cmdlet to verify the IRM configuration.
  • Enable IRM for office 365 Message Encryption using Set-IRMConfiguration -InternalLicensingEnabled $true.
  • Once IRM is configured, next step is configure Transport Rules in Exchange Online.
  • Navigate to Exchange Online –> Mail Flow –> Rules. Click on + icon to create a new rule.

12Name your rule and define the encryption parameters as shown below, We’ve configured a rule to encrypt the messages if the sender is within the organization.

34

Once you define the rule, click on Save and you’re done with configuring office 365 message encryption. You can configure a rule based on keywords, recipient, sender and a lot of other options. An encrypted email will be sent as an attachment to the recipient and recipient needs to login using his credentials to read the information within the email. Recipient can login using his Microsoft account or Org. account. I would highly suggest to use this cool feature in office 365 and secure your mail flow. For more information on Office 365 message encryption, please have a look at Office 365 Message Encryption FAQs at TechNet.

Understand and Modify Office 365 users ImmutableID

Understand Office 365 ImmutableID

ImmutableID is a specific attribute for an Office 365 object that is synchronized from on prem Active Directory. When we install AAD Sync with the default settings on “Uniquely Identifying your users”, the Active Directory “objectGUID” is used as ImmutableID. It’s important to consider and understand the importance of ImmutableID when we are planning for office 365 directory integration that involves multiple active directory forest company merger etc.

Modify Office 365 users ImmutableID

Poor planning of ImmutableID can cause significant issues with your deployment and service interruption. AAD Sync Metaverse stored the value of ImmutableID as “SourceAnchor”

It’s important to understand that ImmutableID of Office 365 synced object is not the same as of ObjectGUID. Office 365 uses a special method to convert on prem user ObjectGUID to another string and save the string as ImmutableID. However, ImmutableID is also unique in Office 365 and can be mapped with the corresponding unique ObjectGUID in the local AD.

Modify Office 365 users ImmutableID?

You cannot change the ImmutableID of synchronized object without having a maintenance window or downtime. Modifying the ImmutableID of office 365 object will cause significant impact on your services and requires proper planning. The only way you can modify the ImmutableID is by turning off Directory Synchronization, allowing the users to be converted from Synced AD Object to cloud identities, performing the modification, and then re-enabling directory synchronization.

Microsoft authentication platform for federated user doesn’t support special character “@”in ImmutableID which means you can’t use mail or UPN as ImmutableID in AADSync when using AD FS SSO.

Steps to manually change the ImmutableID for few users are:

  • Create a new OU in local AD and move the user temporarily.
  • Go to MIIS Console –> On Prem AD Connector –> Containers –> filter out this temporarily OU to soft delete synced users.
  • Run the full Sync.
  • Temporarily pause the Sync from Windows Task Scheduler.
  • Go to Office 365 Portal and restore soft deleted users, so the old synced status changes to in cloud status. You can only change the ImmutableID once the user status in Office 365 is “In Cloud”
  • Change the UPN of each user with “Set-MsolUserPrincipalName -UserPrincipalName user@domain.com -NewUserPrincipalName user@tenantname.onmicrosoft.com“.

2

  • After changing the UPN for the user, run the Cmdlet Set-Msoluser -UserPrincipalName user@tenantname.onmicrosoft.com -ImmutableID ObjectGUIDBase64
  • After changing the ImmutableID, change back user’s UPN with “Set-MsolUserPrincipalName -UserPrincipalName user@tenantname.onmicrosoft.com -NewUserPrincipalName user@domain.com“.
  • Test the authentication process.
  • Setup sync mechanism to use ObjectGUID as Source Anchor and perform Full Sync.

If we’ve to change the ImmutableID of all the users then the above mentioned steps will cause a lot of delay and a single typing mistake can cause significant issue with the user account. We’ve created a PowerShell script that requires a CSV file as input which contains the UPN of all the users and this script will change the UPN of all the users to @tenantname.onmicrosoft.com and change the ImmutableID to ObjectGUID. Once the ImmutableID is changed to ObjectGUID, it will change the user UPN back to @domain.com.

#Import Active Directory Module in PowerShell

Import-Module ActiveDirectory
Import-Csv “D:O365.csv” | ForEach-Object {
$upn = $_.”UPN”
$user = $upn.IndexOf(“@”)
$left = $upn.Substring(0,$user)
$upn1 = “$left” + “@tenantname.onmicrosoft.com”
Restore-MsolUser -UserPrincipalName $upn
Set-MsolUserPrincipalName -UserPrincipalName $upn -NewUserPrincipalName $upn1
Set-Msoluser -UserPrincipalName $upn1 -ImmutableID “$Null”
$id=(Get-ADUser -Filter {UserPrincipalName -like $upn } -Properties ObjectGUID | select ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($_.ObjectGUID)).tobytearray())})
Set-MSOLUser –UserPrincipalName $upn1 –ImmutableID $id
Set-MsolUserPrincipalName -UserPrincipalName $upn1 -NewUserPrincipalName $upn
}

You can also download this script from Microsoft TechNet Gallery. More information on ImmutableID can be found on following URLs.

Understanding Shared Mailbox Limitations in Office 365

Shared mailbox in Exchange Online allow a group of users to view and send email from a common mailbox. Understanding shared mailbox limitations in office 365 is important for setting up right expectations for customers. A lot of customers asked questions about utilizing shared mailboxes in office 365. Before we suggest a solution to the customers we should have a strong understanding of shared mailbox limitations in office 365. In this blog post, we will try to build an understanding on shared mailbox limitations to help customers in making a decision when to use a shared mailbox versus user mailbox.

Understanding Shared Mailbox Limitations in Office 365

A shared mailbox in office 365 is:

  • Free and do not require a license, but every user that accesses the Shared Mailbox must be assigned an Office 365 license.
  • Cannot be accessed by users with Exchange Online Kiosk license.
  • Can be used to store emails sent to and received by the Shared Mailbox.
  • Can be used to store data migrated from on-premises Public Folders.
  • Each shared mailbox can be a maximum size of 50GB but shared mailboxes over 50GB in size need to be licensed.
  • A Shared mailbox doesn’t have a username and password and users cannot log into it directly. A user must sign in to his/her own mailbox and then open the shared mailbox using permissions.

Shared mailboxes aren’t primarily associated with individual users and are generally configured to allow access by multiple users e.g. departmental users, Sales team, HR etc.

  • Cannot be used to archive emails from a user.
  • Cannot be used for Journaling.
  • Cannot be accessed using ActiveSync clients.
  • Doesn’t support Unified Messaging feature.
  • Cannot be accessed using Outlook client. To access a shared mailbox on outlook client, you need to first configure a user mailbox that has access to shared mailbox.
  • Active Directory user associated with a shared mailbox is always a disabled user account.

Create a Shared Mailbox in Office 365 using EAC:

To create a shared mailbox in office 365 using EAC, we need to follow the steps mentioned below.

  1. Log on to Office 365 Admin Center using Global Admin credentials.
  2. Go to Exchange Online Admin Center –> Recipients –> Shared and Click on + iconCreate a shared mailbox
  3. Enter Shared Mailbox information. Add users to Shared Mailbox that will have permissions to view and send email from shared mailbox.

Create a Shared Mailbox in Office 365 using Remote PowerShell:

To create a shared mailbox in office 365 using Remote PowerShell, Follow the steps mentioned below.

  1. Connect to Exchange Online PowerShell.
  2. After connecting to Exchange Online PowerShell, Run the cmdlet New-Mailbox -Name “Shared Mailbox Name” -Alias “Shared Mailbox Alias” -SharedPS
  3. Once the mailbox is created, Run the cmdlet to assign appropriate permissions to users. Add-RecipientPermission “MSTechTalk Shared” –Trustee riaz –AccessRights SendAs. This cmdlet will assign “Send As” permissions to user Riaz.

2

You can find more information on Exchange online limitations at TechNet.

Office 365 Shared Mailbox Sent Items Limitation

Office 365 Shared mailbox makes it easy for a specific group of people to monitor and send email from a common email address. When a person in the group replies to a message sent to the shared mailbox, the email appears to be from the shared mailbox not from the individual user. Shared Mailbox sent items limitation that cause compliance / regulatory issues for most of the customers utilizing shared mailbox is fixed now. Microosft has fixed this issue for all the customers and now customer can leverage the use of Shared Mailbox in Office 365 and on prem version of Exchange. Before we look at the resolution let’s have a look at shared mailbox sent items issue.

When a user sends an email using shared mailbox alias, the email goes directly to the sent items of sender instead of shared mailbox sent item. This is something that cause issues for organizations using Shared Mailboxes. To meet the compliance requirements organizations need control over Shared Mailbox sent items and admin don’t have to run Mailbox Audit logging to nail down the sender of email.

Shared mailboxes are a great way to handle customer email queries because several people in your organization can share the responsibility of monitoring the mailbox and responding to queries. Your customer queries get quicker answers and related emails are stored in one mailbox. A shared mailbox doesn’t have its own user name and password.

Microsoft didn’t have any control over shared mailbox sent items in Exchange 2013 and Exchange online and as a fix customer need to make registry changes on end users machine. This cause a lot of administrative overhead for customers and IT admins. Several customers of mine has not considered to upgrade to Exchange 2013 or migrate to Office 365 due to this limitation of sent items.

Registry fix doesn’t work with the users using outlook in online mode. This fix is only applicable when user is running outlook in cached mode.

With Exchange 2013 CU9 email sent by a user using shared mailbox will be delivered to the Sent Items folder of shared mailbox and to the user mailbox sent items. Microsoft has already started to roll out this new feature to the customers using Office 365 shared mailboxes.

Enable Office 365 Shared Mailbox Sent Items Feature

By default, this feature will be disabled to all the customers and administrator need to run the following PowerShell cmdlet.

For emails Sent As the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True

For emails Sent On Behalf of the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $True

Disable Office 365 Shared Mailbox Sent Items Feature

To disable this feature run the following powershell cmdlets

For emails Sent As the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $False

For emails Sent On Behalf of the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $False

To enable this feature for Exchange online, we need to first connect to Exchange online powershell.

More information on new enhancements in exchange 2013 CU9 can be found on Microsoft Knowledge Base.

Office 365 Encryption Options

Office 365 Encryption Option

Office 365 Encryption Options

Encryption is the process by which information is encoded so that only an authorized recipient can decode and use the information. Microsoft offered multiple Office 365 encryption options to their customers. Office 365 encryption Option is used in two ways, One is by implementing encryption in the service and the second is by offering it to you as a customer control. In the service, Microsoft make use of encryption in the platform, where it works by default and you don’t have to configure anything. For example, Office 365 uses Transport Layer Security (TLS) to encrypt the connection / session between two servers.

Why we need Office 365 Encryption?

At times, organizations needs to communicate with external organizations on a secure encrypted channel to meet their regulatory / compliance requirements. To fulfill the compliance requirements organizations opt office 365 encryption options. Office 365 encryption options provide their customers the benefit to stay ahead to gain control and improve security and reliability of their system. Encryption options offers following benefits to the customers:

  • To stay in control by automatically protecting sensitive information
  • To meet compliance / regulatory requirements
  • To secure confidential information

We currently have 5 different types of Office 365 message encryption option that we can configure to secure our messages in office 365.

  • Office Message Encryption
  • S/MIME
  • Transport Layer Security (TLS)
  • BitLocker
  • Information Rights Management

Office Message Encryption

In November 2013, Microsoft announced Office 365 Message Encryption to send encrypted email messages to people inside or outside of the organization regardless of the destination email service.

Office 365 Message Encryption is designed to help organizations to send confidential messages to people outside your company simply and securely, without the administrative overhead required to use S/MIME or similar technologies. It’s an outside-the-company companion to Information Rights Management, which is why it’s included as part of the Windows Azure Rights Management offering as well.

There are many scenario’s when you need to encrypt your email like

  • Sending credit card statements to customers over email.
  • Sharing confidential information with someone like Social Security number, credit card number etc.
  • Sharing financial information for a loan application.
  • An attorney sending confidential information to a client or another attorney.
  • Sending a contract to someone else.
  • Sharing a company policy with someone.

Office 365 Message Encryption is an enhanced version of Exchange Hosted Encryption (EHE), with the addition of a new set of features. To learn more about all security features in Office 365, kindly visit the Office 365 Trust Center

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Second Message Encryption option in office 365 that we have is S/MIME, which is a widely accepted method / protocol used to send encrypted and digitally signed messages to the recipient using Rivest-Shamir-Adleman (RSA) encryption system. S/MIME is a client-side encryption technology that requires a certificate management and publishing infrastructure.

S/MIME is as important a standard as SMTP because it brings SMTP to the next level, allowing widespread e-mail connectivity without compromising security.

Before S/MIME, administrators used a widely accepted e-mail protocol SMTP, which was inherently not secure, or they used more secure but proprietary solutions. Administrators chose a solution that emphasized either security or connectivity. S/MIME requires Exchange 2013 SP1 or Exchange online with outlook 2010, outlook 2013, OWA and EAC to work properly.

Transport Layer Security (TLS)

TLS, or Transport Layer Security, allows two separate Exchange organizations to transfer mail between them over an encrypted connection. TLS works very similarly to the way SSL works in your web browser.

By default office 365 uses TLS connections to send/receive email messages. TLS in Exchange Online and Domain Security in Exchange 2010 and 2013 are two different concepts and let’s have a high level overview of both technologies.

Domain Security is a set of functionality in the on-premises version of Exchange that started with Exchange 2010 and Outlook 2007 that is intended to provide a lower cost alternative to S/MIME or other message level security solutions.

Transport Layer Security (TLS) is an encryption protocol designed to create a secure communication tunnel over the public internet. Exchange Online gives you the option to setup send and receive connectors to specific partners that are always encrypted.

TLS encrypts the tunnel between mail server to help prevent snooping/eavesdropping.

BitLocker

BitLocker is a drive encryption technology included in Windows Server 2008 and newer versions. BitLocker provides AES (Advanced Encryption Standard) encryption of your email data at rest. That means if for some reason, someone managed to break into an Office 365 data center and steal the hard drive that contains your Exchange Online database, they would not be able to access the data on that hard drive unless they also had the encryption key.

AES uses the same key to encrypt and decrypt the data. I’m not going to spend much time on the specifics of how this type of encryption works because there is nothing for you to configure in Exchange Online, but you can find more information on BitLocker on TechNet.

BitLocker is a great example of one of the reasons to go to Office 365. Microsoft has already performed a lot of the configuration work for setting up secure Exchange for you. BitLocker is already setup on your tenant and all your data is encrypted in Microsoft data center but there is no way for us verify this. Microsoft does comply with a number of different 3rd party auditing procedures to verify things like this. You can find more information on this subject at the Office 365 Trust Center website.

BitLocker Encryption has already been applied to all office 365 tenants and managed by Microsoft.

Information Rights Management

Information Rights Management (IRM) provides the world of Office 365 with far more control over the degree of document access and security allowed. Information Rights Management in Office 365 prevents sensitive information from being printed, forwarded, or copied by unauthorized people inside the organization. Information Rights Management (IRM) enables content owner / publisher to create rights protected content such as an email message or document.

IRM helps individuals enforce their personal preferences regarding the transmission of personal or private information. It also helps organizations enforce corporate policy governing the control and dissemination of confidential or proprietary information within the organization and with customers and partners. More information on Information Rights Management can be found on TechNet.

Microsoft has two methods to enable IRM within the Office 365 productivity suite (Word, Excel and PowerPoint). The first is to install the IRM services on a Windows 2003 or 2008 server, which enables integration within a corporate Windows domain. This integration allows a content author to select which users and groups from Active Directory have access to their content. The second method is to use a Windows Live ID. This enables companies without an Active Directory environment to restrict user access based on a user’s email address.

1 2