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.

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

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

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).