Configuring Exchange On-Premises to Use Azure Rights Management


This article is the fifth in a series of posts looking at Microsoft’s new Rights Management product set. In an earlier previous post we looked at turning on the feature in Office 365 and in this post we will look at enabling on-premises Exchange Servers to use this cloud based RMS server. This means your cloud users and your on-premises users can shared encrypted content and as it is cloud based, you can send encrypted content to anyone even if you are not using an Office 365 mailbox.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Exchange Server integrates very nicely with on-premises RMS servers. To integrate Exchange on-premises with Windows Azure Rights Management you need to install a small service online that can connect Exchange on-premises to the cloud RMS service. On-premises file servers (classification) and SharePoint can also use this service to integrate themselves with cloud RMS.

You install this small service on-premises on servers that run Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2. After you install and configure the connector, it acts as a communications interface between the on-premises IRM-enabled servers and the cloud service. The service can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=40839

From this download link there are three files to get onto the server you are going to use for the connector.

  • RMSConnectorSetup.exe (the connector server software)
  • GenConnectorConfig.ps1 (this automates the configuration of registry settings on your Exchange and SharePoint servers)
  • RMSConnectorAdminToolSetup_x86.exe (needed if you want to configure the connector from a 32bit client)

Once you have all this software (or that which you need) and you install it then IT and users can easily protect documents and pictures both inside your organization and outside, without having to install additional infrastructure or establish trust relationships with other organizations.

The overview of the structure of the link between on-premises and Windows Azure Rights Management is as follows:

IC721938

Notice therefore that there are some prerequisites needed. You need to have an Office 365 tenant and turn on Windows Azure Rights Management. Once you have this done you need the following:

  • Get your Office 365 tenant up and running
  • Configure Directory Synchronization between on-premises Active Directory and Windows Azure Active Directory (the Office 365 DirSync tool)
  • It is also recommended (but not required) to enable ADFS for Office 365 to avoid having to login to Windows Azure Rights Management when creating or opening protected content.
  • Install the connector
  • Prepare credentials for configuring the software.
  • Authorising the server for connecting to the service
  • Configuring load balancing to make this a highly available service
  • Configuring Exchange Server on-premises to use the connector

