次の方法で共有

AD FS 2.0 Step-by-Step Guide: Integration with RSA SecurID in the Extranet

  • [アーティクル]

Updated: September 1, 2011

Applies To: Active Directory Federation Services (AD FS) 2.0

Important

The solution described below provides an additional factor of protection for the AD FS authentication page by requiring the user to have RSA hardware and PIN in addition to an AD username and password. Attackers armed with only a stolen username and password would be unable to log in successfully. However, because the RSA Authentication Agent is a separate system, the AD FS page is unaware of its existence and does not perform matching of the username provided to AD FS to the identity authenticated by RSA.
In Windows Server 2012 R2, multi-factor authentication providers can be configured so that they tightly integrate with the AD FS authentication process, including matching the authenticating user for first and second factor. For more information see Overview: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

About This Guide

Microsoft Active Directory Federation Services (AD FS) 2.0 is a security token service (STS) that enables identity federation, extending the notion of centralized authentication, authorization, and SSO to Web applications and services located virtually anywhere, including perimeter networks, partner networks, and the cloud. Increasingly, organizations want to enable federated application access for users when they are away from the office, but need to do so securely.

This guide discusses multiple approaches for enabling remote access to AD FS 2.0, as well as discussing strong authentication approaches available for securing remote access. Then, it describes in detail the option of using a third-party multi-factor authentication solution such as RSA SecurID.

Lastly, this document provides step-by-step guidance for the setup of a basic lab deployment of the AD FS 2.0 federation server proxy (FS-P) with RSA SecurID, demonstrating multi-factor protected remote access to a claims-aware application hosted in the DMZ. This document is intended for system architects who are interested in understanding the basic modes of integration between AD FS 2.0 and multi-factor authentication solutions like RSA SecurID

Terminology Used in This Guide

Throughout this document, there are numerous references to federation concepts that may be unfamiliar. Use the following table to better understand these concepts.

Concept name Definition

Security token

A package of security information, describing a user, created and consumed during a claims-aware access request

Claims provider

Entity that creates security tokens for users

Relying Party

Entity that consumes security tokens for providing access to applications

Claims

Data about users that is sent inside security tokens

About the Author

Dave Martinez (dave@davemartinez.net) is Principal of Martinez & Associates, a technology consultancy based in Redmond, Washington.

Identity Federation: Extending User Access beyond the Firewall

Beginning with Windows 2000 Server, the Kerberos-based user identity provided by an Active Directory Domain Services (AD DS) deployment has facilitated secure authorization and single sign-on (SSO) to Active Directory-aware resources located inside its own and other trusted Active Directory domains.

Microsoft Active Directory Federation Services (AD FS) 2.0 is a security token service (STS) that enables identity federation, extending the notion of centralized authentication, authorization, and SSO to Web applications and services located virtually anywhere. Identity federation uses standards-based communications and security protocols (HTTPS, SOAP, SAML 2.0, X.509 and so on) to establish federation trusts between identity providers and relying parties, facilitating secure access to Web applications and services across security boundaries. The result is that users employing federated identities can seamlessly access resources located:

  • Inside the corporate intranet

  • Outside the corporate network in a corporate perimeter network, extranet or in the cloud (for example, Windows Azure)

  • At the perimeter networks of partner organizations that have made applications available to your users, including organizations using alternative application platforms or identity management solutions

  • In the cloud with Software as a Service (SaaS) vendors that support federated identity, for example, Microsoft with its Office 365 offering.

Accessing AD FS 2.0 from Outside the Firewall

In order to take advantage of identity federation, an organization’s users must be able to access the AD FS 2.0 service itself so that they can request security tokens.

In its default configuration, an AD FS 2.0 federation server (FS) sits inside an Active Directory domain and authenticates users using Integrated Windows Authentication. Since an FS is a high-value asset containing cryptographic key material, access to the FS is typically limited to internal network clients only.

It is increasingly common, however, for users to need access to Web applications and services at times when they themselves are remote – at home, at the airport, at an Internet café, and so on. To address situations like these, organizations have two high-level options to make the AD FS 2.0 service remotely accessible:

  • Extend the network perimeter - Solutions like virtual private networking (VPN), DirectAccess, and Remote Desktop Services (formerly Terminal Services) all provide users with a de facto direct network connection, providing access to all internal network resources. As related to AD FS 2.0, these solutions have the benefit of supporting browser-based access to federated Web applications using the WS-Federation or SAML 2.0 protocols, as well as rich client access to federated Web services using the WS-Trust protocol. However, these solutions all have significant infrastructure requirements, and provide relatively broad access to internal resources when more tightly controlled internal access might be preferred.

  • Reverse proxy approach - An alternative model is to leverage the network perimeter as an access control edge, allowing proxied access to required servers/services in the internal network. As relates to AD FS 2.0, two options exist to use this approach:

    • General-purpose reverse proxy solutions including Microsoft Forefront Unified Access Gateway (UAG) and Microsoft Forefront Threat Management Gateway (TMG) enable organizations to securely publish internal applications to the Internet. This can include claims-aware applications or the AD FS 2.0 server, whose authentication endpoints can be published externally through the reverse proxy. Unlike the other solutions listed here, a reverse proxy solution is not included in Windows Server.

      A solution like UAG can either perform authentication at the reverse proxy layer (called frontend authentication or preauthentication) or pass users through to a published application unauthenticated with the expectation that the application will perform its own security. When configured to pass through with no preauthentication, AD FS 2.0 remote access scenarios that span both Web applications and Web services can work. When configured to perform preauthentication, AD FS 2.0 can receive requests only for security tokens for browser-based Web applications. Rich client Web services (WS-Trust) scenarios, which embed authentication credentials inside XML SOAP messages using the WS-Security standard, will not work due to protocol transition and user interaction requirements.

    • The AD FS 2.0 Federation Server Proxy (FS-P) is a deployment mode of AD FS 2.0 specifically designed to provide remote access to internally-hosted federation servers. In a typical deployment, the FS-P is hosted in a perimeter network, and passes data through port 443 to the FS, which generates the required security token. The AD FS 2.0 FS-P can respond to security token requests for accessing claims-aware Web applications (WS-Federation, SAML 2.0) and Web services (WS-Trust). However, being limited to proxying only the AD FS 2.0 application, the FS-P cannot enable access to applications or services hosted inside the corporate firewall without the help of a general-purpose reverse proxy, such as UAG.

