Steps to configure ADFS 2.0 and UAG for ADFS 2.0 Authentication and Authorization – Teil 1 - TechNet Blog Deutschland - Site Home

Von Erich Hackspacher

Erich Hackspacher ist langjähriger Mitarbeiter im Microsoft Support (CSS). Seine Erfahrungen hat er in diversen Teams mit teilweise unterschiedlichen Technologien gesammelt. Zur Zeit ist er Mitglied des EMEA-weiten UAG Teams. In diesem Blog zitieren wir in zwei Kapiteln aus dem Whitepaper “How to configure UAG and ADFS to use ADFS 2.0 for Authentication and Authorization within UAG Portal and Published Applications” – Teil 2 finden Sie ebenfalls auf diesem Blog

This document does not explain how to install and configure the required certificate environment (setting up a Certificate Authority, Requesting Server certificates, Trusting CA..) This chapter will show how to configure ADFS Claims Provider Trusts and Relying Parties Trusts using the following two topologies as the start configuration:

Remote employee access using claims

This topic describes the Active Directory Federation Services (AD FS) 2.0 topology when remote employees access applications published by Forefront Unified Access Gateway (UAG) using claims-based authentication.

When remote employees attempt to access the published SharePoint application, the following simplified flow occurs:

The remote employees attempt to access the published SharePoint application using claims-based authentication in one of two ways: by accessing the Forefront UAG portal and then clicking the published SharePoint application or by accessing the published SharePoint application directly using the SharePoint alternate access mapping name.
Forefront UAG redirects the web browser request to the Resource Federation server to authenticate the user.
The Resource Federation server shows the home realm discovery page to users on which they must choose the organization to which they belong; in this case, their own organization.
The remote employees are prompted for credentials and authenticate using their own AD DS credentials, after which they receive a security token.
Users are silently redirected and automatically authenticated to Forefront UAG using the security token created by the Resource Federation server. If they attempted to access the published SharePoint application directly, they are silently redirected to the SharePoint site, after which the SharePoint site appears. If they first accessed the Forefront UAG portal, they must click the SharePoint application to view the site.

· After the first successful connection to the SharePoint site, the Resource Federation server stores a cookie on the user’s computer. The cookie is stored by default for 30 days, during this time, users are not required to answer identification questions on the home realm discovery page; that is, choosing the organization to which they belong.

Partner employee access using claims

This topic describes the Active Directory Federation Services (AD FS) 2.0 topology when partner employees access applications published by Forefront Unified Access Gateway (UAG) using claims-based authentication.

When users from the partner organization attempt to access the published Web Site application, the following simplified flow occurs:

The partner users attempt to access the published SharePoint application using claims-based authentication in one of two ways: by accessing the Forefront UAG portal and then clicking the published SharePoint application or by accessing the published SharePoint application directly using the SharePoint alternate access mapping name.
Forefront UAG redirects the web browser request to the Resource Federation server to authenticate the user.
The Resource Federation server shows the home realm discovery page to users on which they must choose the organization to which they belong; in this case, the partner organization.
The Resource Federation server redirects the web browser to the Account Federation server where users authenticate using their own credentials, after which they receive a security token.
Users are silently redirected several times and automatically authenticated using the security token created by the Account Federation server to the Resource Federation server and then to Forefront UAG. If they attempted to access the published SharePoint application directly, they are silently redirected to the SharePoint site, after which the SharePoint site appears. If they first accessed the Forefront UAG portal, they must click the SharePoint application to view the SharePoint site.

It is the following environment that was used during the creation of this Whitepaper:

1.1 Install and Configure ADFS 2.0

The main steps in this configuration process consist of the following:

1. AD FS 2.0 Installation

2. Creating a Federation Server

- Creating additional Trust Rule when users from the Partner Organization access published resources in the Resource Organization

3. UAG Trunk Configuration

- Configuring an AD FS 2.0 authentication repository

- Configuring the Trunk to use an AD FS 2.0 repository for Frontend authentication

4. Creating a Relying Party Trust

5. Claim Rules creation

2.1.1 Installing ADFS 2.0

First step is to install ADFS 2.0 software. This is not a built-in component shipped with the Operating System, it has to be downloaded and installed separately.

Download the AD FS 2.0 software by saving the AdfsSetup.exe setup file onto the computer:

Active Directory Federation Services 2.0 RTW

Start AdfsSetup.exe to install ADFS 2.0:

On the Server Role page, select Federation server, and then click Next.

On the Install Prerequisite Software page, click Next. After you click Next, you see the Installing AD FS 2.0 page.

