This is one of those “what if?” scenarios with AD FS 2.0 which arose at a customer recently: they wanted to provide secure logon to users in an Extranet Active Directory to web resources in their corporate Active Directory (e.g. Sharepoint). In a pure AD setup, with no third-party SSO products involved, this sort of thing has often been accomplished in the past through the use of a forest trust between extranet and corporate forests. This approach, however,  tends to make network and security departments unhappy; with all sorts of firewall ports needing to be opened, making swiss cheese of interior firewalls. With Windows 2008 R2, we can also do this sort of thing by configuring an Extranet AD FS 2.0 instance(s) in the DMZ (limiting firewall traffic to HTTPS only) and then establishing a federation (claims provider) trust between the corporate AD FS and the Extranet. This is similar to the partner or federated SSO scenarios that Microsoft describe in their documentation.  In this scenario, the Extranet AD FS instance is analogous to the Account Federation Partner and the corporate AD FS instance  to the Resource Federation Partner.

To make this process more interesting (life is never dull), it was suggested we put a UAG in the Extranet (in place of the AD FS Proxy) to support strong/two-factor authentication requirements. This meant that some form of jiggery-pokery with Kerberos Constrained Delegation would be required between the Extranet UAG instance and the Extranet AD FS farm, to ensure that groovy Web SSO experience was maintained all the way to the target web application.

Components

• Forefront UAG 2010 SP1 (extranet.mydomain.com)
• Extranet AD FS (extranet.mydomain.com)
• Forefront TMG 2010 SP1 (sts.mydomain.com)
• Corporate AD FS Proxy (sts.mydomain.com)
• Corporate AD FS Farm (sts.mydomain.com)
• Sharepoint 2010 Farm (sharepoint.mydomain.com

So we have two zones bridged by an AD FS federation trust: an Extranet Zone and a Corporate Zone.

The above is how I configured the sandpit for testing. Our example web application (Sharepoint), is configured as a claims-aware application and the client has bookmarked it as a favourite. He/she is able to link to the Sharepoint site (sharepoint.mydomain.com) directly and this is where the authentication process kicks in.  Walking through the process.

1. The client accesses the Sharepoint URL (https://sharepoint.mydomain.com). (reverse proxied through TMG). The Sharepoint web application is configured as a claims-aware web application with the Corporate AD FS 2.0 farm configured as its SP_TrustedIdentityTokenIssuer using e-mail address as the primary claim.

2. The Sharepoint 2010 security token service (STS), a relying party of the corporate AD FS 2.0 instance, redirects the client to the corporate AD FS 2.0 farm. The client is connecting from the Internet, meaning that the fully qualified domain name sts.mydomain.com (for AD FS) on the Internet resolves to a public IP address, namely that of the AD FS Proxy. The client is redirected to the proxy.

3. The corporate AD FS, with the proxy as arbiter for the AD FS farm, possesses two claims providers: the default corporate Active Directory and a claims provider trust setup to point to the Extranet AD FS instance (Partners and Affiliates in the graphic). AD FS itself cannot determine which realm the client belongs to, so when the client connects he/she home realm discovery (HRD) is performed and the client must choose between selecting the corporate or Extranet realm (this process can be automated… we’ll cover this in a later post). As a result of Home Realm Discovery, the client is thereby redirected to the services endpoint for the Extranet AD FS.  In this scenario, this translates to the public IP address of the UAG trunk.

4. With the client redirected to the UAG for logon, the UAG server(s) processes the logon request. In this example, UAG is configured to use RADIUS for authentication. This is because we’ve opted for strong authentication (using tokens). RADIUS is being used to bridge the connection between UAG (as a RADIUS client), and the strong authentication provider. The token is  submitted via an application running on a smartphone and the client enters the One-Time-Password (OTP) and PIN via the UAG form (4a).  The credentials are forwarded by UAG to the RADIUS server (4b) running on the OTP provider. In this example, the user repository for the one-time password is also the Extranet AD (4c), accessed via LDAP. The UAG server(s) are also domain members within the Extranet AD. Once the OTP logon process is complete, we can chain the logon process to perform federated back-end authentication to the Extranet AD FS instance(s), obtain a kerberos ticket from the Token Service using Kerberos Constrained Delegation (KCD).   This is possible because the UAG server(s) is trusted for delegation by the AD FS server(s).  This process is described in a previous blog post (Federated Identities with UAG 2010 SP1 and Office 365). On the Extranet AD FS, the Corporate AD FS instance is configured as a relying party. We extract the e-mail address from the AD (Send LDAP Attributes as Claims), providing this information to the relying party in a  pass-thru rule (issuance transform rules) .

5. When authentication is complete at the Extranet AD FS, an HTTP POST  by the client is submitted to the corporate AD FS Passive Federation Endpoint.  The Corporate AD FS, acting now as an FP STS, processes the claim according to acceptance transform rules configured (pass thru e-mail), before handing over to the relying party where the issue transform rules are then processed (pass thru e-mail address).

6. The client is then redirected the Sharepoint web application, the e-mail address claim is processed  by the Sharepoint STS, and they gain access to the Sharepoint site.

 

Extranet UAG Configuration

To make this configuration work on the Extranet UAG side, we have to ensure that the federated logon process is not interrupted or interfered with.  At the same time we still have to deal with the strong authentication requirement. As stipulated in previous posts, with non-federated trunk authentication we can satisfy both strong authentication requirements and federated logon to the local (Extranet) AD FS instance. This time, however, the resource lives in the corporate realm. UAG is not directly responsible for proxying connections to the Sharepoint web application. Nonetheless, there are some unusual requirements. 

On the Extranet UAG, there are three authentication providers configured:

• RADIUS/OTP Server
• Extranet Active Directory Domain Controller (can be used for Authorization by the RADIUS server)
• Extranet Active Directory Federation Services (AD FS)

The AD server is optional should you wish to use AD-based authorization groups with the RADIUs authentication server. The AD FS 2.0 server is required for the Extranet federated logon piece.

Surprisingly, there are also two web application templates that need defining:

• A Sharepoint 2010 web application using the Sharepoint 2010 template with the URL of https://sharepoint.mydomain.com
• An AD FS 2.0 web application using the AD FS 2.0 template with the URL of the Corporate AD FS instance of https://sts.mydomain.com

Each of these web applications are configured to use the Extranet AD FS server as their authentication server. Without these web applications being defined, the login process fails at the UAG with  a “request was unable  to reply to an HTTP 401 request from application AD FS” being logged within the UAG Web  Monitor. This one had be stumped for a while as UAG is not responsible  for proxying traffic to the corporate AD FS proxy or the Sharepoint web application.  I can only surmise at the moment this is done to the fact that UAG assumes the web application is behind it and therefore a corresponding application must exist.

I’ve mapped the logon process out in Visio.

If I have the time, I’ll deep-dive the entire setup in a later post. If this would be of interest to anyone, please let me know.

Mylo

UPDATE 28/06: Microsoft have updated their documentation describing partner access using federated claims to Sharepoint 2010.
http://technet.microsoft.com/en-us/library/hh285675.aspx