AD RMS and AD FS Considerations

Applies To: Windows Server 2008, Windows Server 2008 R2

In AD RMS rights can be assigned to users who have a federated trust with Active Directory Federation Services (AD FS). This enables an organization to share access to rights-protected content with another organization without having to establish a separate Active Directory trust or Active Directory Rights Management Services (AD RMS) infrastructure.

Federated identity support allows user accounts to use credentials established by a federated trust relationship through AD FS as a basis for obtaining a rights account certificate (RAC) from an AD RMS cluster. This is an alternative to setting up trusted publishing domains or trusted user domains between entities that have previously established trust infrastructures, such that in most cases the cluster is supporting both users that are inside of the organization and users from a partner organization.

When rights account certificates (RACs) are issued from a federated identity, the standard rights account certificate validity period does not apply. Instead, the RAC validity period is specified in the Federated Identity Support setting. Users with federated identities do not use temporary rights account certificates.

By default, federated trust relationships are not transitive. When a federated trust relationship is established between two organizations, any AD RMS trusted user domains that are established in either organization are not automatically trusted by the other organization. However, when you are importing a trusted user domain, there is an option to trust federated users of the imported domain.

Great care should be taken when allowing proxy addresses through a federated trust. If proxy addresses through federation are allowed, it is possible for a malicious user to spoof an authorized user's credentials and access the user's rights-protected content. If proxy addresses through federation is a requirement of your organization, you should implement a claims transformation module that will examine a proxy address from a federated user and make sure that it matches the forest in which the request originated. The option to allow a proxy address from a federated user is turned off by default in the AD RMS console.

Prior to setting up AD RMS and AD FS, there are some requirements that must be met. The remainder of this document will describe these requirements.

AD RMS with AD FS Requirements

The following table describes the architectural requirements for deploying AD RMS with AD FS.

Solution Component	Intranet Requirements	Extranet Party Requirements
Active Directory Domain Services	Windows 2000 SP4 or later Schema expansion not required No specific forest or domain level mode required.	Windows 2000 SP4 or later Schema expansion not required No specific forest or domain Level mode required
Active Directory Rights Management Services Server Components	Active Directory Rights Management Services Server (Windows Server 2008)	Not Supported
AD FS Requirements	AD FS installed (FS-R) This server could be Windows 2003 R2 Datacenter Edition or Windows 2003 R2 Enterprise Edition EE/DE or Windows Server 2008	AD FS installed (FS-A) This server could be Windows 2003 R2 Datacenter Edition or Windows 2003 R2 Enterprise Edition or Windows Server 2008
ISA Server 2006 (Optional)	Integrated Edge Security Gateway with ISA Server Firewall Web Publication and SSL Bridging capabilities.	Not Required
HSM (Optional)	HSM or Active Directory Rights Management Services Key Storage.	Not Required
SSL Digital Certificates	Required for AD RMS and AD FS	Required for AD FS
Token Signing Certificates	Required for AD FS	Required for AD FS

The following table provides information regarding the pipelines for AD RMS and AD FS. You should note that there are 4 potential different pipelines for AD RMS and AD FS integrations.

AD RMS and AD FS Pipeline Considerations

Pipeline	Description
SSL Usage	AD FS – required for all pipelines AD RMS – required for extranet pipeline.
FQDN	Use FQDN for all AD FS and AD RMS pipelines.
Virtual names	Always use virtual names for each component installed (RMS, AD FS, SQL).
Single AD RMS Pipeline	Validate that can be resolved either from the intranet or Internet. May require DNS change. Example: https://rms.contoso.com
Different AD RMS Pipelines	IIS 7 supports multiple SSL certificates in the same web site Additional IP address will be required, one for each SSL certificate. Example 1: https://rms.contoso.local Example 2: https://rms.contoso.com
AD FS Pipelines	SSL required for pipelines Example 1: AD FS(R): https://adfs.contoso.com Example 2: AD FS(A) https://adfs.fabrikam.com
Pipeline validation	Before continuing validate that pipelines can be reached.

For the AD RMS clients, additional settings are required to make AD RMS and AD FS work. For an Internet Explorer trust in an Internet Explorer zone, you should use GPOs to configure the settings. All pipelines (AD RMS and AD FS) should be added to the Intranet local zone. If internal certification authority is used, you should configure the root CA in the Trusted Root Certification Authorities settings.

AD RMS Client Settings with AD FS

Internet Explorer zone and CA Configuration	Details
Configure Internet Explorer trust in all clients	<GPO>\User Configuration\Windows Settings\Internet Explorer Maintenance\Security Zones and Content Ratings All pipelines described above.
Configure Trust in Root CAs (optional)	<GPO>\Computer Configuration\Windows Settings\Security Settings\Public Key Policies\ Trusted Root Certification Authorities All Root CAs that you want to have trusted.

You will require digital certificates for SSL based pipelines (AD RMS and AD FS) and token signing certificate (AD FS). Although you see the self-signed certificate option, it is highly recommended not to use the certificate in a production environment.

For certificate trusts, it is required to trust all CAs that issue the corresponding SSL and token signing certificates. You can use third party certificates for this purpose. If you use internal CAs to issue the certificates, you need to configure root CA trusts using GPOs and validate you can access the sites without any prompts for digital certificates

CDP/CRL will be used to check the validity of the certificates, so CRL files should be available. You should validate all certificates using the certutil command. For more information see Basic CRL Checking with certutil (https://go.microsoft.com/fwlink/?LinkId=153619).

You should separate the SSL certificate and token signing certificate. For the SSL certificate, you should use FQDN in the common name of the Subject field to match with the published site. Otherwise, you will get a warning. For token signing certificate, no Key Usage fields are required.

For information on setting up AD RMS and AD FS see: AD RMS with AD FS Identity Federation Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkId=153618).

For additional design information regarding AD RMS and AD FS see: Secure Collaboration Using Federated Active Directory Rights Management Services with Microsoft Office SharePoint Services 2007 (https://go.microsoft.com/fwlink/?LinkId=153625).