Office 365 Message Encryption OME

Office 365 Message Encryption (OME) is a Microsoft solution to send mail safely, fully encryption with multiple layers of protection. Instead of sending an email to a recipient via SMTP, the message is encrypted and stored on a Microsoft viewing portal. An informational message is sent to the recipient with a one-time password which the recipient can use to logon to the viewing portal and read the (decrypted) message as shown in the following picture:

Office 365 Message Encryption Overview

To configure OME you have to enable Azure Rights Management first. To do this, open the Office 365 Admin portal and select Settings | Services & Add-ins. In the details pane select Microsoft Azure Information Protection. Click Manage Microsoft Azure Information Protection Settings as shown in the following screenshot:

Enable Azure information Protection

Click Activate and after a few moments you will see a confirmation.

Azure Rights Management is activated

If you open Exchange Online Powershell and execute Get-IRMConfiguration you will see that AzureRMS is enabled as shown in the screenshot below. Please note that the LicensingLocation is empty, this is important in subsequent steps.

Get-IRMConfiguration

According to Microsoft documentation you should now be able to test the IRM configuration using the Test-IRMConfiguration command, but this will fail with a “Failed to acquire RMS templates” error as shown in the following screenshot:

Test-IRMConfiguration Fails

The reason for this (took me some time to figure out) is that the LicensingLocation property is empty. To populate this property, we can retrieve the correct value from the Azure AD Right Management service using PowerShell. This can be installed using the Install-Module AIPService command.

After installing, open the Exchange Online PowerShell module and execute the following commands:

PS C:\> $RMSConfig = Get-AadrmConfiguration

PS C:\> $RMSConfig

PS C:\> $LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl

PS C:\> $LicenseUri

PS C:\> Set-IRMConfiguration -LicensingLocation $LicenseUri

PS C:\> Set-IRMConfiguration -InternalLicensingEnabled $true

Note. The only reason for executing the $RMSConfig and $LicenseUri commands is to check is there are any values in these variables. The output is shown in the following screenshot:

RMSConfig

When you execute the Test-IRMConfiguration command again you will see it succeeds:

Test-IRMConfiguration

So how do you know this works?

The easiest way is to use OWA. To create an additional “encrypt” button in OWA, execute the following command in the Exchange Online PowerShell window:

PS C:\> Set-IRMConfiguration -SimplifiedClientAccessEnabled $true

Now when creating a new message in OWA this button is clearly visible. Send a new message (to your own test account for example in Gmail) and click the Encrypt button. A message will appear that this message is encrypted, nice to know, the recipients cannot remove the encryption, only the sender of the message can change this. You can use the change permissions button to change it from encrypt only to do not forward or confidential.

Encrypt button in OWA

After a few second the email will appear in Gmail, but not directly. You have to open the decrypted message on the viewing portal. A one-time password can be used (which is sent to the same email address, i.e. the Gmail address we used here) or you can use the Gmail account to logon. The latter is also true if the recipient is a hotmail mailbox or even nicer, an Office 365 mailbox.

OME in Gmail

When you click Read the message it will be opened on the viewing portal.

view ome

A message is displayed again that this is an encrypted message. When you reply to the message, an encrypted message is returned to the original sender. If you have selected do not forward in the permissions drop down box earlier, the recipient does not have this option and can only reply to the message.

It also works fine in Outlook (I have tested this with Outlook 2016 Click-2-Run, still have to test other versions). If you create a new message and select Options, you can select Connect to Rights Management Server and get templates under Permissions as shown in the following screenshot:

Outlook Connect to Rights Management Server

This will retrieve the RMS templates from Exchange Online that were created earlier in this blog post. In a few seconds you will see the following options:

  • Encrypt Only
  • Do not forwards
  • Confidential
  • Confidential View Only

Outlook Set permissions on this item

When you select Encrypt Only  as shown in the following screenshot an encrypted message will be sent to the intended recipient:

Outlook Encrypt Only

From this point the behavior will be the same as with Outlook Web App as discussed earlier in this blog post.

Summary

Outlook Message Encryption as outlined in this blog post is a way to send encrypted messages to recipients. It’s not encryption in transit like TLS or S/MIME, but the encrypted message is stored on a Microsoft server. The recipient will receive an email that an encrypted message is waiting, and the recipient can logon to a special website using a one-time password (or using a Microsoft or Gmail account).