Adding Security with Strong Authentication

Organizations allowing remote access to internal servers and applications, using any of the approached described above, commonly consider strong authentication techniques to secure inbound access. Since attackers can reach the inbound access point easily, and successfully authentication to an FS potentially grants the attacker access to security tokens for numerous relying party applications, securing remote authentication to the server is important.

In addition the default username and password authentication, all the aforementioned Microsoft remote access solutions support client certificate and smartcard-based authentication, both of which are public key infrastructure (PKI)-based technologies that provide strong authentication. Client certificates issued to users can be used instead of usernames and passwords to authenticate browser and rich clients to Web applications and services. Smartcard authentication further enhances security by using two factors to verify identity: something the user has (a smartcard-based client certificate) plus something the user knows (a PIN code). Certificates and smartcards can be provisioned and managed through Microsoft Forefront Identity Manager.

Note

If considering the general-purpose reverse proxy approach (UAG, and so on) for remote access to AD FS 2.0, and considering the pass-through model (no preauthentication), any strong authentication will be performed directly at the corporate FS. The FS will be simultaneously accessible by clients inside and outside the corporate firewall. The AD FS 2.0 passive Web site, which processes security token requests for Web applications, supports multiple authentication methods (integrated authentication, forms, client certificates, and so on), but can use only one of those authentication mechanisms at a time. Thus, employing strong authentication for external users requires that internal users use the same strong authentication method, potentially disabling internal SSO to the FS.

Third-Party Two-Factor Authentication

For organizations looking for alternatives to Microsoft’s certificate/smartcard support, third-party solutions exist that provide strong authentication (including two-factor authentication) and integrate with Microsoft technologies. To varying degrees, all of the AD FS 2.0 remote access alternatives can be integrated with third-party strong authentication solutions.

One of the more popular third-party two-factor authentication solutions is RSA SecurID, and multiple integration points exist between Microsoft and RSA technologies. The table below summarizes the RSA SecurID integration options for each of the aforementioned remote access alternatives.

Solution Description

VPN

Using the RSA Authentication Agent for Microsoft Windows Extensible Authentication Protocol (EAP) client, organizations can enable RSA SecurID authentication using the Microsoft Windows VPN client. Alternatively, UAG can also enable RSA two-factor authentication for VPN (see UAG below). In both cases, the resulting connection supports AD FS 2.0 token requests for Web applications and services.

DirectAccess

UAG can enable RSA two-factor authentication for DirectAccess (see UAG below). The resulting connection supports AD FS 2.0 token requests for Web applications and services.

RDS

Using the RSA Authentication Agent for Microsoft Windows Local Authentication Client, organizations can enable RSA SecurID authentication using the Remote Desktop Connection client. Alternatively, UAG can also enable RSA two-factor authentication for RDS (see UAG below). In both cases, the resulting connection supports AD FS 2.0 token requests for Web applications and services.

General purpose reverse proxy

With preauthentication: UAG 2010 explicitly supports RSA SecurID for frontend authentication to published VPN, DirectAccess, RDS connections and Web applications like the AD FS 2.0 browser-based token request Web site.UAG provides a built-in RSA web authentication agent that talks directly to an RSA Authentication Manager server, plus an interface for collecting RSA passcode and Windows domain credentials in a single form. The resulting connection supports AD FS 2.0 token requests for Web applications only; Web services scenarios are not supported unless UAG is used to access AD FS 2.0 through a VPN/DirectAccess/RDS connection.

Pass-through:The RSA Authentication Agent 7.0.2 for Web for IIS enables RSA SecurID authentication for IIS 7 Web applications, and can be installed on an FS. However, the RSA web agent requires Local System or equivalent privileges for the application pool identity of all protected applications. Since external access attempts would be processed directly at the internal FS, use of such a privileged app pool identity represents a security risk, and is therefore not recommended.For Web services scenarios, a Windows Communication Foundation (WCF) rich client can be modified to collect RSA-relevant credential data and communicate directly with the RSA Authentication Manager server by using its application programming interface (API). This requires custom development, and it is the rich client application’s responsibility to preserve the integrity of the security model by communicating with RSA Authentication Manager before contacting AD FS 2.0.

