After some client discussions and demos, I decided to go ahead and install the on-premises RMS connector in our lab environment in order to demo some of the capabilities. As most folks are aware, Active Directory RMS (ADRMS) is no longer being developed, in favor of Azure RMS (AZRMS) in the cloud. Part of this new architecture is to deploy an AZ RMS Connector server on-premises since Exchange, SharePoint and FCI don’t know how to do that natively (where they did with ADRMS).
This first post will focus on installing and configuring the RMS Connector server.
Below you can find a reference architecture for the RMS connector deployment. In a production scenario, you’d obviously want to deploy more than 1 RMS connector server and load balance them for high-availability.
It should also be noted that you will need a pre-existing Azure AD subscription with RMS enabled (not shown here).
You can first grab the RMS Connector source files here.
- You will generally use the RMSConnectorSetup.exe file for 64-bit server installs
- If you later want to configure the connector from a 32-bit computer, also download RMSConnectorAdminToolSetup_x86.exe.
- If you want to use the server configuration tool for the RMS connector, to automate the configuration of registry settings on you on-premises servers, also download GenConnectorConfig.ps1.
Let’s start by launching the RMSConnectorSetup.exe file
Before you can configure the RMS connector, you must enter credentials for an account that has sufficient
privileges to configure the RMS connector.
You can use an account that has one of the following privileges:
- Office 365 tenant administrator: An account that is a global admin for your Office 365 tenant.
- Azure Rights Management global administrator: An account with administrator privileges for the Azure RMS tenant.
- Microsoft RMS connector Administrator: An account in Azure Active Directory that has been granted rights to install and administer the RMS connector for your organization.
At this point, there is a verification test that you can perform to test whether the web services for the RMS connector are operational:
- From a web browser, 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.
Now time to authorize on-premises servers to be able to use the RMS connector, such as Exchange, SharePoint for File Servers with the File Server Classification Infrastructure role.
When you authorize these servers, be aware of the following considerations:
- Servers that you add will be granted special privileges. All accounts that you specify for the Exchange Server role in the connector configuration will be granted the super user role in Azure RMS, which gives them access to all content for this RMS tenant. The super user feature is automatically enabled at this point, if necessary. To avoid the security risk of elevation of privileges, be careful to specify only the accounts that are used by your organization’s Exchange servers. All servers configured as SharePoint servers or file servers that use FCI will be granted regular user privileges.
- You can add multiple servers as a single entry by specifying an Active Directory security or distribution group, or a service account that is used by more than one server. When you use this configuration, the group of servers will share the same RMS certificates and will all be considered owners for content that any of them have protected. To minimize administrative overheads, we recommend that you use this configuration of a single group rather than individual servers to authorize your organization’s Exchange servers or a SharePoint server farm.
On the Servers allowed to utilize the connector page, click Add.
Notes on RMS Connector configuration for:
- You must specify a security group and you can use the default group (Exchange Servers) that Exchange automatically creates and maintains of all Exchange servers in the forest.
- If a SharePoint 2010 server is configured to run as Local System (it’s not using a service account), manually create a security group in Active Directory Domain Services, and add the computer name object for the server in this configuration to this group.
If a SharePoint server is configured to use a service account (the recommended practice for SharePoint 2010 and the only option for SharePoint 2013), do the following:
- Add the service account that runs the SharePoint Central Administration service to enable SharePoint to be configured from its administrator console.
- Add the account that is configured for the SharePoint App Pool.
File Servers with 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.
Choose the role you’d like to configure
Choose the appropriate group or computer object based on the previous table above
Check for updates here
You should now see your server listed
See my follow-up blog for further Connector configuration for Exchange, SharePoint & File Servers!