Thanks for those folks who notified me that some of the 2010 articles on the blog have become corrupted. The two original posts have been lovingly restored after applying some TLC.
November 4th 2010 posting: AD FS – Inside and Outside
December 3rd 2010 posting: The Triumvirate – UAG 2010SP1, AD FS 2.0 and Kerberos
Cheers,
Mylo
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
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:
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:
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
If you’ve had the good fortune of setting up AD FS 2.0 in the last few months, then no doubt you’re seeing the various capabilities and nuances of such a solution. As a new product though, while “free”, working with such technology can be frustrating. Not having the pleasure of seeing someone else going through that pain barrier that you are, nor being able to learn from someone else’s mistakes rather than yours, can make for difficult times … Nonetheless, I’ve been running various sandpits and configurations now since Q4 2009 (with admittedly varying degress of success) and I really had been meaning to make note of some of this earlier.. it was the recent release of UAG 2010 SP1 RC that provided the necessary motivation.
In this post I’m describing Web SSO scenarios, using a single corporate Active Directory for internal and external access. I look at a few possible approaches:
I’m using split-DNS in my test sandpit.. mydomain.com registered (A) records point to the AD FS proxy and the TMG in Scenario 1 for AD FS and Sharepoint respectively. In Scenario 3, the UAG portal trunk is the destination for both AD FS and Sharepoint. Scenario 2 has the A record for the AD FS STS pointing to the internal AD FS farm and the internal Sharepoint web farm(s).
Scenario 1 – Internet Access
Prerequisites
sts.mydomain.com – pointing to the Internet registered (A) record for the AD FS Proxy
teams.mydomain.com – pointing to a RP (e.g. Sharepoint 2010)…
I used TMG in the sandpit to protect my relying party (Sharepoint)…. It’s worth noting that TMG is acting as a simple Reverse Proxy here. There’s no pre-authentication on the web listeners, no FBA, no Windows Auth. The user is logging on via the AD FS proxy, before they can gain access to the Relying Party (via TMG). If that’s not clear enough… let me put it another way .. TMG is not involved in the logon process at all … i.e. AD FS based logon thru TMG is not a supported configuration (not to mention I can’t get it working either). There are, however, still potential advantages to be had, in using the TMG as the reverse proxy; namely in protecting the relying party (Network Inspection System and Enhance Malware Protection spring to mind).
As a footnote, I ended up using a wildcard certificate for testing in this scenario ; a single web listener on TMG will suffice with multiple web publishing rules per relying party (in this case per web application in Sharepoint 2010). Note that it is possible to put the AD FS proxy itself behind TMG and this works (although this adds another SSL hop to the access equation) and again, there’s no authentication configured on the listener.
Scenario 2 – Intranet/Internal Users: Integrated Authentication : IWA and AD FS
Prerequisites
In an Intranet scenario, we can leverage the SSO capability that AD and WIF can offer through integrated authentication. The client is using local DNS and is pointing directly to the AD FS farm rather than the proxy. In this example, I’ve added the STS needs to the local Intranet zone. If you’re using Mozilla in your tests here, you’ll need to go into about:config in the browser and add the STS to both the network.negotiate-auth.delegation-uris and network.negotiatea-auth.trusted.uris for Kerberos to work.
Scenario 3 : Internet Access (with UAG)
Prerequisites
– All the above plus UAG 2010 SP1 RC
When I saw that UAG SP1 (RC) now supports AD FS 2.0, I danced a little jig (albeit in my mind… I am at best, sadly, a poor dancer… my right leg is a PC, my left is a Mac…..that’s how well they get on)…. Anyway, with UAG 2010 supporting AD FS 2.0, this little offering enhances the use case at the edge.
As the name suggests with UAG, this is unified access… so all access in this scenario is thru said gateway. In this capacity, UAG (portal.mydomain.com) is a Relying Party. As the SP1 RC documentation, recommends, I created a trunk and configured AD FS as an authentication provider in UAG.
There are two access scenarios with UAG here. The first is accessing the portal trunk itself with the application available on the UAG portal, the second is calling the application directly (RP-initiated logon)
Portal-based Logon
Logging in thru portal.mydomain.com, I’m entering the UAG URL directly rather than the application (teams.mydomain.com).
First time I logon, I elect to trust the site for this session… (all the UAG ActiveX controls were installed earlier)…. because my AD FS test rig is configured with two test claims providers, Employees and Partners, we need to go thru Home Realm Discovery.. I’m logging into Employees.. (Partners is another IdP)
Login with user ID and password at the AD FS Proxy
Now we’re in the UAG portal screen
I select the “Teamsites” application and off we go and we’re in Sharepoint
RP-Initiated Logon
This process incorporates less steps and is a more likely usage scenario particularly with users bookmarking the relying party in the browser.. duly noted… here I access a Teamsites favourite that I’ve created in my browser of choice; taking me to https://teamsites.mydomain.com.
Again, I go thru Home Realm Discovery (HRD) and select Employees
Forms-based Logon at the AD FS Proxy using my trusty user ID.
This time there’s no Portal rendition, and it’s straight into the application.
UAG Configuration Notes
Here’s some barebones configuration notes.. this is not a step-by-step, rather a summary of the salient points (as I recall them)…
Create a new portal trunk and under this trunk (e.g. portal.mydomain.com) create our authentication server using the new AD FS 2.0 Server Type.
Retrieve the federation metadata and select a leading claim value (I’ve used Name). This will automatically create a new AD FS 2.0 application and Application Type .. make a note of the UAG Relying Party endpoint.. this is required when configuring the Relying Party in AD FS….. syntax is along the lines of..
You can test availability of the metadata via the browser.. note that this must resolve to the external trunk address rather than any internal address of the UAG server (this is mentioned in the documentation).
After it’s created we can pop in and look at the application properties… I didn’t have to change any settings within.
At this point it was time to create an application in UAG for our test Teamsites application… as can be seen from the subsequent shot.. we elected to use the AD FS authentication server here..
Incidentally, I elected to check the Portal and toolbar link checkbox as I wanted to test accessing the Sharepoint application thru the portal itself (as described earlier).
A couple of final notes…
Make sure the UAG portal URL, the AD FS STS and the RP are in the same browser zone otherwise spurious errors such as the one below will appear. Again, the help file does mention this, but ….
I used Local Intranet Zone as I have an Intranet access scenario (2) which uses Kerberos-based logon..
I’ve also tried this configuration from the Internet using a Windows 7 domain joined client using DirectAccess and everything works smoothly with integrated auth … great stuff..
The UAG RC documentation states that you can configure AD FS to use forms-based authentication, however, UAG does not support this configuration by default. Now I initially read this as meaning that the FBA is not supported, however, that didn’t make much sense to me so I assumed that I’d misinterpreted the meaning of the RC documentation and chose to ignore it 
…
Next test stop is either going to be KCD testing with Shadow accounts (which looks pretty interesting ) or adding the CRM 2011 Beta IFD to UAG…
Hope this helps somebody/somewhere..
Mylo
The Access Onion 