A. For an internal RMS implementation, content is protected, in part, by user accounts, so that external users normally cannot access the content. RMS requests use Simple Object Access Protocol (SOAP). SOAP operates over HTTP (port 80) or HTTP Secure (HTTPS, port 443), which means that only these ports need to be opened on the firewall and routed to the RMS server. For additional security, you can place in the DMZ a firewall with Microsoft Internet Security and Acceleration (ISA) Server, which then forwards the packets to the DMZ in the internal network and can optionally strip out the Secure Sockets Layer (SSL) encryption. Two URLs are configured for RMS: an internal URL and an external URL. The external URL allows RMS clients to obtain use licenses to view protected content. (For more in-depth information about RMS, see “Windows Rights Management Services.”)
The following four options are available to enable external parties to consume RMS-protected content:
RMS trust relationship. If you have a partner organization that will regularly consume protected content, that organization can implement RMS internally, then set up an RMS trust with the internal RMS implementation, in which partner organizations exchange RMS server licensor certificates (the public keys). This RMS trust relationship will let an external organization automatically consume protected content. Note that even if the other organization has RMS, you still require CALs or the External Connector (EC) license for their users to view protected content generated by your organization.
Windows Live ID. The external organization can use Windows Live IDs to access your organization’s RMS protected content if the RMS implementation is configured to trust the Windows Live ID source. Once Windows Live ID is enabled, users can request access to protected content by sending a request with their Live ID. Additionally, creators of protected content can enter the Live ID of an external user and grant the user access.
Internal accounts in a forest. External users can have accounts created in the internal AD domain specifying their external email address. Be aware that such AD accounts are a potential security risk, so IT will need to ensure that they have access only to the resources the organization deems they should access. Additionally, if external users needed to create RMS-protected content, they’d need to VPN to the internal network to access the internal URL of the RMS server.
Accounts in a DMZ forest. As an alternative to creating accounts in the internal domain for external users, you could create a separate forest with its own RMS infrastructure in the demilitarized zone (DMZ) and establish an RMS trust relationship between the DMZ and internal RMS implementations. You could then grant permissions to users in the DMZ forest.
