Configuring AD FS 2.0

Using Metadata to Add Claims Provider

Use the metadata import capabilities of AD FS 2.0 to create the Example.com claims provider. The metadata includes the public key that is used to validate security tokens signed by Access Manager.

Using Metadata to Add a Relying Party

  1. In AD FS 2.0, in the console tree, right-click the Claims Provider Trusts folder, then click Add Claims Provider Trust to start the Add Claims Provider Trust Wizard.

  2. Click Start.

  3. On the Select Data Source page, select Import data about the claims provider from a file.

  4. In the Federation metadata file location field, click Browse.

  5. Navigate to the location where you saved nam_metadata.xml, click Open, then click Next.

  6. On the Specify Display Name page, type NAM Example.

  7. Click Next > Next > Close.

Editing Claim Rules for the Claims Provider Trust

The following claim rule describes how the data from Access Manager is used in the security token that is sent to the WIF sample application or SharePoint 2010.

  1. In AD FS 2.0, click Relying Party Trusts, right click WIF Sample App, and click Edit Claim Rules.

    or

    In the AD FS 2.0 center pane, under Claims Provider Trusts, right-click NAM Example, and click Edit Claim Rules.

  2. On the Acceptance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, select Pass Through or Filter an Incoming Claim.

  4. Click Next.

  5. On the Configure Claim Rule page, use the following values:

    Name

    Value

    Claim rule name

    Name ID Rule

    Incoming claim type

    Name ID

    Incoming name ID format

    Unspecified

  6. Select Pass through all claim values and click Finish.

  7. Click Add Rule.

  8. On the Select Rule Template page, select Pass Through or Filter an Incoming Claim > Next.

  9. On the Configure Claim Rule page, under Claim rule name, specify the following values:

    Name

    Value

    Claim rule name

    Name Rule

    Incoming claim type

    Name

  10. Keep Pass through all claim values selected and click Finish.

  11. To acknowledge the security warning, click Yes.

  12. Click OK.

  13. Click Add Rule.

  14. On the Select Rule Template page, select Pass Through or Filter an Incoming Claim, and click Next.

  15. On the Configure Claim Rule page, specify the following values under Claim rule name:

    Name

    Value

    Claim rule name

    Email Rule

    Incoming claim type

    E-Mail Address

  16. Keep Pass through all claim values selected and click Finish.

  17. To acknowledge the security warning, click Yes.

  18. Click OK.

Editing Claim Rules for the WIF Sample Application

At this point, incoming claims have been received at AD FS 2.0, but rules that describe what to send to the WIF sample application have not yet been created. You need to edit the existing claim rules for the sample application to take into account the new Access Manager external claims provider.

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click WIF Sample App, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name Rule

    Incoming claim type

    Name

  6. Keep Pass through all claim values selected, then click Finish.

  7. On the Issuance Transform Rules tab, click Add Rule.

  8. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  9. On the Configure Claim Rule page, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Unspecified

  10. Keep Pass through all claim values selected, then click Finish.

  11. Click OK.

NOTE:If you changed the rules while federating AD FS 2.0 with the WIF sample application, ensure that you add the Permit All Users issuance rules back to the WIF sample application. See Step 6: – Change Rules in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide.

Or, as an alternative, add a new Permit or Deny Users Based on an Incoming Claim rule allowing incoming Name ID = john@example.com to access the application.

Editing Claim Rules for the SharePoint 2010 Application

At this point, incoming claims have been received at AD FS 2.0, but the rules that describe what to be sent to the SharePoint 2010 application have not yet been created. You need to edit the existing claim rules for the SharePoint 2010 application, which is added as relying party to ADFS 2.0, to configure the new Access Manager external claims provider.

Editing the Claim Rules for the SharePoint 2010 Application

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click SP2010, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, specify the following values:

    Name

    Value

    Claim rule name

    Pass eMail Rule

    Incoming claim type

    Email Address

  6. Leave the Pass through all claim values option selected and click Finish.

Using Certificates and Certificate Revocation Lists

For security reasons, production federation deployments require the use of digitally signed security tokens, and optionally allows encryption of the security token contents. Self-signed private key certificates, which are generated from inside the AD FS 2.0 and Access Manager products, are used for signing security tokens.As an alternative, organizations can use a private key certificate that is issued by a certificate authority (CA) for signing and encryption. The primary benefit of using CA-issued certificates is the ability to check for possible certificate revocation against the certificate revocation list (CRL) from the issuing CA.

Also, to avoid the untrusted certificate messages in browsers, the trusted root certificate of the CA must also be imported into your browsers. Many well-known CA's trusted roots are included with common browsers. Using one of these existing CAs to mint your certificates also prevents the untrusted certificate messages.

In AD FS 2.0 and in Access Manager, CRL checking is enabled by default for all partner connections, if the certificate being used by the partner includes a CRL Distribution Point (CDP) extension.

This has implications in federation deployments between Access Manager and AD FS 2.0:

  • If a signing/encryption certificate provided by one side of a federation includes a CDP extension, that location must be accessible by the other side's federation server. Otherwise, CRL checking fails, resulting in a failed access attempt. The CDP extensions are added by default to certificates that are issued by Active Directory Certificate Services (AD CS) in Windows Server 2012.

  • If the signing/encryption certificate does not include a CDP extension, no CRL checking is performed by AD FS 2.0 or Access Manager.

Disabling CRL Checking in Identity Server

  1. Modify the tomcat.conf file.

    For information about how to modify a file, see Modifying Configurations.

  2. Add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

Disabling CRL Checking in AD FS 2.0

  1. Click Start > Administrative Tools > Windows PowerShell Modules.

  2. Run the following command in the PowerShell command prompt:

    set-ADFSClaimsProviderTrust -TargetName "NAM Example"

    -SigningCertificateRevocationCheck None

NOTE:You can make many configuration changes to AD FS 2.0 by using the Windows PowerShell command line and scripting environment. For more information, see AD FS 2.0 Windows PowerShell Administration of the AD FS 2.0 Operations Guide and AD FS 2.0 Cmdlets Reference.