Installing the Connector Service

  1. You need to set up an RMS administrator. This administrator is either the a specific user object in Office 365 or all the members of a security group in Office 365.
    1. To do this start PowerShell and connect to the cloud RMS service by typing Import-Module aadrm and then Connect-AadrmService.
    2. Enter your Office 365 global administrator username and password
    3. Run Add-AadrmRoleBasedAdministrator -EmailAddress <email address> -Role “GlobalAdministrator” or Add-AadrmRoleBasedAdministrator -SecurityGroupDisplayName <group Name> -Role “ConnectorAdministrator”. If the administrator object does not have an email address then you can lookup the ObjectID in Get-MSOLUser and use that instead of the email address.
  2. Create a namespace for the connector on any DNS namespace that you own. This namespace needs to be reachable from your on-premises servers, so it could be your .local etc. AD domain namespace. For example rmsconnector.contoso.local and an IP address of the connector server or load balancer VIP that you will use for the connector.
  3. Run RMSConnectorSetup.exe on the server you wish to have as the service endpoint on premises. If you are going to make a highly available solutions, then this software needs installing on multiple machines and can be installed in parallel. Install a single RMS connector (potentially consisting of multiple servers for high availability) per Windows Azure RMS tenant. Unlike Active Directory RMS, you do not have to install an RMS connector in each forest. Select to install the software on this computer:
    IC001
  4. Read and accept the licence agreement!
  5. Enter your RMS administrator credentials as configured in the first step.
  6. Click Next to prepare the cloud for the installation of the connector.
  7. Once the cloud is ready, click Install. During the RMS installation process, all prerequisite software is validated and installed, Internet Information Services (IIS) is installed if not already present, and the connector software is installed and configured
    IC002
  8. If this is the last server that you are installing the connector service on (or the first if you are not building a highly available solution) then select Launch connector administrator console to authorize servers. If you are planning on installing more servers, do them now rather than authorising servers:
    IC003
  9. To validate the connector quickly, connect to http://<connectoraddress>/_wmcs/certification/servercertification.asmx, replacing <connectoraddress> with the server address or name that has the RMS connector installed. A successful connection displays a ServerCertificationWebService page.
  10. For and Exchange Server organization or SharePoint farm it is recommended to create a security group (one for each) that contains the security objects that Exchange or SharePoint is. This way the servers all get the rights needed for RMS with the minimal of administration interaction. Adding servers individually rather than to the group results in the same outcome, it just requires you to do more work. It is important that you authorize the correct object. For a server to use the connector, the account that runs the on-premises service (for example, Exchange or SharePoint) must be selected for authorization. For example, if the service is running as a configured service account, add the name of that service account to the list. If the service is running as Local System, add the name of the computer object (for example, SERVERNAME$).
    1. For servers that run Exchange: You must specify a security group and you can use the default group (DOMAIN\Exchange Servers) that Exchange automatically creates and maintains of all Exchange servers in the forest.
    2. For SharePoint you can use the SERVERNAME$ object, but the recommendation configuration is to run SharePoint by using a manually configured service account. For the steps for this see http://technet.microsoft.com/en-us/library/dn375964.aspx.
    3. For file servers that use File Classification Infrastructure, the associated services run as the Local System account, so you must authorize the computer account for the file servers (for example, SERVERNAME$) or a group that contains those computer accounts.
  11. Add all the required groups (or servers) to the authorization dialog and then click close. For Exchange Servers, they will get SuperUser rights to RMS (to decrypt content):
    image
    image
  12. If you are using a load balancer, then add all the IP addresses of the connector servers to the load balancer under a new virtual IP and publish it for TCP port 80 (and 443 if you want to configure it to use certificates) and equally distribute the data across all the servers. No affinity is required. Add a health check for the success of a HTTP or HTTPS connection to http://<connectoraddress>/_wmcs/certification/servercertification.asmx so that the load balancer fails over correctly in the event of connector server failure.
  13. To use SSL (HTTPS) to connect to the connector server, on each server that runs the RMS connector, install a server authentication certificate that contains the name that you will use for the connector. For example, if your RMS connector name that you defined in DNS is rmsconnector.contoso.com, deploy a server authentication certificate that contains rmsconnector.contoso.com in the certificate subject as the common name. Or, specify rmsconnector.contoso.com in the certificate alternative name as the DNS value. The certificate does not have to include the name of the server. Then in IIS, bind this certificate to the Default Web Site.
  14. Note that any certificate chains or CRL’s for the certificates in use must be reachable.
  15. If you use proxy servers to reach the internet then see http://technet.microsoft.com/en-us/library/dn375964.aspx for steps on configuring the connector servers to reach the Windows Azure Rights Management cloud via a proxy server.
  16. Finally you need to configure the Exchange or SharePoint servers on premises to use Windows Azure Active Directory via the newly installed connector.
    • To do this you can either download and run GenConnectorConfig.ps1 on the server you want to configure or use the same tool to generate Group Policy script or a registry key script that can be used to deploy across multiple servers.
    • Just run the tool and at the prompt enter the URL that you have configured in DNS for the connector followed by the parameter to make the local registry settings or the registry files or the GPO import file. Enter either http:// or https:// in front of the URL depending upon whether or not SSL is in use of the connectors IIS website.
    • For example .\GenConnectorConfig.ps1 –ConnectorUri http://rmsconnector.contoso.com -SetExchange2013 will configure a local Exchange 2013 server
  17. If you have lots of servers to configure then run the script with –CreateRegEditFiles or –CreateGPOScript along with –ConnectorUri. This will make five reg files (for Exchange 2010 or 2013, SharePoint 2010 or 2013 and the File Classification service). For the GPO option it will make one GPO import script.
  18. Note that the connector can only be used by Exchange Server 2010 SP3 RU2 or later or Exchange 2013 CU3 or later. The OS on the server also needs to be include a version of the RMS client that supports RMS Cryptographic Mode 2. This is Windows Server 2008 + KB2627272 or Windows Server 2008 R2 + KB2627273 or Windows Server 2012 or Windows Server 2012 R2.
  19. For Exchange Server you need to manually enable IRM as you would do if you had an on-premises RMS server. This is covered in http://technet.microsoft.com/en-us/library/dd351212.aspx but in brief you run Set-IRMConfiguration -InternalLicensingEnabled $true. The rest, such as transport rules and OWA and search configuration is covered in the mentioned TechNet article.
  20. Finally you can test if RMS is working with Test-IRMConfiguration –Sender billy@contoso.com. You should get a message at the end of the test saying Pass.
  21. If you have downloaded GenConnectorConfig.ps1 before May 1st 2014 then download it again, as the version before this date writes the registry keys incorrectly and you get errors such as “FAIL: Failed to verify RMS version. IRM features require AD RMS on Windows Server 2008 SP2 with the hotfixes specified in Knowledge Base article 973247” and “Microsoft.Exchange.Security.RightsManagement.RightsManagementException: Failed to get Server Info from http://rmsconnector.contoso.com/_wmcs/certification/server.asmx. —> System.Net.WebException: The request failed with HTTP status 401: Unauthorized.”. If you get these then turn of IRM, delete the “C:\ProgramData\Microsoft\DRM\Server” folder to remove old licences, delete the registry keys and run the latest version of GetConnectorConfig.ps1, refresh the RMS keys with Set-IRMConfiguration –RefreshServerCertificates and reset IIS with IISRESET.

Now you can encrypt messages on-premises using your AADRM licence and so not require RMS Server deployed locally.

Comments

21 responses to “Configuring Exchange On-Premises to Use Azure Rights Management”

  1. Radiology Group avatar
    Radiology Group

    Thanks for the article. 2 questions:

    1. Will this add an Exchange Transport action to allow encrypting e-mails as an action to an ETR?

    2. Is it possible to add encryption natively to on-premise Exchange w/out using the cloud service?

    1. Brian Reid avatar

      The ETR for Exchange is already present (rights protect message with RMS template). Just choose this after you have configured all the rest of the steps and choose the RMS template you want to protect content with.

      And for the second question, yes you can do encryption without using Azure Rights Management Service (the cloud one) and instead use ADRMS (Active Directory Rights Management). Disadvantage is that it is very complex to share keys externally with the on-premises RMS server. The cloud service authorises key release from the cloud (it does not store or require data or documents sent to the cloud) but allows you to share data encrypted with external parties.

      To see the ADRMS steps see

  2. Ravi avatar
    Ravi

    Great Article !! Simplified and explained in details . Followed all steps and RMS in place for us . Thanks .

  3. MARK avatar

    All the above configurations are done
    Also the one mentioned in the article are also verified
    https://technet.microsoft.com/en-in/library/dn375964.aspx#BKMK_HowToRunTheTool but set-irmconfiguration -internallicensingenabled $true is failing with string cannot be zero error and a watson dump is generated

    1. Brian Reid avatar

      This error implies that something is not correct. I would double check everything. check that RMS is not already set up locally and that the accounts used are working fine.

  4. tomer katsir avatar
    tomer katsir

    hi,
    can I add an additional AZURE RMS connector after I had launched the connector administrator console and configured the servers to authorize?

    1. Brian Reid avatar

      I believe so. Do you mean like to add HA after the installation and configuration? I know the docs say that you set up all the servers and then configure, but I have done the configuration and added servers afterwards in the lab.

  5. Hamza avatar
    Hamza

    Hi,
    You have mentioned that install the VIP certificate in case the servers are behind the load balancer. What if the load balancer is doing SSL offloading and applies its own certificate on the VIP URL. Do I still need to replace the server certificate with VIP certificate?

    1. Brian Reid avatar

      I would not SSL Offload but either pass through or SSL Bridging. You cannot inspect the traffic and if you do you risk breaking it, so don’t inspect. Aka certificate pinning could be going on and SSL offload would break it

  6. Sheeraz avatar
    Sheeraz

    Hi Brian,
    A customer is running On-Premises Exchange 2016 with CU 11 and i have set up Azure Information Protection (AIP) and it has also been integrated with On-Premises Exchange with set up of RMS connector. While evaluating different scenarios for AIP, we noticed that AIP policy templates are not appearing when users are connected to Exchange through Outlook Web Access (OWA). However; in OWA users can see “Do not forward” option.

    Secondly, Android users and iOS users when using native Apps or Outlook App are also not getting any AIP templates.

    While users are not facing any issues when they are connecting through Office ProPlus or Office 2016 Professional version to

    Exchange server from their Desktop/ Laptop.

    Please suggest, if AIP templates are supported on OWA and on ActiveSync clients – if so, what else to verify. Thanks

    1. Brian Reid avatar

      AIP for on-premises servers only supports the RMS component of such. See https://docs.microsoft.com/en-us/azure/information-protection/requirements-servers for this. Client software gets AIP add-in directly and so supports it regardless of where their mailbox is, but OWA on-premises will only show RMS templates (protection templates) and not the AIP label that may or may not contain a protection template.

      1. Andrea avatar
        Andrea

        Hi brain, Microsoft knows that? I have the same issue of Sheeraz on premises side… They say that it should work. So aip label with protection should be seen on premises ….. But it doesn’t!

        1. Brian Reid avatar

          Where do you see the statement that it should work please?

          1. Andrea avatar
            Andrea

            Hi Brian, Sorry for extreme delay,….
            About the statement : Nir Hendler – Program Manager of microsoft azure information say that it should.
            Secondary on an a test environment i created an AIP label with protection and assigned on global policy…. It shows on ehchange on premise (mail flow rules) and inside set permission of OWA.
            After that i created a new label AIP then i’ve created a new policy and the assigned to all users….. this time label was not shown in exchaange on premise (mail flow rules) but not inside set pernmission inside OWA.

            Looking at comments it shoul de correct that AIP label are not seen inside owa on premise….. right? but it seems that this is true only for label not inside the global policy.

  7. Grant Terry avatar
    Grant Terry

    This is a great article.
    Trying to confirm that it’s possible to use OWA 2010 to decrypt previously encrypted AD RMS content once migrated to Azure.
    We have configured our RMS Connector servers, configured the Exchange on-prem servers, Disabled the AD RMS SCP, and we had already imported our (AD RMS) TPD into Azure, and the Test-IRMConfiguration –Sender billy@contoso.com works fine, all PASS.
    We can create and consume Azure RMS content in OWA. The issue is that only Azure Protected RMS content can be consumed, AD RMS content in OWA cannot be opened.
    We get the following error when opening different AD RMS protected emails.
    Error: Failed to find server info for the RMS server https://rmsconnector.devdomain.local/_wmcs/licensing
    Consuming AD RMS content should work in OWA?

    1. Brian Reid avatar

      Your connector needs to be published to the internet and reachable from Azure Information Protection and Exchange Online. Your URI of devdomain.local is not internet routable.

      1. Grant Terry avatar
        Grant Terry

        From what I have read (including this article) the RMS connector does NOT need to reachable from the Internet and can use .local addresses.
        2.Create a namespace for the connector on any DNS namespace that you own. This namespace needs to be reachable from your on-premises servers, so it could be your .local etc. AD domain namespace. For example rmsconnector.contoso.local

        I would like to confirm that Exchange 2010 can successfully consume AD RMS content via the RMS Connector. I am not able to make this happen. AD RMS content cannot be consumed. Azure RMS content works fine.

  8. Brian Reid avatar

    OK, I think you are are are looking at it from opposite points of view. Are you asking if OWA in Exchange Online can use the connector to reach an on-premises RMS server? If so the answer is no. You move your RMS Server to Azure RMS and then use the connector to allow on-premises services to reach Azure RMS – you decomission AD RMS when you have this in place.

    1. Grant Terry avatar
      Grant Terry

      We have about half of our users in Exchange Online and half still using Exchange on-prem. We have imported the AD RMS TPD into Azure and now we have our on-prem AD RMS key stored in Azure. The on-prem users are using 2010 Exchange and OWA. These on-prem users are not able to consume previously created AD RMS content using the AD RMS Key that is stored in Azure. OWA makes a connection to the on-prem RMS connector (using a registry redirect on the OWA CAS server) and the RMS server passes that request to Azure.

      I have two redirect entries in the Registry on the 2010 CAS servers.
      1. Azure RMS URL points to local RMS connector
      2. on-prem AD RMS URL points to local RMS connector

      Everything with Azure RMS content works, but consuming AD RMS content in OWA (through the connector) does not. Has anyone successfully configured this?

  9. Jamie avatar
    Jamie

    Hi there, great article, I was hoping you could help with something. We have a hybrid environment setup where all email is sent via office 365 (some mailboxes on premise, some in EOL) using DLP rule which encrypts mail. Our on premise users get the ‘someone has sent you a protected message’ when recieving returned emails when our EOL mailbox users get the native inline decrypted experience.

    I’ve done all of the above, what am I missing? Is what I am trying to achieve possible?

    Thanks,

    Jay

    1. Brian Reid avatar

      If your DLP rule is set to “external only” then its possible that EXO is seeing your on-premises environment as external. Do emails EXO to EXS show auth as anonymous or internal in the headers? Or set your DLP rules to exclude on-prem users from the encryption, or move all your mailboxes to the cloud!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.