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:
pre-authentication at the listener
perform regex expressions in RADIUS to strip/modifying incoming request
user lockouts occur on the remote DMZ user database, not the corporate Active Directory user ID
use smartcard for logon checkbox on the “shadow” domain user account to set automatic long passwords on the user; useful, if 3rd party IDSs need to be created for partners who don’t need AD logon credentials
reduce “surface area” of risk should theft of the device occur (e.g. Windows Mobile Smartphone)
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.
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).
This is what was used in the “sandpit”.
- UAG 2010 SP1 RC
- AD FS 2.0 RTW
- AD FS 2.0 Proxy
- Sharepoint 2010 Web Application
- Local Active Directory of which all the above are domain members (except the AD FS Proxy)
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
- portal.mydomain.com : 192.168.100.1
- teams.mydomain.com : 192.168.100.1
- sts.mydomain.com : 192.168.100.1
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:
- General : Default
- Web Servers tab
- points to internal FQDN / Load Balanced VIP of the Sharepoint web farm
- public name is set to teams.mydomain.com
- Authentication (as per graphic)
- Use SSO checkbox is ticked
- Use Kerberos Constrained Delegation for Single Sign-on radio dialog is selected
- Application SPN is set to http/*
- KCD Value Name is set to Name
- Download/Upload : Default
- Portal Link
- Add Portal and toolbar link is unchecked
NB: I’ve set teamsites to be my initial internal application also for the trunk (see below)
- Authorization : Default (at the moment)
- Web Security : Default
- Cookie Encryption : Default
- Endpoint Policy Settings : Default
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):
- Pass thru Name
- Pass thru Role
- Pass thru UPN
- Pass thru E-Mail Address
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
- SSL Host header is set to https://teams.mydomain.com
- Wildcard certificate is set on the Sharepoint website
- SPN set to the FQDN of the Sharepoint web application pool (service account)
Authentication Advanced Settings
- Extended Protection = Accept
- Kernel Mode Authentication = True
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?
- Front-end authentication protocols may differ from back-end authentication protocols. For ISA/TMG/IAG/UAG admins, this is a familiar concept, but it can now be applied to federation protocols at the front-end.
- It provides a means of projecting claims-based identities to “legacy” web applications that are not claims-aware or are not ready to step over to claims. This allows us to extend the federation concept to legacy applications.