I came across this issue the other day, so thought I would add it to my blog. We were trying to get Azure Information Protection operating in a client, and all we could see when checking the download of the templates in File > Info inside an Office application was the following:
The sequence of events was File > Info, click Set Permissions. You get the “Connect to Rights Management Servers and get templates” menu item. Clicking this shows a box saying “Retrieving templates from server” (which you might not see as this step takes no real time at all) and then an error that reads “Your machine isn’t set up for Information Rights Management (IRM). To set up IRM, sign into Office, open and existing IRM protected message or document, or contact your helodesk”.
For each of these recommendations, we tried them and still got the same message.
So what was the issue?
In https://docs.microsoft.com/en-us/azure/information-protection/get-started/requirements#firewalls-and-network-infrastructure Microsoft state the the IRM client in Windows uses Certificate Pinning. This is where the client application knows what certificate it expects to see at the service it is connecting to. If it gets a different certificate it will fail to connect. Within enterprise organizations, firewalls and proxy devices that do SSL Inspection change the certificate in use so that they can see the content being sent to the service in the clear. For the IRM client in Windows, this means that IRM does not trust the certificate and so will not work.
You can test for SSL Inspection on a URL by browsing the target URL in Chrome. For example, for IRM go to https://admin.na.aadrm.com/admin/admin.svc and click the Secure banner in the address bar:
You will get a popup – hover over the “Certificate (Valid)” message. If the certificate is not valid then either your PC is missing some important updates or SSL inspection is happening, but not implemented correctly!
You can use this same test to check for SSL Inspection on any network.
The certificate listed when you hover over the “Certificate (Valid)” message should read (for AIP) a Microsoft CA issued certificate. It should not list your company or proxy service as the issuer. Do not terminate the TLS client-to-service connections (for example, to do packet-level inspection) to the Azure Rights Management service. Doing so breaks the certificate pinning that RMS clients use with Microsoft-managed CAs to help secure their communication with the Azure Rights Management service.
For network performance, Microsoft also have a list of URLs that they recommend you do not inspect for Office 365 services. This list of endpoints that should not be inspected are those categorised as Optimize or Allowed when you browse
https://endpoints.office.com/endpoints/O365Worldwide?ClientRequestId=GUID. Interestingly at the time of writing this lists aadrm.com as Default, which means it can be inspected – I have reported this to the team that manages the endpoint service so that this URL can be moved up in its classification.
Once you bypass SSL Inspection for *.aadrm.com you will find that the Office and RMS clients work fine (assuming everything else is enabled correctly of course).
Leave a Reply