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
Carrying on from where we left off in the last post, let’s look at some sample scenarios for implementing mixed authentication scenarios using a combination of AD FS and third-party identity providers. As usual, the assumption is that some sort of split-DNS in the federation service namespace is available.
In this example, AD FS will act as a hybrid Security Token Service (STS). In addition to the out-of-the-box AD FS claims provider (IP-STS) role, AD FS must act as a Relying Party Security Token Service (RP-STS) for two claims providers; the first where it trusts a SAML capable two-factor authentication claims provider, the second where it trusts a gateway portal that provides IdP-initiated sign-on.
In the above diagram, note the use of split DNS to differentiate between user experience inside and outside of the organization; namely, internal resolution of the AD FS federation services endpoint points to the AD FS farm, whilst externally resolving to the AD FS Proxy(s).
Here are the sign-on use cases:
External SP-initiated Sign-On
A1 – Client accesses Web Application
A2 – Client is redirected to AD FS RP-STS for processing (A2-1)
A3 – Client is redirected to 2FA Provider for logon.
A4 – Following successful authentication at 2FA, client SAML assertion is passed to AD DS RP-STS for claims processing.
A5 – Client is redirected to Web Application (RP)
External IdP-initiated Sign-On
B1 – Client accesses IdP-capable Portal
B2 – From the portal, client selects bookmarked Web Application (Smart Link)
B3 – Client is redirected to IdP to determine whether user has valid logon token for SSO
B4 – Client is redirected to AD FS RP-STS for claims processing
B5 – Client is redirected to web application (RP)
Internal RP/SP-initiated Sign-On
C1 – Client accesses web application
C2 – Client is redirected to local AD FS IP-STS for processing. AD is set as default realm via customization (no realm selection allowed)
C3 – Integrated Windows Authentication (IWA) is performed at STS and claims are processed.
C4 – Client is redirected to web application (RP)
To make the above scenarios work, some minor customization is needed. The first barrier that we hit is home-realm discovery. If AD FS trusts two additional claims providers, besides Active Directory, how can authentication requests be routed correctly?
The answer rests partly with tweaking the AD FS proxy and farm configuration, the other in the way the Portal IdP calls AD FS. The customization on the AD FS side is relatively straightforward.
Let’s look at each access scenario:
1. External SP-initated sign-on
In external scenarios that are initiated at the relying party or service provider, we want to use the strongest authentication possible, our 2FA provider. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting the following line on the Page_Init section.
SelectHomeRealm(https://idp.mydomain.com)
2. External IdP-initiated sign-on
IdP-initiated sign-on envisages the use of access gateway solutions such as Juniper SA / Citrix CloudGateway. In these scenarios the user authenticates to the gateway using the authentication mechanism required by the organization. Access to back-end applications is then performed using service provider initiated sign-on. Having already authenticated at the gateway, with the gateway configured as a claims provider on the AD FS side, the user is not prompted for credentials again and SSO to the application is provided.
This scenario has some interesting use cases. It allows the organization to use a different authentication method for accessing the gateway IdP than via the service provider initiated sign-on route (2fa). If the gateway employs some form of endpoint component checking and machine validation, then the organization may wish to adopt a more lenient access and user friendly authentication mechanism for managed/trusted devices (e.g. username/password).
Integration with AD FS is accomplished through using smart-links and selecting both the claims provider, via the home realm parameter (whr), and the relying party (wtrealm), in the query string, e.g.
NB: I’ve omitted Forefront UAG in this list as its relationship with AD FS is that of a relying party rather than an identity provider. Redirects using the whr= parameter to a stronger authentication provider than AD FS are possible.
3. Internal SP-initated sign-on
In this scenario, we want the relying party of SAML 2.0 service provider to select the Active Directory authentication provider, rather than the other two trusted claims providers. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting the following line on the Page_Init section.
SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );
This will automatically select the highlighted item, the native provider always the first chosen.
Summary
In this post we’ve looked at supporting multiple claims providers for AD FS with the minimum of customization. Changing the homerealmdiscovery.aspx.cs file on the AD FS farm ensured all internal authentication requests are passed to Active Directory. Similarly, externally, we specified the realm the AD FS proxy should use to select the 2FA provider. With home realm discovery now set both front and back-end servers, additional claims providers that support IdP-initiated sign-on may be used and invoked through smart links.
I was at a a customer recently where they were experiencing a problem with DirectAccess; roaming users, home or travelling, would suddenly lose their DirectAccess connection. Investigation revealed that these were IP-HTTPS users that were working out of office and their connections would mysteriously drop. These were normally Teredo clients but there are documented scenarios of Teredo quirks that cause a fail back to IP-HTTPS. The users in question had been travelling and logging on on other corporate LANs so fallback to IP-HTTPS was plausible (the ins and outs of Teredo behaviour can be found in the following blog entry):
On the IP-HTTPS side, we were noticing that the tunnel negotiation and setup was failing. Logs from the user(s) experiencing the problem were captured via the DirectAccess Connectivity Assistant. The details in the IP-HTTPS portion of the log were revealing:
https://access.mydomain.com:443/IPHTTPS Last Error Code : 0x80092013 Interface Status : failed to connect to the IPHTTPS server.
The Certificate Distribution Point (CDP) of the online Issuing Certification Authority could not be reached (error code 0x80092013).
The Certificate Distribution Point (CDP) offline message turned out to be misleading. The CA CDP was online and reachable, but investigation revealed a key omission in our configuration. The CDP of the Issuing CA URL was not in the Direct Access tunnel exemptions list. This meant that every X hours or so the CRL cache on the local Windows 7 clients was expiring. When the client did need to obtain a fresh CRL from the CA, it failed because of a race condition where the client was unable to setup the infrastructure tunnel because the server authentication certificate issued to the IP-HTTPS listener (running under IIS) could not be validated as the CA CDP was unreachable and the CRL not downloadable because the tunnel hadn’t been established (loop to infinity)…..
Lessons learned:
Nice!! 
Regards,
Mylo
I wrote in previous posts about some of the more unusual access scenarios involving Office 365 and UAG with AD FS 2.0. In doing so I’d not gone through and covered setting up a basic federated trunk scenario using UAG, AD FS 2.0 and Office 365. With this post I’ll attempt to remedy that.
In a normal O365 federated identity setup, UAG would be configured as a relying party to provide single sign-on to web applications at the edge. As a relying party UAG then processes security tokens issued by the AD FS security token service. For UAG admins, there is a key difference in the way UAG works with AD FS compared to other authentication services. Normally speaking, it is the UAG that is directly responsible for front-end authentication. Here, however, UAG adopts the role of an AD FS proxy and uses the AD FS infrastructure to provide the authentication and process the requisite claims required for single sign on to back end web applications. There is no authentication taking place on the UAG. This is borne out when we look at the web application configuration the for the trunk, with UAG configured like any other claims-aware application or relying party.
On the AD FS web application itself, we must allow unauthenticated access to the AD FS web server / farm
Additional authentication services cannot be used on the same trunk. Also, unlike the AD FS proxy, UAG does not provide a forms-based logon page. Instead it uses challenge/response. So a user who is accessing O365 from a non-domain joined machine can expect to an NTLM challenge response.
Because UAG does not process AD FS authentication, the request is proxied to the AD FS service in the backend using the Integrated Windows Authentication (IWA) handler. This can be seen in the redirect to https://sts.mydomain.com/adfs/ls/auth/integrated/……
Connecting to an Office 365 web resource from the Internet with a domain joined machine on the Internet, users can logon via IWA and get the single sign-on experience to the O365 resource when the STS is in the Local Intranet zone of the browser. Looking at Fiddler, one can see a kerberos service ticket in the negotiate header.
No Proxy-Authorization Header is present.
Authorization Header (Negotiate) appears to contain a Kerberos ticket:
60 82 06 38 06 06 2B 06 01 05 05 02 A0 82 06 2C `‚.8..+….. ‚.,
30 82 06 28 A0 30 30 2E 06 09 2A 86 48 82 F7 12 0‚.( 00…*†H‚÷.
01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 06 0A …..*†H†÷……
From a non-domain joined machine, the fact that we’re doing IWA and and Negotiate means that it falls-back to NTLM (and the logon challenge/response)…..
No Proxy-Authorization Header is present.
Authorization Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 NTLMSSP………
96 00 00 00 60 01 60 01 AE 00 00 00 00 00 00 00 –…`.`.®…….
Whether you like the idea of challenge/response over form-based logon is down to personal preference 
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
In recent posts, I’ve been flicking between two configuration states on two different trunks:
I’ve been using two ADFS instances in the back-end, testing various combinations using the mythical sts.mydomain.com and sts1.mydomain.com endpoints.
There is one limitation that becomes very clear during testing:
an AD FS instance may be used by a single trunk only
AD FS instances cannot be shared across trunks. What !@#!.. that’s crazy!! Well, not really.. When you consider that UAG is proxying federation services endpoints, this does make a lot of sense. We cannot arbitrarily share instances of our federation service across different trunks, because that goes against the very nature of a federated trust. It can be represented in one and only one place. When we try and share the same service across multiple trunks, UAG chucks out the following message:
The AD FS authentication server ‘AD FS 2.0 …" is used in more than one trunk: TrunkA, TrunkB. Configure the UAG to use the AD FS 2.0 authentication server in one trunk only.
Which reminds me of something else I needed to post………………………
Following recent posts and discussions on the Office 365 forums, it seemed like a good time to look at integration between UAG 2010 SP1 and AD FS 2.0 and logon scenarios using Office 365 beta. Not much has been written about this to date, so I’ve been wading through the pre-production landscape of Office 365, trying to come terms with the complexities that these co-existence scenarios can bring.
Since UAG 2010 SP1, Microsoft have provided out-the-box support for AD FS 2.0. For Office 365 as a claims-aware platform, this gives us an opportunity for integrating UAG and AD FS 2.0 on-premise with Office 365 Enterprise web applications. UAG 2010 SP1 supports the WS-Federation passive profile, allowing for Office 365 web apps to be published through the UAG portal.
Microsoft highlight a number of integration topologies in their Forefront UAG 2010 SP1 with AD FS 2.0 documentation.
http://technet.microsoft.com/en-us/library/gg274298.aspx
From an Office 365 perspective, there are two topologies in the above link that had particular resonance for me in testing:
1. Remote employee access using claims
UAG is configured as a relying party for an on-premise AD FS 2.0 server (Resource Federation server in the diagram). Remote users authenticate to both the UAG trunk using and also the back-end application using claims-based authentication.
2. Remote employee access using non-federated trunk and federated application authentication
In this configuration, users connect to the UAG trunk using non claims-based authentication, for example, strong/two-factor authentication. They then authenticate to the published application using federated authentication. This configuration is the supported two-factor authentication that the Office 365 documentation alludes to. If the front-end authentication solution uses a separate user database from the Active Directory, then also consider that some form of matching shadow accounts are required within Active Directory (remember that AD FS uses AD as its authentication repository) to bridge access between front and back-end.
Why use UAG?
If you’re wondering what benefits UAG may offer with Office 365.
There are some limitations that you should be aware of. When Microsoft refer to the WS-Federation passive profile, they’re talking about UAG and the browser, meaning Outlook Web App, Sharepoint Onlne and the Office 365 administration portal. The sign-in experience that we’re referring to in this post is with federate identities. In this scenario a user may access the Office 365 sign-in service. The service determines that the domain name referred to (via the UPN) is part of a federated domain and accordingly redirects the user to the on-premise Active Directory Federation Server (AD FS) 2.0 instance. Where UAG is in front of AD FS, this call is intercepted because the UAG is in-line for processing traffic.
Pre-requisites
There are a couple of pre-requisites for our UAG/O365 configuration.
AD FS 2.0 Single Sign-On for Office 365 has been prepared:
* This option is not mandatory and one could argue against its use in the federated trunk scenario, as we’re doing full claims authentication, i.e. domain membership is not really necessary. For the purposes of this post, however, we’re using AD domain-membership to perform kerberos constrained delegation for the non-federated trunk configuration scenario.
Configure an AD FS 2.0 Authentication Server
Both UAG access scenarios require the services of an AD FS 2.0 authentication server. This can be done during trunk creation or, in this example, from the Admin menu, by selecting Authentication and Authorization Servers.
To create the relationshjp with AD FS 2.0, we must create an authentication server, obtain federation metadata from AD FS and then define the claim that will be used as the lead value (of interest).
Add an ADFS 2.0 Server. In the example below, I’ve created an Authentication Server calling Training, pointed it to the on-premise AD FS 2.0 Server / Farm at (https://mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml). I then retrieved the metadata from this URL and then selected Name to be the attribute of interest.
NOTE: If you get an error while retrieving metadata stating “the Federation Metadata is signed, but the UAG server does not trust the certificate”, check that the Token Signing Certificate, if it is self-signed, is imported into the Trusted Root Certification Authorities store of the UAG. Alternatively, if there is a certificate chain involved, via an internal authority, ensure that the corresponding chain is imported. Any PKI CDP URLs for internal issuing authorities should be visible/reachable. You may need to edit the underlying TMG CRL Download System Policy to ensure it is checked.
Once the authentication server has been created, it can be referenced for usage within a trunk. This can be:
I’ll cover the federated trunk configuration first and the hybrid configuration immediately after.
Federated Trunk (Remote employee access using Claims)
In this configuration we define the ADFS security token service (STS) as an identity provider and authentication server for UAG
In the example below I created a trunk with the name of ADFS
As the above summary screen warns, the UAG relying party must be configured in AD FS. This needs to the point to the UAG URL assigned by the wizard,. This URL must be the public (external) address of the (federated) trunk.
You can review the Advanced Trunk Configuration afterword, under the Authentication tab to confirm the configuration information for the UAG relying party necessary in AD FS.
For example,
Realm: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS
Federation Metadata: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS/FederationMetadata/2007-06/FederationMetadata.xml
The STS should be reachable through the internal DNS of your organization, i.e. UAG is configured to use internal DNS and not external DNS.
Configure AD FS 2.0
In AD FS 2.0 we need to add a relying party trust.
Add the federation metadata endpoint described in the previous section. This needs to point to the (external) trunk. Before this will work you’ll need to create HOSTS file entry(s) on the AD FS server(s) pointing to the UAG federated trunk. This enables AD FS to resolve the address of the relying party. Remember that the UAG federation trunk URL is proxying traffic to the AD FS federation services endpoint (sts.mydomain.com) and internally that resolves to the AD FS farm/server(s). We need the AD FS to be able to reach and resolve the UAG address.
Having created the HOSTS file and successfully connected to the UAG relying party, we need to create a claim rule for the UAG. In this example, I’ve created a simple Pass-thru claim that passes thru the Name attribute.
Now we’re set to create an Office 365 web application… skip the next section and go to Configure an Office 365 web application.
Non-Federated Trunk (Remote employee access using non-federated trunk authentication and federated application authentication)
Non-federated trunk mixes authentication protocols between front-end and back-end systems, namely:
The initial configuration for this scenario should be familiar if you’ve used UAG or IAG before as we select one of the classic supported authentication protocols (e.g. LDAP, AD, RADIUS, SecurID etc). For the purposes of this article, the front-end authentication type (RADIUS/LDAP etc) that we settle for is not important.
In this example, I’ll be using a front-end authentication process through RADIUS. It helps for purposes of demonstration to choose a different front-end authentication provider, e.g. a 2FA OTP provider, from that of the the back-end provider (AD FS). In this setup, therefore, I’m using an OTP solution (Pointsharp ID) with software tokens.
Generating an OTP code from my smartphone, I enter my user ID and OTP to successfully complete the logon process. However, for this process to work correctly, we need to integrate AD FS 2.0 as a back-end authentication provider.
To setup AD FS 2.0 in a non-federated trunk scenario, we need to add it in UAG via the Add Application wizard. In this configuration, AD FS does not “live” on the trunk; rather, it exists as a web application.
From the Add Application Wizard, select the Active Directory Federation Services 2.0 template.
I’ve used the defaults here until Step 5. On the web servers screen fill out the details for the AD FS server/farm address. Enter the FQDN of the federation service, e.g. sts.mydomain.com
The server address (FQDN) and the public host name assigned must be the same.
On Step 6 – Authentication, leave the SSO checkbox unchecked, we’ll fill this in in a moment.
On Step 7 – Portal Link, leave the Add a Portal and toolbar link unchecked (we call the application implicitly through the published relying party web application).
Once the application has been created, enter the application properties and click on the Authentication tab. Check the SSO tab and change the radio dialog to Use Kerberos constrained delegation for single sign-on. AD FS uses an application pool identity for the farm AD account, so the http://* application SPN should be used.
NOTE: When AD FS 2.0 is configured for trunk authentication, you may notice the between the way that it is configured when non-trunk authentication is done on the front-end and claims authentication in the backend. In the latter configuration, as the above graphic indicates, we’re using Kerberos constrained delegation to trigger the logon process (to AD). In the federated trunk scenario, however, we’re doing pure claims-based authentication. In this configuration, the checkbox Allow unauthenticated access to web server is checked.
This actually does make sense. In the federated trunk scenario, UAG is in essence claims-aware and needs to allow unauthenticated proxy requests to reach the web server so that logon can be initiated.
Configure an Claims-aware application (Office 365)
To add a claims-aware web application within UAG, there are a number of steps involved:
In this example, we’ll use Outlook for Web Access (OWA 365) as a sample web application. The inbuilt Exchange 2010 wizard doesn’t work in this scenario so we’ll create a web application using the portal trunk..
In the Applications window, click on Add to Launch the Add Application Wizard
At Step 1, Select an Application, choose Web | Other Web Application (Portal Hostname)
Give the application a name and select whether the endpoint policies you wish to enforce. I’ve used the defaults until Step 5 – Web Servers. In the addresses box here enter: www.outlook.com .
On Step 6 Authentication, check the SSO checkbox and select the AD FS 2.0 server created earlier as the authentication server.
In Step 7, enter the URL for your Outlook for Web Access 365 web application
In the above I’m using https://www.outlook.com/owa/mydomain.com as an example.
Summary
The processes described above support portal-initiated logon (via the UAG) and also relying-party initiated logon from the Microsoft online website itself.
As ever, please read the documentation on the Office 365 website as those gaps are being filled every day. Oh…and validate your single sign-on usage scenarios!!!
http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652538.aspx
As always, if you have any comments, corrections, questions or have some insight on this subject , please contribute!
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 