To install the AD FS 2.0 software using the command-line:

- run adfssetup.exe /quiet for the federation server role

- run adfssetup.exe /proxy /quiet for the federation server proxy role

Now you are ready to configure the computer to become a federation server. You can use the following procedure to set up the computer to become the first federation server in a new federation server farm or a stand-alone federation server

2.1.2 Create a stand-alone Federation Server

After you install the Active Directory Federation Services (AD FS) 2.0 software and configure the required certificates on a computer, you are ready to configure the computer to become a federation server. You can use the following procedure to set up the computer to become a stand-alone federation server.

To create a stand-alone federation server

1. There are two ways to start the AD FS 2.0 Federation Server Configuration Wizard:

- open the AD FS 2.0Management snap-in (Start/Administrative Tools/AD FS 2.0 Management) and click the AD FS 2.0 Federation Server Configuration Wizard link on the Overview page or in the Actions pane.

- open Windows Explorer, navigate to the C:\Program Files\Active Directory Federation Services 2.0 folder, and then double-click FsConfigWizard.exe.

2. Select Create New Federation Service and then click Next.

3. click Stand-alone federation server, and then click Next.

4. On the Specify the Federation Service Name page, verify that the SSL certificate that is showing is the one used to configure Secure Sockets Layer (SSL) settings for the Default Web Site.

5. Select to create new AD FS Configuration Database

At the end of the wizard, a Configuration Results page will be displayed

Now we can have a look at the ADFS 2.0 Management console and we will notice that the ADFS 2.0 federation server has been completely configured and ready to be used.

The most important settings to be mentioned at this stage are the Attribute Store and claims provider trusts.

When AD FS 2.0 is installed and configured on a domain-joined computer, the Active Directory user account store for that domain is made available as a selectable attribute store. An attribute store is a pluggable module that the policy process for Active Directory Federation Services (AD FS) 2.0 can query to retrieve claim values. Active Directory® Federation Services (AD FS) 2.0 includes built-in attribute stores that you can use to query for claim information from external data stores, such as Enterprise Active Directory, Lightweight Directory Access Protocol (LDAP) directories, and Microsoft SQL Server. You can also define custom attribute stores to query for claim information from other external data stores.

Adding a claims provider trust to AD FS 2.0 gives users of that claims provider access to the relying parties that are configured in AD FS 2.0. Each relying party application makes authorization decisions about a user by examining the claims that AD FS 2.0 provides. In our example we see that a Claims Provider Trust with Active Directory is already configured.

Now it is the time to verify the configuration of ADFS 2.0 federation server setup.

The best way to so this is to browse the following URL for the Federation metadata of the Federation Server.

https://denver.woodgrovebank.com/federationmetadata/2007-06/federationmetadata.xml

The next step is to configure the Relying Party trust. This requires the Federation Metadata of the relying party

We will use UAG as our Relying Party (consumer of the claims issued by ADFS 2.0 Federation Server) so we will have to configure UAG 2010 SP1 to use ADFS 2.0 as a method to authenticate remote employees.

2.1.3 AD FS 2.0 Trunk Configuration

This step requires configuring UAG 2010 SP1 to use AD FS 2.0 as a method to authenticate the users them accessing the UAG portal. An ADFS 2.0 trunk can only be configured as an HTTPS trunk. Therefore you need to have the required certificate already requested and available.

The domain portions of the Subject field of the UAG trunk certificate should match the Subject fields of the certificates protecting the ADFS (STS) and the published application.

1. Configuring an AD FS 2.0 authentication repository

• On the UAG server, start the UAG Management console, access Admin | Authentication and Authorization Servers

• In the Authentication and Authorization Servers window, click Add

• In the Add Authentication Server window, in the Server type drop-down list, select AD FS 2.0. In the Server name box enter Federation

• In the Specify the URL of the federation metadata file, enter: https://denver.woodgrovebank.com/federationmetadata/2007-06/federationmetadata.xml

• Click Retrieve Metadata to retrieve the list of claims defined in the federation metadata file, on the AD FS 2.0 server

• If you get prompted about the federation metadata being signed with a certificate that is not trusted by the UAG sever, click OK to continue

• The Select the claim value to be used as the lead user value list became enabled. Select from the drop-down list the claim value UPN, then click OK to close the window

2. Configuring the HTTPS UAG portal trunk using the AD FS 2.0 repository for created before

· Select the portal trunk and click on the Configure… button to open the Advanced Trunk Configuration window

· On the Authentication tab, in the Select authentication servers list, click on Add

