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
29/04/2013: I received feedback from readers that this original article had become corrupted, so I’m reposting it.
In the previous post I was looking at how to configure AD FS 2.0 with UAG 2010 SP1 RC and publishing Sharepoint through it in a straight claims-based authentication access scenario. This time we’re going to mix authentication protocols. As ever, do this in a test environment/sandpit, where a wrong move might not necessarily be your last 
Back in Q4 2006/Q1 2007, Stefaan Pouseele, an ISA Server MVP, helped out when I was trying a few access scenarios using ISA 2006, RADIUS and Constrained Delegation. He had been blogging about the concept of using a cheap RADIUS OTP solution with ISA and RADIUS. The gist of the solution was that it was possible to authenticate against a user database in the DMZ through RADIUS and then ISA’ support for kerberos constrained delegation to provide access to resources within the corporate Active Directory domain by using corresponding shadow user accounts. At the time I tested this out using ISA, RADIUS and Exchange and it worked a treat.
Here is the link to his original article:
The advantages were:
There were downsides.. someone had to manage the DMZ ID’s .. shadows accounts had to be created on a 1-to-1 basis, doubling the management overhead. Nonetheless, it worked pretty well at the time with Exchange ActiveSync and mobile devices.
Roll on 4 years ago and testing with UAG 2010 SP1 reminded me of those earlier ISA scenarios. This time, however, the participants are UAG 2010 SP1, AD FS 2.0 and Sharepoint 2010. We’re still doing front-end authentication (this time with claims) and now transitioning kerberos to the back-end Sharepoint web app.
Objective
This post describes publishing applications through the Forefront Unified Access Gateway (UAG) 2010 SP1 using claims-based trunk authentication at the front-end and Kerboros Version 5 at the back-end. In this setup, a user will logon via AD FS and the UAG will then request a Kerberos ticket on behalf of the user and use that ticket to authenticate to the published kerberized application.
AD FS in this setup is our UAG trunk authentication provider. Our test web application in this case is a Sharepoint 2010 web application, with the application configured to do Negotiate (Kerberos) authentication.
The UAG SP1 documentation describes the broad process of what needs to occur but focuses primarily on using shadow accounts for federated logon (with a 3rd party). I’ll look at this approach in a later post. Initially, I was more curious as to see how this would work against a native local AD directory using “corporate” AD credentials for AD FS to parse at logon and UAG delegating those credentials via Kerberos to a web application.
We’re mixing and matching authentication here, using claims-based authentication at the edge, and then Kerberos as an enterprise protocol for authenticating to our web application, i.e. UAG is federation-aware but SharePoint is not. This is pretty cool. It means that AD FS can be used to handle Web SSO, whilst leveraging UAG to provide connectivity to applications using delegated credentials (in this case Kerberos).
System Setup
This is what was used in the “sandpit”.
The AD FS 2.0 Proxy might appear surplus to requirements. You could for example turn on Forms-Based Authentication in the web.config of the AD FS farm, but in my test sandpit the application is configured for Integrated Windows Authentication (IWA) to test local AD SSO. The proxy, by definition, will do forms-based authentication and therefore fits the profile for claims-based trunk authentication via UAG.
External DNS Settings
UAG is, in effect, in-line for processing of all traffic. So, when a user points their browser to https://teams.mydomain.com, the UAG intercept the request, does the necessary access/compliance checking, before the trunk handles the claims-based authentication logon process and redirect to AD FS (UAG is a relying party within AD FS).
If multiple claims providers are configured (as in this sample), then Home Realm Discovery (HRD) in AD FS may kick-in and the user selects the appropriate home realm for logon. In this test, I’m using the local “corporate” Active Directory for authentication. In subsequent blogs, I’ll extend this out to a federated trust (3rd party or Extranet AD / AD FS instance).
Having selected the corporate realm, let’s logon with our test user 280368.
After successful logon AD FS server (sts.mydomain.com) redirects the browser to the UAG instance, in this case: https://portal.mydomain.com/InternalSite/ADFSv2Sites/federation/Default.aspx)
Post-validation occurs before the user is then authenticated against Sharepoint
And we’re in.. let’s have a quick look at the user settings:
The i:0#.w|MYDOMAIN\280368 account value is our Kerberized logon. As can be seem from the screenshots, I set out doing this test with Sharepoint 2010, configuring a Sharepoint 2010 teamsites web application to use Integrated Windows Authentication (IWA).
As can be seen from the above screenshot, I’ve configured the SharePoint web application in UAG to use Kerberos Constrained Delegation for single sign-on (with an SPN of http/*). This doesn’t mean that I’m no longer using AD FS, rather I’m doing AD FS logon at the trunk and then delegating logon: translating the Name claim extrapolated from AD FS and pass the value onto Active Directory as the shadow account user. Microsoft call this Federated trunk with non-federated web applications.
Aside from the above screenshot, I amended the web application on my portal trunk from the previous blog. For validation, here are the settings on each tab of the web application:
NB: I’ve set teamsites to be my initial internal application also for the trunk (see below)
One additional change that I did do, as the Portal link section alluded to, I’ve set the Teamsites application as my home application on the main trunk configuration page.
AD FS 2.0 Settings
Within AD FS, there should be a relying party setup pointing to the external interface of the UAG (as described in the previous blog post).
In addition, the following claims rules are setup on the Relying Party (Name is the key):
IIS Settings
For reference purposes I’ve included IIS settings. I’m not suggesting that you set your Sharepoint web application settings via IIS manually; rather, it can be useful to see the end-product/result in IIS
Authentication Advanced Settings
Sharepoint 2010
I did setup an SPN for teams.mydomain.com using the corresponding Sharepoint service account for the MOSS web application, e.g.
Setspn –S http/teams.mydomain.com MYDOMAIN\sa_apppool1
Under Authentication Providers in Sharepoint, I turned off the AD FS Trusted Identity Provider I’d configured in the previous blog entry and now re-enabled Windows Authentication, setting Integrated Windows Authentication and Negotiate (Kerberos).
I’d mostly definitely recommend testing the Sharepoint web application internally before playing around with UAG. Use IEHTTPHeaders or HTTPWatch or a similar plug-in to ensure that Kerberos is working and that the browser is not downgrading authentication to NTLM. This is key to avoid any sort of spurious errors within UAG … errors along the lines of “you do not have permission to access this folder” spring to mind
Within Sharepoint, for test purposes, I also added the Domain Users built-in group to the site visitors group
Not the most secure configuration, but good for testing
So what are the benefits of this approach?
Regards,
Mylo
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 