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
The above error surfaced recently when logging in at an O365 tenant. While the message itself is a fairly generic one, and can be attributed to a number of possible causes, in this case the organization (using identity federation) had an expired token signing certificate in their AD FS 2.0 configuration. They had automatic certificate rollover disabled on their AD FS farm so that AD FS could not rollover the configuration with new certificates. For some organizations, with web applications such as Sharepoint 2010, this may be a desirable configuration, with the process of certificate rollover being manually administered, rather than AD FS silently and automatically handling it.
Hindsight is a wonderful thing in this case and paying heed to warning messages about expiring certificates in the event logs in the preceding weeks may well avert some nasty surprises. However, calamities happen and should this problem evade your radar in the future, looking at what recovery options are available may be useful.
When the token signing certificate is due to expire (2-3 weeks before), the AD FS 2.0 Admin Event Log will begin to blurt out warning messages (Event ID:385).
AD FS 2.0 detected that one or more certificates in AD FS configuration database need to be updated manually because they are expired, or will expire soon. See additional details for more information
Additional Details:
Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ is set to expire on 12/30/2011 1:00:00 AM.
Should the warnings be ignored, and the certificate has expired, the Event ID 385 warning changes to:
Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ expired on 12/30/2011 1:00:00 AM.
At this point the AD FS wheels are wobbling and an Event ID 381 may start popping up:
An error occurred during an attempt to build the certificate chain for configuration certificate identified by thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’. Possible causes are that the certificate has been revoked or certificate is not within its validity period.
The following errors occurred while building the certificate chain:
MSIS2013: A required certificate is not within its validity period when verifying against the current system clock.
User Action:
Ensure that the certificate is valid and has not been revoked or expired.
This may be followed closely behind by Event ID 102:
There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate, String id, Boolean clone, Boolean disposable)
at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate)
at Microsoft.IdentityServer.Service.Configuration.MSISSecurityTokenServiceConfiguration.Create(Boolean forSaml)
at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.ConfigureWIF()
at Microsoft.IdentityServer.Service.SecurityTokenService.MSISConfigurableServiceHost.Configure()
at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.Create()
at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.StartProxyPolicyStoreService(ServiceHostManager serviceHostManager)
at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.OnStartInternal(Boolean requestAdditionalTime)
As the original title graphic intimated, federated logon at this point is not working.
Depending on your AD FS configuration you may have automatic certificate rollover enabled. This can be checked via Get-ADFSProperties
In this particular case it was set to:
This meant that that once the signing token certificate expired, a replacement was not automatically assigned. In this case a new certificate needs to be provisioned manually. Of course, you could also elect to activate the autocertificaterollover function.
Preparing to make the change
Whether you elect to go the manual or the automatic route, in either case, you’ll still have some investigation to do. Before nuking your AD FS configuration, consider the impact of assigning / replacing the token signing/decryption certificates in AD FS.
Of course, if you’re facing a production federation service outage then there’s likely to be other pressures to consider as well 
, but try and determine which relying parties or claims providers will be able to process the details of the change (automatically) via updated federation metadata exchange or not. In the case of the latter, some sort of manual intervention may be required. Applications, for example, such as Office 365 and Sharepoint 2010 will need to be informed of this change.
Option 1: Manual Rollover
Via this method, you can generate your own certs using the Self-SSL feature built into IIS 7.x, or use Keytool, OpenSSL etc.. Alternatively, you may have your own internal PKI. I don’t see any benefit in using a third-party certificate for token signing encryption/decryption. No doubt someone out there may have a valid reason for doing so, but self-signed certs / internal PKI serve the purpose in this scenario. With IIS, under Service Certificates, I opted to create a self-signed certificate
Give the certificate a recognizable “friendly” name and IIS creates the certificate.
If you’ve elected to use an internal PKI, then there may be a certificate chain involved. Claims providers or relying parties will require a copy of the corresponding chain (.P7B) file or individual CA (.cer) files. The AD FS service account needs to be able to manage the private key of the certificate. This can be accomplished through the MMC Certificates|Computer snap-in. Right-click over the certificate:
Select Manage Private Keys and give the AD FS service account Full Control to the certificate. Now you need to prepare to make the change.
Option 2: Automatic Rollover
To configure automatic rollover:
Set-ADFSProperties -AutoCertificateRollover $true
To trigger an automatic replacement of the existing certificates the following needs to be entered.
Update-AdfsCertificate –Urgent
BEWARE! By selecting the urgent option you are voluntarily hitting the self-destruct button and hosing any working configuration. Relying parties and claims providers will not have refreshed their federation metadata with you and at this stage will be working against stale metadata. It is best, therefore, to carry out these activities out out-of-hours and co-ordinate with the parties concerned refreshing of metadata. As I discuss later in this post, some parties need manual intervention.
With the automatic rollover option selected, any existing token signing / decrypting certificates will be deprecated and replaced with a fresh one years’ validity alternate.
Exporting certificates to file
Once you’ve added a new token-signing certificate (manual route) or run the Powershell script to set automatic rollover you’ll need to export the certificate to file. Double click on the AD FS Token Signing certificate, click on the Details tab and then select Copy to File. The export format varies according to the target system. Windows systems will generally accept DER and Base64. If it’s a Java web container / application server then use Base64. Ditto with Linux/Unix…
In the examples below, I’ve used Office 365 and Sharepoint 2010 as two examples of web applications that need manual intervention.
Office 365 – MSOL
To rectify the problem of a token signing certificate change in Office 365, we need to update Online Services with new information concerning our certificate. As covered in the post here: https://blog.auth360.net/2011/10/15/ad-fs-2-0-rollup-i-multiple-issuer-support/ AD FS 2.0 now supports multiple UPN suffixes, so you’ll need to run this per UPN domain to update the respective information in Powershell.
$Cred=Get-Credential
Connect-MSOLService -cred $cred
Update-MsolFederatedDomain -DomainName mydomain.com -SupportMultipleDomain
Update-MsolFederatedDomain -DomainName yourdomain.com -SupportMultipleDomain
Substitute your own UPN suffixes with the examples above and the effect should be instantaneous and logon to MSOL possible once the update has been carried out. Run this through your test environment first to make sure you get the desired effect.
Sharepoint 2010
Sharepoint throws an error when the token signing certificate is invalid when accessing the Sharepoint Security Token Service at https://sharepoint.mydomain.com/_trust/
An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing – sts.mydomain.com\nIssuer Name: CN=ADFS Signing – sts.mydomain.com\nThumbprint: 611CBD4AE55FE2F2C3F0648C16C57A231AA51491\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..
In the above example, I triggered automatic certificate rollover on the AD FS side without notifying Sharepoint of the change and this threw an error (screenshot). To rectify this we’ll need to export the token signing certificate from AD FS instance and import it into Sharepoint 2010. We’ll then assign the register and assign the replacement certificate. This occurs at two levels:
The following Powershell script shows an example configuration.
$certPath = "C:\temp\ADFS Token.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")
$root = New-SPTrustedRootAuthority "AD FS 2.0 STS" -Certificate $cert
$upd = Set-SPTrustedIdentityTokenIssuer -Identity "ENTER THE NAME OF YOUR EXISTING ADFS INSTANCE " -ImportTrustCertificate $cert
Your own configuration may vary and you’ll need to ensure that the identity to be updated is set correctly.
As ever TEST, TEST, TEST!!!!…..
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
This is more of a mental note to self (and something which I kept forgetting the correct syntax for, despite using it in the past)… How to add an additional claims-aware web application to an existing Sharepoint 2010 farm.
$ap=Get-SPTrustedIdentityTokenIssuer
$uri = new-object System.Uri(“https://www.mydomain.com“)
$ap.ProviderRealms.Add($uri, “urn:sharepoint:mydomain”)
$ap.Update()
The original post courtesy of Steve Peschka:
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 