Checklist: Deploying Microsoft Federation Gateway Support

Updated: February 15, 2011

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 with SP1

The following steps in this checklist describe the tasks required to install and configure Microsoft Federation Gateway Support on an Active Directory Rights Management Services (AD RMS) cluster. For more information about Microsoft Federation Gateway, see Microsoft Federation Gateway Support Overview.

  1. If you have not already done so, on each server in the cluster assign a secure sockets layer (SSL) certificate to the Web site that is hosting the AD RMS cluster and configure the cluster to use SSL-encrypted connections. The certificate must be from a certification authority that is trusted by the Microsoft Federation Gateway. For more information, see Important considerations for installing AD RMS Microsoft Federation Gateway Support.

  2. If you have rights policy templates that grant user rights to Anyone, you should consider modifying them to prevent granting rights to external users who are authenticated through the Microsoft Federation Gateway. For information on changing a rights policy template, see Edit a Rights Policy Template.

  3. In order to ensure that you can recover your AD RMS cluster in case of a problem, you should back up your AD RMS databases. The AD RMS databases have names that begin with the DRMS_ prefix. The method and procedure you use to back up the databases will depend on the server on which they are stored and the procedure that you typically follow to back up the server databases.

  4. On each server of the AD RMS cluster, install Service Pack 1 for Windows Server® 2008 R2 and then add Microsoft Federation Gateway Support to each server in the cluster by following the instructions in Adding Microsoft Federation Gateway Support.

  5. On one server in the AD RMS cluster, enroll the cluster with the Microsoft Federation Gateway and then enable Microsoft Federation Gateway Support by following the instructions in Enrolling and Enabling Microsoft Federation Gateway Support.

CautionCaution
Before uninstalling Service Pack 1 for Windows Server® 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster. For more information, see Removing Microsoft Federation Gateway Support.

The following is a list of things that should be considered before you install AD RMS with Microsoft Federation Gateway:

  • The AD RMS cluster must be configured to use an SSL-encrypted connection that uses a certificate that the Microsoft Federation Gateway trusts. To prove your ownership of the domain that you want to federate with the Microsoft Federation Gateway, you must own the X.509 SSL certificate for that domain. It must be from one of the trusted root certification authorities (CAs) that are configured in the Microsoft Federation Gateway. The following table lists those CAs.

     

    CA certificate friendly name

    Issued to

    Intended purposes

    Entrust (http://go.microsoft.com/fwlink/?LinkId=162663)

    Entrust.net Secure Server Certification Authority

    Server authentication, client authentication, code signing, secure messaging, IP security tunnel termination, Internet Protocol security (IPsec) user, Internet Protocol security (IPsec) Internet Key Exchange (IKE) intermediate, time stamping, file-system encryption

    Go Daddy Class 2 Certification Authority (http://go.microsoft.com/fwlink/?LinkId=162664)

    Go Daddy Class 2 Certification Authority

    Server authentication, client authentication, secure messaging, code signing

    Network Solutions (http://go.microsoft.com/fwlink/?LinkId=162665)

    Network Solutions Certificate Authority

    Server authentication, client authentication, secure messaging, code signing, time stamping

    VeriSign Class 3 Public Primary CA (http://go.microsoft.com/fwlink/?LinkId=162667)

    Class 3 Public Primary Certification Authority

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    Class 3 Public Primary Certification Authority

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    VeriSign Trust Network

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    VeriSign Class 3 Public Primary Certification Authority - G5

    Server authentication, client authentication, secure messaging, code signing

  • The SSL certificate that you use to enroll with the Microsoft Federation Gateway must be a certificate that shows ownership of the AD RMS cluster's extranet URL. If the AD RMS cluster is configured with an intranet URL that is different from the extranet URL and if the intranet URL is not a domain name that can be accessed from the Internet, you must install the SSL certificate associated with the extranet URL on this AD RMS server and then select that certificate when enrolling with the Microsoft Federation Gateway.

  • If the SSL certificate contains a subject alternate name (SAN), the last entry in the SAN list must be the fully qualified domain name of the domain you want to enroll with the Microsoft Federation Gateway.

  • To avoid conflicts, you should not enroll your AD RMS cluster with the Microsoft Federation Gateway by using the same URL that has been used to federate another resource with the Microsoft Federation Gateway. Other federated relationships to the Microsoft Federation Gateway can include (but are not limited to) federations to Microsoft Online and Microsoft Exchange Server. If you have already used the URL that your AD RMS cluster uses as its external URL to federate with the Microsoft Federation Gateway for another purpose, you must enroll the AD RMS cluster with the Microsoft Federation Gateway by creating and using a certificate that contains the AD RMS URL as the last entry in the SAN and with a common name (CN) that is not the same as the registered resource. For example, if the DNS name of your AD RMS server is resource.contoso.com, and if that name has already been used by another resource that has been federated to the Microsoft Federation Gateway, you can create a certificate in the following format to avoid federation conflicts:

    Subject: CN=adrmsservice.contoso.com
          SAN:
                 DNS Name=adrmsservice.contoso.com
                 DNS Name=resource.contoso.com
    
  • The virtual directories that are created for use by Microsoft Federation Gateway Support use http://. Because of this, your firewall must be configured to enable http:// data to pass through. Note, however, that the http:// transactions for Microsoft Federation Gateway Support use message-level security.

Community Additions

ADD
Show: