Working with Microsoft Information Protection (MIP) deployment across organizations requires a well-thought-out strategy and following certain best practices. MIP leverages Azure RMS service to manage permission and policies through encryption settings which all user devices must communicate when MIP encrypted documents are touched. Microsoft has published a list of IP Addresses and URLs that must be allowed by the organization’s security control to avoid any service interruptions.
One of our global customers in the semiconductor manufacturing space was looking to tighten its internal security posture and wanted to employ SSL inspection strategies to safeguard the flow of information. One such strategy is to limit or block TLS (Transport Layer Security) client-to-service connections by performing packet inspection. Enacting this policy, however, resulted in some undesirable behavior with MIP.
The symptoms of a blocked connection:
- Inability to open Office files encrypted with MIP (Microsoft Information Protection) – created by others or you, using the desktop Microsoft 365 apps
- Inability to open PDF and other non-Office files encrypted with MIP
The innovative solution Netwoven offered
Netwoven diagnosed that if the users can open encrypted files on the web using Office Online but are unable to open the very same files when downloaded as a local copy, usually indicating that there could be a connectivity issue from end point devices prohibiting connectivity with RMS service, responsible for allowing permission to open encrypted documents. Usual troubleshooting steps would indicate looking at the end point devices’ firewall settings or endpoint protection settings blocking communication.
MIP clients (RMS clients) need to communicate with the Azure RMS service via aadrm.com. This connection must remain open for RMS clients such as Microsoft Office, and the unified labeling clients to successfully decrypt files. Our experts team recommended to the customer to use the following PowerShell commands to inspect if the connection to the RMS service was being blocked:
$request = [System.Net.HttpWebRequest]::Create(“https://admin.na.aadrm.com/admin/admin.svc”)
The result showed that the issuing CA (Certificate Authority) is from Microsoft CA
If the CA name is not from Microsoft, it is likely that the customer’s network security is prohibiting or blocking traffic to aadrm.com
The Corporate firewall security policy was updated to whitelist the domain aadrm.com and allow traffic without packet inspection.
By implementing this fix, the customer avoided a major MIP outage that would have had adverse effects on the organization’s productivity and security.
We hope you found this blog useful in understanding the innovative solutions Netwoven adopts to shore up your security posture. Please reach out to us so that we can put our decades of experience and expertise in security & compliance services and Microsoft technologies to help you in your organization’s Digital Transformation journey.