Since the RMS (Rights Management Service) templates are used it is also possible to use additional features like do not forward (the forward button is greyed out) or tag a message as confidential. This can be used in combination with transport rules to add additional features or mail flow when it comes to confidential information, functionality that’s not available when using good old email.

Microsoft Teams The request is not properly formatted

Every now and then we get a call from end users that they cannot login at Microsoft Teams and they get an error message “The request is not properly formatted” and “The parameter ‘login_hint’ is duplicated.“, especially after changing the user password. The error message is (partly in Dutch) shown in the following screenshot:

The request is not properly formatted

This error message is recurring, so it’s not possible to logon anymore. It looks like there’s something stored in a cache related to the user’s old credentials. To resolve this, you can follow these steps:

  • Exit the Teams client, and make sure Outlook is also closed since Outlook can have open add-ins related to teams.
  • Go to the directory C:\Users\<username>\Appdata\Microsoft\Teams (shown below) and delete all files and directories found there. If any files cannot be deleted, most likely Outlook is still locking files.

AppData Microsoft Teams

When all files are deleted you can start the Teams client again and it should logon successfully.

Azure Files Backup and Restore

In contrast to SharePoint Online and OneDrive for Business there’s no recycle bin for Azure Files available. Data is Azure is stored redundant and you can even opt for a multi-geo redundancy, but when (accidentally) deleting files they are gone.

To prevent unwanted deletion of data you can use Azure Backup to make sure your data is always safe, and that you can restore data.

To implement backups in Azure, you must create an Azure Recovery Services Vault. To do this, go to the Azure Portal and type Recovery Services Vault in the All services search box and click Create Recovery Services Vault. When entering the details make sure you use the same region as where your file share is located (West Europe in my example) as shown in the following screenshot:

Create Recovery Services Vault

Click Review + Create and click Create.

In the All Resources blade click on the newly created Vault to see all properties for the new Vault. To create a backup of the Azure Files, click + Backup and in the What do you want to backup drop down box select Azure FileShare (Preview) and click Backup. It can take a couple of seconds before the correct Storage Account appears:

Select Storage Account

Select the Storage Account and click OK. It can take a minute before the Storage Account is validated. The file shares that can be backed up will also be automatically discovered, this can also take some time. Select the file share and click OK.

The last step is to configure an Azure backup policy as shown in the following screenshot:

Azure Backup Policy

Create your own policy, pay attention to the retention time which is 30 days by default, click OK and click Enable backup.

The Azure Recovery Services Vault and backup policy will now be created. After some time the backup is created, and an initial backup will be performed.

Initial backup pending

You can open the backup items and click backup now or you can wait until the next backup has automatically run (3:30 AM in my example).

Restore files from Azure Backup

Backing up files is nice and important, but even more important is the ability to restore files from backup. And restoring files from Azure backup is pretty simple.

Open the Azure Portal and navigate to the Recovery Services Vault that was created previously. In the details of the Vault, click on backup items under Protected items. You will see several backup management types, select the Azure Storage (Azure Files) option. There should be one or more Backup items available. Select one of the backup items and click on the context menu (the three dots on the right of the backup item) and select File Recovery as shown in the following screenshot:

Backup Items

Click on the date and time restore point and click OK. Click on Select File and browse through the directory structure that’s in the backup set, until you’ve found the file or directory you want to restore. Select this item and click Select. Select Original location or Alternate location and in the drop down box determine what action should be taken in case of conflicts (Overwrite, Skip or Create Copy). Click OK and click Restore to start the restore of your deleted item(s). After a short amount of time (depending of the size and amount of files) the data should be restored, and visible again the Windows Explorer.

Summary

In Azure Files there’s no recycle bin for restoring (accidentally) deleted files, so you have to rely on backup and restore. To achieve this, you can implement the Azure Recovery Services Vault. You can implement a Vault (in the same region as where your data is stored) and create a backup policy to store backup files in the Vault. Once backed up, you can restore files easily from the Vault using the Azure Portal. It depends on your own retention policy how long the data should be kept in the Vault, but your data should be safe now.

 

Azure Files instead of SharePoint Online

Most of my customers are in one way or another moving to Office 365. Not only Exchange Online, but also OneDrive for Business, SharePoint Online, Teams and other cloud services.

SharePoint Online a great solution of collaboration solutions, when multiple people are working on multiple documents in a department, group or project style.

