AD RMS and Server Design
Applies To: Windows Server 2008, Windows Server 2008 R2
The following sections describe various server considerations that need to be taken into account when developing an AD RMS design. These may or may not all apply to your organization or the environment on which you are working.
To better delegate control of your AD RMS environment, new administrative roles have been created. These administrative roles are local security groups that are created when the AD RMS role is installed. Each of these administrative roles has different levels of access to AD RMS associated with them.
The new AD RMS administrative roles give you the opportunity to delegate AD RMS tasks without giving full administrative control over the entire AD RMS cluster. It is recommended to create Active Directory security groups for each of these administrative roles and add them to their respective local security groups. This will give you the ability to scale your AD RMS deployment across several servers without having to add specific user accounts to each AD RMS server.
The new local security groups are:
Active Directory Rights Management Services Enterprise Administrators. The AD RMS Enterprise Administrators role allows members of this group to manage all AD RMS policies and settings. During AD RMS provisioning, the user account installing the AD RMS server role is added to the AD RMS Enterprise Administrators role. As a best practice, membership of this group should be restricted to only user accounts that need full AD RMS administrative control.
Active Directory Rights Management Services Template Administrators. The AD RMS Templates Administrators role allows members of this group to manage rights policy templates. Specifically, AD RMS Template Administrators can read cluster information, list rights policy templates, create new rights policy templates, modify existing rights policy template, and export rights policy templates.
Active Directory Rights Management Services Auditors. The AD RMS Auditors role allows members of this group to manage logs and reports. This is a read-only role that is restricted to read cluster information, read logging settings, and run reports available on the AD RMS cluster.
Cross-Boundary Collaboration Considerations
AD RMS can extend its services to other organizations or forests. AD RMS manages multi-forest scenarios using trust policies settings. You can add trust policies so that AD RMS can process licensing requests for content that was rights-protected by a different AD RMS cluster. You can define the following trust policies:
Windows Live ID. Setting up a trust relationship with the Microsoft online RMS Service allows an AD RMS user to send rights-protected content to a user with a Windows Live ID. The Windows Live ID user will be able to consume rights-protected content from the AD RMS cluster that has trusted Windows Live ID, but the Windows Live ID user will not be able to create content that is rights-protected by the AD RMS cluster.
Trusted user domains (TUD). The addition of a trusted user domain allows the AD RMS certification cluster to process requests for client licensor certificates or use licenses from users whose rights account certificates (RACs) were issued by a different AD RMS certification cluster. You add a trusted user domain by importing the server licensor certificate of the AD RMS cluster to trust.
Trusted publishing domains (TPD). The addition of a trusted publishing domain allows one AD RMS cluster to issue use licenses against publishing licenses that were issued by a different AD RMS cluster. You add a trusted publishing domain by importing the server licensor certificate and private key of the server to trust.
Active Directory Rights Management Services with ADFS. Establishing a federated trust between two forests is done by using Active Directory Federation Services. This can also be useful if one forest does not have AD RMS installed, but its users need to consume rights-protected content from another forest. This is the recommended connection method between two partners running Windows Server 2008 or later.
Trusted User Domains (TUD)
By default, AD RMS does not service requests from users whose RACs were issued by a different AD RMS installation. In some situations, this may become necessary. The following are examples in which you require this.
One organization may have multiple forests and therefore may have multiple AD RMS installations. Each AD RMS installation may be configured to trust the other AD RMS installations in the organization by establishing one another as trusted user domains.
Two companies may want to establish each other as trusted user domains in order to publish AD RMS-protected content for one another.
An organization may want to use RMS to protect content for an external user who does not have access to an AD RMS system. In this case, a third party, such as Windows Live ID, is required by the external user.
A trusted user domain is an entity that has its own AD RMS installation. That entity can be another forest in your organization or perhaps a partner’s AD RMS installation. Trusted user domains allow users from that domain to request a use license from your licensing servers.
To allow these scenarios, AD RMS domains can be added to the list of trusted user domains, which allows AD RMS to process such requests. For each trusted domain, you can also add and remove specific users or groups of users. certification
You can manage trusted user domains as follows:
Using Windows Live ID . To support external users, you can add the Microsoft online RMS service to the list of trusted domains. This allows an AD RMS server that is in your company to process licensing requests received with a RAC that was issued by the Windows Live ID service. This option is not recommended for business-to-business scenarios, but is useful for business-to-consumer scenarios.
Managing External Users. To trust external users from another organization's AD RMS installation, you can add the organization to the list of trusted user domains. This allows servers in an AD RMS cluster to process a licensing request that includes a RAC that was issued by an AD RMS cluster in the other organization.
Managing Internal Users who are members of different forests. In the same manner, to process licensing requests from users within your own organization who reside in a different Active Directory forest, you can add the AD RMS installation in that forest to the list of trusted user domains. This allows servers in an AD RMS cluster that is in the current forest to process a licensing request that includes an RAC that was issued by an AD RMS cluster in the other forest.
To add an AD RMS installation to the list of trusted user domains, you must import the TUD for the AD RMS installation that you want to add. The administrator must first export the TUD .bin file from the server or cluster to trust and send the certificate file to you. For additional information on adding and removing trusted user domains see Adding and Removing Trusted User Domains (http://go.microsoft.com/fwlink/?LinkId=155018).
After defining a trusted user domain, you should specify which e-mail domains are trusted. It is an important security step to configure e-mail domains; otherwise it would be possible for a user from a trusted user domain to impersonate an internal user. It is highly recommended that local e-mail domains be excluded from trusted user domains.
Please remember that an AD RMS Trust does not require a Windows Forest Trust or connectivity between AD RMS domains. Also, it is unidirectional (one-way), so if you need to establish a bi-directional trust you must install each companies TUD file in the others organization. That is, if Contoso and Fabrikam want to setup a Trusted User Domain bi-directionally between each other, Contoso will have to import Fabrikam’s TUD file into their AD RMS and Fabrikam will have to import Contoso’s TUD file. Also, without a forest trust, the benefit of group expansion will not be available.
Remember that there are Windows Integrated Authentication constraints placed on the licensing pipeline within IIS. In order for a user from another domain to be able to request a use license, the user must be able to authenticate to your server running IIS. This can be accomplished in several ways such as enabling anonymous authentication, establishing a Windows trust relationship with the other forest, or using a dummy account for authentication.
For additional information including how to setup a TUD step-by-step see AD RMS Deployment in a Multiple Forest Environment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=154940).
The following is an example of how a trusted user domain works:
Contoso exports and sends its TUD to Fabrikam.
Fabrikam imports the TUD .bin file it receives from Contoso.
Alice@Fabrikam.com sends Bob@Contoso.com an item of RMS-protected content.
Bob receives the content and in his attempt to consume it, sends his RAC and the publishing license to the issuing Licensing Server at Fabrikam.
The Licensing Server at Fabrikam is aware that Contoso’s domain is a trusted user domain and can use the imported TUD to verify Bob’s RAC and issue him a use license.
For additional information on Trusted User Domains see AD RMS TUD Business-to-Business Requirements (http://go.microsoft.com/fwlink/?LinkId=154924) and Add a Trusted User Domain (http://go.microsoft.com/fwlink/?LinkId=154925).
Trusted Publishing Domains (TPD)
By default, an AD RMS Licensing Server can issue use licenses for only content where it originally issued the publishing license. It some situations, this may not be acceptable. The following are examples of when this may be less than desirable.
In the event when one cluster running AD RMS is to be retired, users may still want to access previously protected content that was issued a publishing license by that computer. Servers in other clusters can then add the to-be-retired server as a trusted publishing domain.
One company acquires another company.
In order to specify a cluster that is allowed to issue use licenses for content protected by a different cluster, the first cluster must be defined as a trusted publishing domain. If content was published by another certification cluster either in your organization, for example, a subsidiary organization in another forest, or in a separate organization, your AD RMS cluster can grant use licenses to users for this content by configuring a Trusted Publishing Domain on your AD RMS cluster. By adding a Trusted Publishing Domain, you set up a trust relationship between your AD RMS cluster and the other certification cluster by importing the Trusted Publishing Certificate of the other cluster..
This scenario is commonly used when a company acquires another company that already has an AD RMS implementation in place. With this feature, you can centralize all EUL and CLC issuances to a single point, rather than via the acquired AD RMS forest or forests.
To add a Trusted Publishing Domain, you must import the Trusted Publishing Certificate, the private key (if the private key is stored in software rather than in an HSM), and all the rights policy templates for the AD RMS server or cluster that you want to add. The administrator must first export these items from the cluster to a password-protected XML file, and then specify the password that is required to decrypt it. You can then import the file into the new AD RMS cluster. You will need to know the password that the administrator specified on the XML file prior to importing it. For example, the administrator in Fabrikam would export the information to an XML file. He would then give this file and the password to the administrator in Contoso. The Contoso administrator would then import the XML file into his AD RMS cluster.
If the private key is stored in an HSM, you must transfer the private key to the HSM on the trusted server by following the instructions in the HSM documentation. Depending on the type of HSM that is on each server and the configuration of the HSM devices, you may not be able to transfer the private key from one HSM to another. Review the HSM documentation to determine whether you can transfer the private key without losing data in the destination HSM. If you cannot successfully transfer the private key, you cannot establish a Trusted Publishing Domain between the two servers.
If you are using an HSM to protect your AD RMS private key and are importing an Trusted Publishing Certificate from an AD RMS installation that uses software-based private key protection, you must specify a private key password on the Security settings page of each AD RMS server in the cluster before you attempt to import the certificate.
You can remove a Trusted Publishing Domain that you added at any time by removing its certificate from the list of certificates for Trusted Publishing Domains.
Remember that DNS records may have to be modified so that the URL in the publishing licenses of content created in the trusted publishing domain resolves to an IP for the licensing server of AD RMS installation that setup the trusted publishing domain.
The following is an example of how a trusted publishing domain works:
Fabrikam exports and sends the XML file and the password to Contoso.
Contoso provides the password and imports the XML file..
Alice@Fabrikam.com sends Bob@Contoso.com an item of RMS-protected content.
Bob receives the content and sends his RAC and the publishing license to the issuing Licensing Server at Contoso.
The Licensing Server at Contoso can decrypt the publishing license issued by Fabrikam and confirms that Bob is a named principal in the publishing license. It then issues the use license to Bob.
For additional information on Trusted Publishing Domains see AD RMS Trusted Publishing Domain Considerations (http://go.microsoft.com/fwlink/?LinkId=154926) and Add a Trusted Publishing Domain (http://go.microsoft.com/fwlink/?LinkId=154927).
Federated Identity using Active Directory Rights Management Services ADFS
Increasingly, enterprises are feeling the need to collaborate outside their enterprise boundaries and are looking at federation as a solution. Supporting federation in AD RMS will allow enterprises to leverage their established federated relationships to enable collaboration with external entities.
In Windows Server 2008 AD RMS rights can be assigned to users who have federated trust via Windows Active Directory Federation Services. This will enable an organization to share access to rights-protected content with another organization without having to establish a separate trust or AD RMS infrastructure.
AD RMS will support issuing certificates and licenses to users who authenticate using ADFS. AD RMS will do so without breaking existing functionality except for group expansion. For additional information see Group Expansion for Federated Users (http://go.microsoft.com/fwlink/?LinkId=155023).
ADFS uses terms such as "account partner" and "resource partner" to help differentiate the organization that hosts the accounts (the account partner) from the organization that hosts the Web-based resources (the resource partner). The term "federation trust" is used in ADFS to characterize the one-way, non-transitive relationship that is established between the account partner and the resource partner
For additional information on AD RMS and AD FS see AD RMS and AD FS Considerations (http://go.microsoft.com/fwlink/?LinkId=154929) and theAD RMS with AD FS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=153618).
Additional Components for Multi-forest Environments
This section briefly describes the additional components for multi-forest environments. These components are:
Identity Lifecycle Manager 2007 Feature Pack 1. ILM 2007 FP1 is a stand-alone product that is designed to synchronize identity information. It can be used to synchronize GALs between companies Active Directory directories.
IIS and SSL. Most traffic between clients and AD RMS Servers are encrypted, but, if you want to prevent spoofing and completely encrypt transmissions, an SSL certificate should be installed on the AD RMS cluster. This is particularly important when Extranet/Internet access should be defined because of the Basic Authentication requirement on AD RMS clusters. SSL can be used to protect both Intranet and Extranet pipelines.
IIS 7.0 can have a single Certificate per Website - Because IIS 7.0 supports only one certificate per Website, you should use SSL Bridging technologies in the firewall/gateway, such as ISA Server 2006/2004, in front of the AD RMS installation.
For additional information on AD RMS and multi-forest environments seeUnderstanding AD RMS Across Forests (http://go.microsoft.com/fwlink/?LinkID=153538), AD RMS Multi Forest Considerations (http://go.microsoft.com/fwlink/?LinkId=154930), Checkist AD RMS Multi Forest (http://go.microsoft.com/fwlink/?LinkID=153541), and AD RMS Deployment in a Multiple Forest Environment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154940)..
For additional information on licensing-only clusters see AD RMS Licensing-only Cluster Deployment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=155064).
AD RMS Service Discovery
AD RMS uses the concept of service connection point to allow users to automatically locate the AD RMS certification server cluster. The service connection point (SCP) for AD RMS identifies the connection URL for the service to the AD RMS-enabled clients in your organization. The SCP is registered in Active Directory Domain Services (AD DS), and allows clients to discover the AD RMS cluster to request use licenses, publishing licenses, or rights account certificates (RACs).
Because several AD RMS architecture scenarios exist, as do several applications that use AD RMS in many different configurations, Microsoft provides different options to configure/override AD RMS default settings to provide information about the Certification cluster, licensing-only cluster, and other client specific parameters.
If you want clients to discover an AD RMS certification cluster without using Active Directory or the SCP you can use the following registry keys on the clients. This may be useful in situations where you want to test AD RMS but do not want to modify Active Directory.
CorpLicenseServer: Typically Active Directory is used to specify the AD RMS Licensing server used for issuing use licenses. This setting allows you to override the location of the AD RMS cluster specified in Active Directory for certification. Can be used when auto-discovery is not available, such as when users do not work inside a LAN with connectivity to Active Directory, or when using Trusted Publishing Domains to override the license servers that issued publishing licenses. If present, takes precedence over the settings under MSDRM registry branch for Office applications.
HKLM\Software\Microsoft\Office\12.0\Common\DRM\ REG_SZ: default Value: < http(or https)://RMS_Cluster_Name /_wmcs/Licensing>
CorpCertificationServer: Typically Active Directory is used to specify the AD RMS Certification server used for bootstrapping. This setting allows you to override the location of the AD RMS cluster specified in Active Directory for certification. Can be used when auto-discovery is not available, such as when users do not work inside a LAN with connectivity to Active Directory. If present, takes precedence over the settings under MSDRM registry branch for Office applications.
HKLM\Software\Microsoft\Office\12.0\Common\DRM\ REG_SZ: default Value: <http(or https)://RMS_Cluster_Name/_wmcs/Certification>
Activation: This registry key defines the URL of the user activation service
HKLM\Software\Microsoft\MSDRM\ServiceLocation\Activation REG_SZ: default Value: <http(or https)://RMS_Cluster_Name/_wmcs/Certification>
EnterprisePublishing: This registry key defines the URL of an RMS installation that you want this client to use for license requests.
HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing REG_SZ: default Value: < http(or https)://RMS_Cluster_Name /_wmcs/Licensing>
The CorpLicenseServer and EnterprisePublishing keys can be used even if you do have an SCP registered, if you want your clients to use a different licensing server.
For additional information on AD RMS service discovery see AD RMS Client Service Discovery (http://go.microsoft.com/fwlink/?LinkId=154932) and Register a Service Connection Point (http://go.microsoft.com/fwlink/?LinkId=154934).
Publishing AD RMS to the Internet
Extranet Access scenarios may require the AD RMS to be available on the Internet for external user access. For some organizations, the AD RMS cluster availability using the Internet/Extranet access is a mission-critical service required. Therefore, it is crucial that you provide your customers with stable and reliable AD RMS published services.
For additional information on deploying AD RMS in an extranet see (Add an Extranet Cluster URL (http://go.microsoft.com/fwlink/?LinkId=154935), Checklist: Deploying AD RMS in an Extranet (http://go.microsoft.com/fwlink/?LinkId=154936), and AD RMS Deployment in an Extranet Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154938).