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:
- AD FS Proxy Forms-Based Authentication for Internet users
- Intranet AD FS Logon using Integrated Windows Authentication (IWA)
- UAG-based logon thru “portal” logon and RP-initiated Logon for Internet users using UAG SP1 RC.
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
- Internet connectivity (although testing via VMs is perfectly acceptable)
- Browser (IE / Mozilla)
- Forefront TMG 2010 SP1
- AD FS 2.0 Server
- AD FS 2.0 Proxy
- Relying Party (I elected to use Sharepoint 2010 in this example, although a CRM 2011 IFD also works fine… )
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
- Local Intranet/Corporate Connection
- A Browser (IE / Mozilla)
- AD FS 2.0 Server
- Active Directory
- Relying Party
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)
– 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)
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
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..