· Select the Federation server, then click Select. The Federation server is added to the list of authentication servers used by this trunk

· Select any additional authentication server in the list and click Remove, then confirm the removal

· Click OK to close the Advanced Trunk Configuration window

Now you need to activate the settings in UAG. Note the pop-up message displayed, which contains the URL for the federation metadata on the UAG server, which must be configured on the AD FS 2.0 server. However, the federation metadata file is not available until after you activate the UAG configuration.

After successfully activating the configuration, the federation metadata file that is required for creating the relying party trust with the AD FS 2.0 server is created in the following folder: \von\InternalSite\ADFSv2Sites\<trunk_name>\FederationMetadata\2007-06

Verify that the FederationMetadata.xml file has been created in the above mentioned folder, on the UAG server

Also an AD FS 2.0 application is automatically created. This application represents the AD FS 2.0 authentication repository

Having finished this step, we can move to the next one.

2.1.4 Creating a Relying Party Trust

When deploying Forefront Unified Access Gateway (UAG) with Active Directory Federation Services (AD FS) 2.0, you must configure the Forefront UAG server as a new relying party trust. To create the relying party trust, you must use the AD FS 2.0 Management snap-in, and import the Forefront UAG configuration data from federation metadata that Forefront UAG publishes to a local network or to the Internet.

Before creating the relying party trust, you must either copy the federation metadata file from the Forefront UAG server (or array manager server) to the AD FS 2.0 server or make sure you can access it on the AD FS 2.0 server over the Internet.

The file was created during Forefront UAG activation and is located in the following folder:

...\Microsoft Forefront Unified Access Gateway\von\InternalSite\ADFSv2Sites\<trunk_name>\Feder ationMetadata\2007-06,

or at the following URL: https://<Portal_FQDN>/InternalSite/ADFSv2Sites/<trunk_name>/FederationMetadata/2007-06/FederationMetadata.xml.

On the Choose Issuance Authorization Rules page, click Permit all users to access this relying party, and then click Next.

On the Ready to Add Trust page, review the settings, and then click Next to save your relying party trust information

As you can see, the Relying Party publishes the following claim types as accepted claim types in federation metadata

Finally the Relying Party Trust has been added:

2.1.5 Creating Claim Rules

Now that the Trusts have been created we need to make sure that the required claim will be issued to the client. This process is done through 2 steps

1. Add claim rule to the claim provider

· On Denver, access the AD FS 2.0 Management console, then go to AD FS 2.0 | Trust Relationships | Claims Provider Trusts

· In the middle pane, right-click Active Directory and select Edit Claim Rules.

· Click Add Rule. On the Select Rule Template page, choose Send LDAP Attribute as Claims, then click Next

· On the Configure Rule page, in the Claim rule name field, enter Send LDAP UPN

· In the Attribute store drop-down, select Active Directory

· In the LDAP Attribute drop-down, select User-Principal-Name, and in the Outgoing Claim Type drop-down, select UPN. Click Finish, then click OK to close the Edit Claims for Active Directory window

2. Create claim rule for the Relying Part (UAG):

· This claim rule is created on the Issuance Transform Rules Tab

· Similar to the previous procedure, create a claim Rule for the UAG Relying Party. The rule will pass through to the UAG server the UPN claim issued by the AD as the identity provider that was previous configured.

2.1.6 Disable IIS Extended Protection

Forefront UAG behaves like a “man in the middle” in AD FS 2.0 deployments. IIS on the AD FS 2.0 server automatically protects against man in the middle attacks using a Channel Binding Token (CBT). However, if the CBT is enabled, you cannot provide access to your remote employees. To turn off CBT use one of the following methods:

1. On the AD FS 2.0 server in your organization, run the following command:

appcmd.exe set config "Default Web Site/ADFS/ls" -section:system.webServer/security/authentication/windowsAuthentication /extendedProtection.tokenChecking:"None" /extendedProtection.flags:"Proxy" /commit:apphost

2. Disable Extended Protection in IIS on your ADFS 2.0 Server:

· Launch IIS Manager. On the left pane, access DENVER | Sites | Default Web Site | adfs | ls

· In the middle pane, double-click Authentication. Right-click Windows Authentication and select Advanced Settings

· In the Advanced Settings window, in the Extended Protection drop-down list, select Off, then click OK

The last setting we have to make is to add the public host name of the AD FS 2.0 – Federation application, as well as public host name of the portal to the browser’s Trusted sites zone. Alternatively, you can add the entire woodgrovebank.com domain to the zone, by using a wildcard: *.woodgrovebank.com