One of my clients has a department with two employees, but with approx. 4TB of primarily static data. They store data on a file share and store it there for 20 years or more. The directory structure reflect the organization, but also the timeframe, so the directory structure is deep and filenames are typically long. Combine this with the 256 character URL limit in SharePoint and there’s the challenge, you can not simple move this to SharePoint Online. Restructuring the data would be a solution when moving to SharePoint Online, but that would be a massive project.

Another solution would be the use of Azure Files, where a file share is created in Azure and where the users can access the files directly in Azure, just like a regular share on the on-premises fileserver. And if you have a low bandwidth and high latency Internet connection, you can always implement a caching server on-premises, where an offline copy is stored on-premises. Compare this to OneDrive for Business where a copy of the data can be stored on your workstation.

To create an Azure file share, follow these steps:

In the Azure Portal, create a new Resource Group (or use an existing one).

To create a new storage account, select All Services in the Azure Portal, and in the all services blade type storage accounts. Click on Storage Accounts and click +Add to create a new storage account. Select your subscription, the Resource Group, enter a unique name, select the location/region closest to your own location and the performance characteristics, like in the following screenshot:

Create Storage Account

Click Review + Create, and after reviewing click Create to create the new storage account.

When the storage account is created you can create the file share. Select the storage account and under File service, select Files and click + File Share. In the upper right corner, enter a name and quota, and click on Create.

The file share is now created and can be viewed in the Azure Portal:

Azure File Share

When you click the Connect icon, commands are shown for Windows, Linux en MacOS to connect the clients to the new file share. When using PowerShell, pay attention to the -Global and -Persist switch to make sure the connection will be kept after you close the PowerShell window and after rebooting. You can use tools of your choice (Storage Explorer, Windows Explorer, XCopy, RoboCopy etc) to copy data from the old location to the Azure File Share.

On the client, you can see the newly created file share in Windows explorer:

Azure File Share Explorer

Summary

In some scenarios it is not always feasible to use SharePoint Online for storing files, and in such scenarios Azure Files can be a good candidate. In this blog I’ve showed you how to create a storage account and an Azure File Share to be used within (Windows) clients.
In my next blog I’ll discuss Azure files and backup, since there’s no Recycle Bin in Azure Files like there is in SharePoint Online or OneDrive for Business.

 

Block creation of Office 365 Groups

I’m an old school IT guy, in my world provisioning is done via the IT department or via a provisioning tool. What I don’t want is that regular users create all kinds of objects in my environment, whether it be Active Directory, Azure Active Directory or Office 365.

In Office 365 everything is different, multiple services (Outlook, Teams, Planner, SharePoint, PowerBI and others) are using Office 365 Groups under the hood. So, when users create a new plan in Planner or a new team in Teams, they also create an Office 365 Group in Azure Active Directory.

I’m currently working in a 12,000-user environment, and the last thing I want to happen is 12,000 users randomly creating all kinds of groups, ending up in a total mess where nobody can find information and where it is impossible to delete anything without hurting other people.

The solution for this is to assign the creation of new Office 365 to a security group in Azure Active Directory (this can be a cloud object or a synchronized object). To create a new security group in Azure Active Directory you can use the following PowerShell command:

New-AzureADGroup -DisplayName "O365 Group Creators" -SecurityEnabled:$True -MailEnabled:$False -MailNickName "Nothing"

New-AzureADGroup

Note. It is also possible to create a security group in the Azure AD Portal.

The next step is to assign the permission to create Office 365 Groups to this new security group. This can only be achieved using PowerShell and the Azure AD Preview Module, using the following script:

$GroupName = "O365 Group Creators"
$AllowGroupCreation = "False"
Connect-AzureAD
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
if(!$settingsObjectID)
{
  $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
  $settingsCopy = $template.CreateDirectorySetting()
  New-AzureADDirectorySetting -DirectorySetting $settingsCopy
  $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}
$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation
if($GroupName)
{
  $settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid
}
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

When you run this script, you will see a similar output:

GroupCreators

The first box corresponds to the objectID of the security group we’ve created in the first step, just compare with the ObjectID shown in the first screenshot.

The second box shows $false for the EnableGroupCreation property, indicating no other groups are allowed to create Office 365 Groups.

All members of the security group we just created are allowed to create Office 365 groups. There are some exceptions though, Exchange admins, SharePoint admins, Teams admins and User Management admins are by default allowed to create Office 365 groups as well, but typically these are not regular users.

This way you can control who is able to create Office 365 Groups in your environment, and make sure group creation doesn’t explode in your tenant.

More information