AD FS 2.0 FS-P

Using the FS-P along with RSA Authentication Agent 7.0.2 for Web for IIS, users can sequentially authenticate to RSA SecurID, and then to the FS-P by using forms authentication. The resulting connection supports AD FS 2.0 token requests for Web applications only; Web services are not supported.Since the RSA web agent requires Local System or equivalent privileges for the application pool identity of all protected applications, it is recommended for security purposes that the FS-P either be deployed standalone (not domain joined) or deployed in an Active Directory forest that is not trusted by the internal Active Directory forest hosting an organization’s user accounts. Alternatively, the FS-P forms login page (for Web applications) or a WCF rich client (for Web services) can be modified to collect RSA-relevant credential data and communicate directly with the RSA Authentication Manager server by using its API before contacting AD FS 2.0. This requires custom development.

The next section of this document describes the steps required to build a sample deployment of AD FS 2.0 that employs the FS-P and the RSA Authentication Agent 7.0.2 for Web for IIS for providing remote access to a perimeter-based claims-aware application.

Sample Lab: Prerequisites and Requirements

This lab requires five computers, as described below:

  1. AD FS 2.0 Federation Server – fsweb.contoso.com

    The federation server created in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide (https://go.microsoft.com/fwlink/?linkid=193997) is used as starting point for this lab. To ensure that AD FS 2.0 is working properly, readers must complete that step-by-step guide before starting this one, to ensure AD FS 2.0 is working properly. This document presumes that neither of the Appendices in that step-by-step guide has been completed.

Note

The AD FS 2.0 Federation with a WIF Application Step-by-Step Guide requires the availability of a contoso.com internal domain in which fsweb.contoso.com is a member. Since the same computer can perform the domain controller and federation server roles in test deployments, this lab used fsweb.contoso.com for both functions. In production deployments, federation servers and domain controllers should be located on separate servers for security.

  1. RSA Authentication Manager Server – securid.contoso.com

    A server running RSA Authentication Manager 7.1 SP4 P3 is used in this lab to process RSA SecurID authentication requests. The server uses Windows Server 2003 SP2, the most recent Windows Server release supported by the RSA Authentication Manager product as of the time of writing.

    This document presumes the following has already taken place on this server:

    • This computer is joined to the contoso.com domain (to leverage DNS)

    • RSA Authentication Manager 7.1 SP4 P3 is installed

    • The contoso.com Active Directory instance is being used as an RSA Authentication Manager identity source for the realm to which we will later add the IIS web agent; in this lab, the default SystemDomain realm was used. The Active Directory samAccountName is mapped as the RSA SecurID User ID.

Note

Support for Active Directory as an RSA Authentication Manager identity source was first released in Authentication Manager 7.1 SP2. 

  - An RSA SecurID token has been assigned to CONTOSO\\administrator, the user PIN has been set, and the token is operational.

  1. Claims-aware Web Server – web.contosodmz.com

    A perimeter-based IIS web server will host the same Windows Identity Foundation (WIF) application used in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide. Since AD FS 2.0 will not have been previously installed on this server, users will download and install the WIF runtime and WIF SDK. Although WIF can run on Windows Server 2003 and above, this lab used Windows Server 2008 R2.

    This document presumes the following has already taken place on this server:

    • The Web Server (IIS) server role is installed.

    • The ASP.NET role service for the IIS server role is also installed.

Note

This lab requires the availability of a contosodmz.com perimeter domain in which web.contosodmz.com is a member. The DNS deployment for the domain will act as “Internet DNS” for the external web browser client in this lab.Since the same computer can perform the domain controller and web server roles in test deployments, this lab used web.contosodmz.com for both functions. In production deployments, domain controllers should not host externally-facing web servers.

  1. RSA SecurID-protected AD FS 2.0 Proxy – proxy.contosodmz.com

    A perimeter-based AD FS 2.0 FS-P will provide remote browser clients with a means to communicate with an internal federation server for requesting security tokens. Access to the FS-P will be protected both by the proxy itself (using forms authentication against the internal Active Directory domain) and the RSA Authentication Agent 7.0.2 for Web for IIS. This server uses Windows Server 2008 SP2, the most recent Windows Server release supported by the RSA Authentication Agent 7.0.2 for Web for IIS.

Important

The current build of RSA Authentication Agent 7.0.2 for Web for IIS currently available for download from the RSA web site is build 379. Build 379 does not work with AD FS 2.0. RSA has created a solution to address the issue. Please contact RSA Technical Support, or visit RSA SecurCare Online and search for solution a55200 (https://knowledge.rsasecurity.com/scolcms/knowledge.aspx#a55200). 

This lab presumes only that this server is joined to the contosodmz.com perimeter forest; no other software should be pre-installed.

  1. Internet client

    This lab used a Windows 7 workstation as the external web browser client accessing the perimeter-based claims-aware application. Since the lab uses fictional DNS names, this client computer will be configured to use the perimeter DNS server for name resolution. Supported browsers for AD FS 2.0 and the RSA Authentication Agent 7.0 for Web for IIS include Internet Explorer 7.0, Internet Explorer 8.0, and Firefox 3.0.

Step 1: Preconfiguration Tasks

Perform these prerequisite configuration steps to prepare the environment for testing.

Note

All of the actions in this section were performed while logged into Windows with administrative privileges.

Ensure IP Connectivity

For simplicity, this lab used five IP addresses in the same 192.168.1.x subnet, and did not establish firewall rules to control communications. However, for those interested in using firewalls in their lab, the inbound port requirements for each server are as follows:

Note that the internal servers only require inbound connectivity from the AD FS 2.0 proxy / RSA web agent computer. Also note that the perimeter DNS instance requires inbound connectivity from external clients.

Configure Name Resolution

In this lab, we will use Microsoft Domain Name System (DNS) servers to configure name resolution of the various servers. The initial DNS deployment should look as follows:

To initially configure DNS, first point the DNS client on each computer to the proper DNS server, then set up a DNS forwarder from the internal DNS server to the perimeter DNS server, to resolve computers in the contosodmz.com zone.

Later in the document, we will perform further DNS configuration specific to the AD FS 2.0 proxy.

To configure DNS client/server relationships

  1. Find the Local Area Connection object in the following locations:

    Operating System Location

    Windows Server 2003

    Control Panel > Network Connections > Local Area Connection

    Windows Server 2008

    Control Panel > Network Connections > Local Area Connection

    Windows Server 2008 R2

    Control Panel > Network and Internet > Network Connections > Local Area Connection

  2. Right-click Local Area Connection, and select Properties.

  3. In Windows Server 2003, click Internet Protocol (TCP/IP), and click the Properties button. In Windows Server 2008 and Windows Server 2008 R2, click Internet Protocol Version 4 (TCP/IPv4), and click the Properties button.

  4. In the Properties dialog box, use the following values:

    Computer Preferred DNS Server

    fsweb.contoso.com

    127.0.0.1 (self)

    securid.contoso.com

    fsweb.contoso.com IP address

    web.contosodmz.com

    127.0.0.1 (self)

    proxy.contosodmz.com

    web.contosodmz.com IP address

    Internet client

    web.contosodmz.com IP address

  5. Click OK, and then click Close.

To configure DNS forwarding on fsweb.contoso.com

  1. On fsweb.contoso.com, click Start, click Administrative Tools, and then click DNS.

  2. Click the FSWEB icon in the left navigation area, right-click Forwarders in the Actions pane, and select Properties.

  3. On the Forwarders tab, click Edit, type the IP address for web.contosodmz.com, and click Enter. In the Edit Forwarders window, watch for the word “validating” to change to “OK.”

  4. To complete the forwarder setup, click OK twice.

Verify Clock Synchronization

Federation events typically have a short Time to Live (TTL). To avoid errors based on time-outs, ensure that all computers have their clocks synchronized.

Note

For information on how to synchronize a Windows Server domain controller to an Internet time server, see the Microsoft Knowledge Base article 816042(https://go.microsoft.com/fwlink/?LinkId=60402).

Enable SSL Server Authentication

Claims-aware access relies heavily on public key infrastructure (PKI), including Secure Sockets Layer (SSL) encryption, for trustworthy communications. Because this lab uses self-signed SSL certificates for IIS server authentication, corresponding public key certificates must be imported into each computer that initiates contact with these IIS servers. After preconfiguration, the lab’s SSL trust deployment should look as follows:

Note

In a production scenario, to avoid SSL-related warnings and errors, organizations are encouraged to use SSL certificates that chain up to a commercial trusted root certificate distributed in Microsoft Windows server and client operating systems.

To initially configure SSL security in this lab, we must:

  • Create and apply a new self-signed certificate on the perimeter web server (web.contosodmz.com) using IIS Manager.

  • Add the self-signed certificate for web.contosodmz.com to the FS (fsweb.contoso.com) local server Trusted Roots store.

  • Add the self-signed certificate being used by the FS into the local server Trusted Roots store of various computers.

Later in the document, we will perform further SSL configuration specific to the AD FS 2.0 proxy.

To generate and apply a new self-signed SSL certificate for web.contosodmz.com

  1. On web.contosodmz.com, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the left pane, click the WEB computer. Then, in the IIS section of the center pane, double-click Server Certificates.

  3. In the right pane, under Actions, click Create Self-Signed Certificate.

  4. In the Specify Friendly Name window, type web_self, and then click OK.

  5. In the left pane, in the Sites folder, right-click Default Web Site, and then click Edit Bindings.

  6. In the Site Bindings window, click Add.

  7. In the Add Site Binding window, in the Type box, select HTTPS, and in the SSL certificate box, select web_self. Click OK, and then click Close.

To install web.contosodmz.com SSL certificate on fsweb.contoso.com

  1. On web.contosodmz.com, in IIS Manager, in the left pane click the WEB icon. Then, in the IIS section of the center pane, double-click Server Certificates.

  2. Right-click the server certificate web_self, and select View.

  3. On the Certificate Details tab, click Copy to File to start the Certificate Export Wizard.

  4. On the Export Private Key page, verify that No is selected, and click Next.

  5. On the Export File Format page, verify that the default is selected, and click Next.

  6. On the File to Export page, click Browse and navigate to a location accessible by fsweb.contoso.com. In the File name box, type web_self.

  7. To save web_self.cer to the defined location, click Save, click Next, click Finish, click OK, and then click OK.

  8. On fsweb.contoso.com, access the location where web_self.cer was saved.

  9. To start the Certificate Import Wizard, right-click web_self.cer, and click Install Certificate.

  10. Click Next.

  11. In the Certificate Store window, click Place all certificates in the following store.

  12. Click Browse, and then click Show physical stores.

  13. In the Trusted Root Certificate Authorities folder, select Local Computer, and then click OK.

  14. Click Next, click Finish, click OK, and then click OK.

To install fsweb.contoso.com SSL certificate on other computers

  1. On fsweb.contoso.com, in IIS Manager, in the left pane click the FSWEB icon. Then, in the IIS section of the center pane, double-click Server Certificates.

  2. Right-click the server certificate fsweb.contoso.com, and select View.

  3. On the Certificate Details tab, click Copy to File to start the Certificate Export Wizard.

  4. On the Export Private Key page, verify that No is selected, and click Next.

  5. On the Export File Format page, verify that the default setting is selected, and click Next.

  6. On the File to Export page, click Browse, and navigate to a location that is accessible by the other lab computers. In the File name box, type fsweb_self.

  7. Click Save, click Next, click Finish, click OK, and then click OK to save fsweb_self.cer to the defined location.

  8. On each of the computers listed below, log in with administrator privileges, access the location where fsweb_self.cer was saved, right-click the file, and install the certificate to the local computer Trusted Root Certificate Authorities store:

    1. web.contosodmz.com

    2. proxy.contosodmz.com

    3. Internet client

Install WIF and Sample Application

These steps will add the WIF runtime and WIF SDK to the web.contosodmz.com perimeter web server, and register the sample application (which is part of the SDK) in IIS.

To install the WIF runtime and WIF SDK on web.contosodmz.com

  1. In Server Manager, right-click Features in the left navigation area, and select Add Features.

  2. On the Select Features page, in the .NET Framework 3.5.1 Features section, check .NET Framework 3.5.1check box.

  3. Click Next, and then click Install.

  4. Download the WIF Software (https://go.microsoft.com/fwlink/?LinkId=224157) to web.contosodmz.com. For Windows Server 2008 R2, choose the file named Windows6.1-KB974405-x64.msu.

  5. Double-click the file, click Yes, and accept the license terms to perform the install.

  6. Download the WIF SDK (https://go.microsoft.com/fwlink/?linkid=179833) to web.contosodmz.com. Since this lab uses .NET Framework 3.5.1, choose the WindowsIdentityFoundation-SDK-3.5.msifile.

  7. Double-click the file, click Next, check the I accept the terms in the License Agreement box, and then click Next.

  8. Click Next to accept the default destination folder, and then click Install.

  9. Click Finish to complete the installation.

To install the WIF SDK sample application in IIS

  1. Open Windows Explorer, and navigate to the C:\Program Files (x86)\Windows Identity Foundation SDK\v3.5\Samples\Quick Start\Using Managed STS folder.

  2. Right-click setup.bat, and then click Run as administrator.

  3. After the command-line script stops running, close the Command Prompt window.

To create and configure the required WifSamples application pool

  1. Open the Internet Information Services (IIS) Manager console.

  2. In the console tree, in the root node that contains the WEB computer, right-click Application Pools, and then click Add Application Pool.

  3. In the Add Application Pool dialog box, in Name type WifSamples, and then click OK.

  4. In IIS Manager, in the Details pane, right-click the newly created WifSamples application pool, and then click Advanced Settings.

  5. In the Advanced Settings dialog box, in the Process Model section, change the value for Load User Profile to True, and then click OK.

  6. Close the IIS Manager console.

Install the AD FS 2.0 Federation Server Proxy

These steps will add the AD FS 2.0 FS-P role to the proxy.contosodmz.com server in the perimeter. The FS-P install process will automatically install other required software, including the Web Server (IIS) role and the .NET Framework 3.5.1.

To install the AD FS 2.0 Federation Server Proxy role

  1. Download the AD FS 2.0 Software (https://go.microsoft.com/fwlink/?linkid=151338) to proxy.contosodmz.com. Make sure to select the proper file for the version of Windows Server 2008 you are using (32-bit or 64-bit).

  2. Double-click the file, and then click Run to start the AD FS 2.0 Setup Wizard.

  3. On the Welcome to the AD FS 2.0 Setup Wizard page, click Next.

  4. On the End-User License Agreement page, read the license terms. If you agree to them, select the I accept the terms in the License Agreement check box, and then click Next.

  5. On the Server Role page, choose Federation server proxy. Click Next, and then click Next.

  6. On the Completed the Microsoft AD FS 2.0 Setup Wizard page, you have to clear the check box to start the AD FS 2.0 Federation Server Proxy Configuration Wizard. We will do this configuration later.

  7. Click Finish.

Step 2: Configure AD FS 2.0 Federation Server Proxy

These steps will establish a trust between the FS-P and the contoso.com FS, as well as configure DNS and certificates to properly support the FS-P deployment.

An AD FS 2.0 deployment always has a single service URL to which browser clients are redirected for requesting security tokens. In this lab, the service URL is https://fsweb.contoso.com/adfs/ls/. Since this URL points to a FS inside the contoso.com internal forest, it is inaccessible by Internet clients. The purpose of the FS-P is to act in the place of the FS for Internet clients.

For the FS-P to operate correctly, Internet clients looking for the FS service URL have to be redirected to the FS-P and must have the ability to establish secure communications with the FS-P. This requires the following:

  • Modifying external DNS to redirect requests for the FS (fsweb.contoso.com) to the IP address of the FS-P (proxy.contosodmz.com)

  • Using an SSL server authentication certificate on the FS-P with a subject name that matches the name of the FS (fsweb.contoso.com)

Reconfigure DNS

These steps modify the perimeter DNS instance hosted on web.contosodmz.com to redirect external requests for fsweb.contoso.com to the Internet-accessible FS-P. The steps include the following:

  • Adding a zone to the perimeter DNS that matches the internal Contoso DNS zone name (contoso.com)

  • Adding a record to the new zone for fsweb.contoso.com that points to the FS-P (proxy.contosodmz.com) IP address

  • Adding an entry to the HOSTS file on the FS-P that points to the actual FS (fsweb.contoso.com) IP address, which will override the perimeter DNS entry and ensure that the proxy can find the federation server

To add the contoso.com zone to perimeter DNS

  1. On the perimeter DNS server (web.contosodmz.com), click Start, click Administrative Tools, and then click DNS.

  2. In the left navigation area, right-click the Forward Lookup Zones folder, and select New Zone.

  3. In the New Zone Wizard, on the Zone Type page, verify that Primary zone is selected.

  4. On the Active Directory Zone Replication Scope page, verify that the default is selected, and click Next.

  5. On the Zone Name page, type contoso.com in the text box, and click Next.

  6. On the Dynamic Updates pages, verify that the default is selected, and click Next.

  7. Click Finish.

To add a fsweb.contoso.com record to the new zone

  1. In the DNS Manager left navigation pane, click the new contoso.com forward lookup zone.

  2. Right-click the contoso.com zone, and select New Host (A or AAAA).

  3. In the New Host Name box, type fsweb, and in the IP address box, type the IP address for the FS-P (proxy.contosodmz.com).

  4. Click Add Host, click OK, and then click Done.

To add an entry for fsweb.contoso.com to the FS-P HOSTS file

  1. While logged in as an administrator, locate the hosts file on the FS-P computer (proxy.contosodmz.com), and open in Notepad. The default location is C:\windows\system32\drivers\etc\hosts.

  2. Add an entry for fsweb.contoso.com, for example:192.168.1.1fsweb.contoso.com

  3. Save and close the file.

Configure SSL on the FS-P

These steps enable SSL server authentication on the IIS instance running on the FS-P (proxy.contosodmz.com). Since the SSL certificate requires that the subject name equals the FQDN of the internal FS, creating a self-signed certificate in IIS will not work. Thus, we will export the certificate from the internal FS and import it into the FS-P.

To export the fsweb.contoso.com certificate

  1. On fsweb.contoso.com, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the left pane, click the FSWEB icon. Then, in the IIS section of the Details pane, double-click Server Certificates.

  3. In the Details pane, right-click the fsweb.contoso.com certificate, and click Export.

  4. In the Export Certificate dialog, in the Export to box, select a location accessible by the FS-P.

  5. In the File name dialog, name the file fsweb_ssl, and click Open.

  6. Provide a password, and click OK to complete the export.

To import and apply the fsweb.contoso.com certificate on the FS-P

  1. On web.contosodmz.com, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the left navigation pane, click the PROXY icon. Then, in the IIS section of the Details pane, double-click Server Certificates.

  3. In the Actions pane, click Import.

  4. In the Import Certificate dialog, in the Certificate file box, navigate to the fsweb_ssl.pfx file you created earlier, and click Open.

  5. Type the password you set earlier, and click OK.

  6. In the tree pane, in the Sites folder, right-click Default Web Site, and then click Edit Bindings.

  7. In the Site Bindings dialog, click Add.

  8. In the Add Site Binding dialog, in the Type box, select HTTPS and

  9. In the SSL certificate box, select fsweb.contoso.com. Click OK, and then click Close.

Create the AD FS 2.0 Proxy Trust

These steps establish communications between the FS and the FS-P.

To create the AD FS 2.0 proxy trust

  1. On proxy.contosodmz.com, click Start, click Administrative Tools, and then click AD FS 2.0 Federation Server Proxy Configuration Wizard.

  2. On the Specify Federation Service Name page, leave the default fsweb.contoso.com name, and click Test Connection. If the connection fails, verify that the SSL certificate for fsweb.contoso.com is trusted, and that the HOSTS file entry on the FS-P properly points to the IP address of the FS.

  3. Click Next.

  4. In the Windows Security dialog, type the Contoso administrator username (CONTOSO\administrator) and password, and click OK.

  5. To start the configuration process, click Next.

  6. Click Close.

Step 3: Configure the Claims-Aware Application

Here we will configure the claims-aware application on web.contosodmz.com to work with AD FS 2.0 as a WIF-enabled application. To simplify the configuration process, we will use published metadata from both the WIF application and the AD FS 2.0 FS (which is actually made available to the perimeter-based web server by the FS-P).

Run the WIF Federation Utility

The WIF Federation Utility modifies the web.config file of an ASP.NET application to add the configuration elements required for integration with an AD FS 2.0 server.

Note

Developers who install the WIF runtime and SDK on a development server can launch this same configuration wizard from within Visual Studio 2008 or Visual Studio 2010 by right-clicking the project in Solution Explorer and selecting Add STS Reference.

To run the WIF Federation Utility

  1. On web.contosodmz.com, click Start, click Administrative Tools, and then click Windows Identity Foundation Federation Utility.

  2. On the Welcome to the Federation Utility Wizard page, in Application configuration location, navigate to C:\Program Files (x86)\Windows Identity Foundation SDK\ v3.5\Samples\Quick Start\Using Managed STS\ ClaimsAwareWebAppWithManagedSTS\web.config and click Open.

  3. In Application URI, type https://web.contosodmz.com/ClaimsAwareWebAppWithManagedSTS/, and click Next.

Note

Verify that the Uniform Resource Identifier (URI) starts with https and that it does not specify a port number.

  1. On the Security Token Service page, click Use an existing STS, type fsweb.contoso.com, and then click Next.

Note

The metadata here is actually being read from the FS-P, since DNS is redirecting fsweb.contoso.com to the proxy IP address.

  1. On the STS signing certificate chain validation error page, leave the Disable certificate chain validation option selected, and click Next.

  2. On the Security token encryption page, leave the No encryption option selected, and click Next.

  3. On the Offered claims page, review the claims that will be offered by the federation server, and then click Next.

  4. On the Summary page, review the changes that will be made to the sample application by the Federation Utility, and then click Finish.

  5. Click OK.

Create a New Relying Party Trust in AD FS 2.0

These steps add a new relying party trust in AD FS 2.0 for which the federation server will generate security tokens.

To add an AD FS 2.0 relying party trust

  1. On the ADFS 2.0 computer (fsweb.contoso.com), click Start, click Administrative Tools, and then click AD FS 2.0 Management to open the AD FS 2.0 Management console.

  2. In the left navigation area, expand the Trust Relationships folder, then right-click the Relying Party Trusts folder, and click Add Relying Party Trust to start the Add Relying Party Trust Wizard.

  3. On the Welcome page, click Start.

  4. On the Select Data Source page, click the Import data about the relying party published online or on a local network option.

  5. In the Federation metadata file location box, type https://web.contosodmz.com/ClaimsAwareWebAppWithManagedSTS/, and click Next.

  6. In the Specify Display Name page, verify web.contosodmz.com, and click Next.

  7. On the Choose Issuance Authorization Rules page, verify that the Permit all users to access the relying party option is selected, and then click Next.

  8. Click Next, and then click Close.

Edit Claim Rules for Relying Party Trust

These steps configure the claims that will be sent to the claims-aware application.

To edit AD FS 2.0 claim rules for a relying party trust

  1. The Edit Claim Rules dialog should already be open. If not, In the AD FS 2.0 Management Details pane, under Relying Party Trusts, right-click web.contosodmz.com, and then click Edit Claim Rules.

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

  3. In the Select Rule Template page, verify that the Send LDAP Attributes as Claims option is selected, and click Next.

  4. On the Configure Claim Rule page, in the Claim rule name box, type Send Name.

  5. In the Attribute Store list, select Active Directory.

  6. In the Mapping of LDAP attributes section, create the following mappings:

    LDAP Attribute Outgoing Claim Type

    SAM-Account-Name

    Name

  7. Click Finish.

  8. To close the Edit Claim Rules window, click OK.

Step 4: Test the AD FS 2.0 Proxy Solution

This test will demonstrate an operational AD FS 2.0 federation server proxy. The claims-aware application will redirect users to the FS-P, which will use forms authentication to identify the user. The security token will be generated by the internal federation server.

Note

For the best results, clear all the cookies in Internet Explorer on the Internet client computer. To clear the cookies, click the Tools menu, click Internet Options. Under Browsing history, click Delete. Select the types of items you want to delete, and then click Delete.

To access the perimeter-based claims-aware application

  1. On the Internet client, open a browser window and navigate to https://web.contosodmz.com/ClaimsAwareWebAppWithManagedSTS/.

  2. If you are presented with a Sign In page, select fsweb.contoso.com from the list, and then click Continue to Sign In.

  3. On the Forms authentication page, type administrator and the password, and click Sign In.

At this point, you should see the WIF SDK sample application. Note the presence of the authentication method claim, which states that password authentication was used. Since the internal FS uses Integrated Windows Authentication, this implies that access took place through the FS-P.

Step 5: Install RSA Authentication Agent

These steps will add the RSA Authentication Agent 7.0.2 for Web for IIS to the FS-P, for additional security when remotely requesting security tokens for accessing claims-aware applications. For more information, review the RSA Authentication Agent 7.0 for Web for Internet Information Services 7.0 Installation and Configuration Guide included with the web agent software.

Prepare RSA Authentication Manager

Before you install the RSA web agent on the web server, the RSA Authentication Manager server configuration file (sdconf.rec) must be exported to the agent host, and the new agent must be registered in the RSA Authentication Manager Security Console.

To export the RSA sdconf.rec configuration file to proxy.contosodmz.com

  1. On securid.contoso.com, click Start, click All Programs, click RSA Security, and then click RSA Security Console.

  2. After you log using with RSA Authentication Manager administrative credentials, click the Access tab, click Authentication Agents, and then click Generate Configuration File.

  3. On the Generate Configuration File page, click the Generate Config File button.

  4. On the Download Configuration File page, click the Download Now link.

  5. Save the AM_Config.zip file to a location accessible by proxy.contosodmz.com.

  6. Click Close.

  7. On proxy.contosodmz.com, locate the AM_Config.zip file you created earlier.

  8. Right-click AM_Config.zip, and click Extract All.

  9. Extract the folder to a location on the file system (this lab used the Administrator desktop).

To register the new web agent in RSA Authentication Manager

  1. On securid.contoso.com, in the RSA Security Console, click the Access tab, click Authentication Agents, and then click Add New.

  2. On the Add New Authentication Agent page, in the Authentication Agent Basics section, in the Hostname box, type proxy.contosodmz.com, and then click Resolve IP. The IP address for the proxy server will be auto-populated.

  3. In the Authentication Agent Attributes section, in the Agent Type box, select Web Agent.

  4. Click Save (located at the bottom of the page).

Install the RSA Web Agent

Installing the RSA web agent for IIS 7 requires first updating the IIS role services on the web server, as is described below.

To install prerequisite role services

  1. On proxy.contosodmz.com, in Server Manager, expand the Roles node in the left navigation tree.

  2. Right-click the Web Server (IIS) role node, and select Add Role Services.

  3. In the Select Role Services dialog, select the following role services, including all the role services under them, and then click Next.

    1. Common HTTP Features

    2. Application Development

    3. IIS 6.0 Management Compatibility

  4. Click Install to load the new role services.

  5. Click Close.

Afterward, contact RSA Technical Support and request the RSA solution a55200. The hot fix provides a new version of the web agent for IIS 7 (build 411) that works with AD FS 2.0.

When you have the hotfix, follow the instructions provided in Chapter 3 of the RSA Authentication Agent 7.0 for Web for Internet Information Services Installation and Configuration Guide to install the RSA IIS web agent on proxy.contosodmz.com.

Note

It is recommended that readers test the operation of the web agent by using the procedure described in the Testing Authentication section of this chapter.

Step 6: Configure RSA Authentication Agent

After web agent installation, the following configuration changes enable two-factor authentication for the FS-P application.

Enable Web Agent Protection

These steps enable the web agent and identify the resource we are protecting with two-factor authentication.

To enable web agent protection on proxy.contosodmz.com

  1. On proxy.contosodmz.com, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the navigation tree, in the Sites folder, click Default Web Site.

  3. In the Details pane, scroll down to the Other section, and double-click RSA SecurID.

  4. Select the Enable RSA SecurID Web Access Authentication Feature on This Server check box.

  5. In the Actions pane, click Apply.

  6. To acknowledge the warning about application pools, click OK.

To protect the AD FS 2.0 proxy application

  1. In the IIS Manager console, in the navigation tree, expand the Default Web Site and adfs folders.

  2. Click the \ls application.

  3. In the Details pane, scroll down to the Other section, and double-click RSA SecurID.

  4. Select the Protect This Resource with RSA SecurID check box.

  5. In the Actions pane, click Apply.

Reconfigure Application Pools

For RSA authentication to function, the web agent (WebID) application and any resources on the web server that one wants to protect must all use the same application pool. That application pool must use either the local computer service account (LocalSystem) or a local/domain account with Administrator privileges as its application pool identity. In this lab, we will use the LocalSystem account.

To configure application pools for RSA authentication

  1. On proxy.contosodmz.com, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the navigation tree, expand the PROXY icon, and then click Application Pools.

  3. In the Details pane, right-click RSA SecurID Pool, and select View Applications.

  4. Right-click the /WebID application, and click Change Application Pool.

  5. In the Select Application Pool dialog, click the ADFSAppPool option , and click OK.

  6. In the navigation tree, select Application Pools again.

  7. Right-click ADFSAppPool, and select Advanced Settings.

  8. In the Advanced Settings dialog, in the Process Model section, select the Identity row, and then click the NetworkService icon.

  9. In the Application Pool Identity dialog, in the Built-in account dropdown list, select LocalSystem and click OK.

  10. Click OK.

Step 7: Test RSA/AD FS 2.0 Proxy Solution

This test will demonstrate an operational AD FS 2.0 federation server proxy, protected by RSA SecurID two-factor authentication.

Note

For the best results, clear all the cookies in Internet Explorer on the Internet client computer. To clear the cookies, click Tools, and click Internet Options. Under Browsing history click Delete. Select the types of items you want to delete, and click Delete.

To access the perimeter-based claims-aware application

  1. On the Internet client, open a browser window and navigate to https://web.contosodmz.com/ClaimsAwareWebAppWithManagedSTS/.

  2. At the RSA SecurID forms authentication page, type administrator for username and the RSA passcode for the Contoso administrator account, and click Log In.

  3. If you are presented with an AD FS 2.0 Sign In page, select fsweb.contoso.com from the list, and then click Continue to Sign In.

  4. In the AD FS 2.0 forms authentication page, type administrator and the Contoso administrator account password and click Sign In.

At this point, you should see the WIF SDK sample application. A session cookie generated by the FS-P provides SSO to other federated applications during that browser session. A session cookie generated by the RSA web agent can provide SSO to other RSA-protected web applications across one or multiple web domains.