Federating FIM 2010 using UAG/ADFS and KCD

This post is about leveraging ADFS/UAG to publish FIM to identities outside the trusted security realms for delegation and/or self-service identity related tasks. Before getting into the technical stuff, this post is not meant to be a “How To” guide. It’s really just to demonstrate the capabilities of our identity stack.

Where is this applicable? Say you have a resource forest where FIM resides so how do you provide access to the portal from autonomous security realms without having to create a bunch of NT trusts or maintaining secondary credentials. Because shadow accounts exist within the resource forest as security principals for dependent services (for example BPOS or O365), you can leverage UAG, ADFS, and KCD together to provide secure access. UAG is claims-aware and supports Kerberos protocol extensions for (1) protocol transitioning and (2) constrained delegation.

• Protocol transition is a Kerberos extension introduced in Windows 2003 which allows a service that uses Kerberos to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service without requiring the principal to initially authenticate to the KDC with credentials.
• Constrained delegation is an extension which allows a service to obtain service tickets (under the delegated users identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 1510, or in the protocol transition extension.

The architecture should look and works as diagramed below:
 

To get this working you need the following:

1. Kerberos-enabled WSS 3.0 (FIM Portal Server) + working FIM 2010 installation
2. ADFS 2.0 Server (STS-RP and STS-IP)
3. UAG 2010 SP1

There are many online references for configuring WSS for Kerberos; therefore, I’m just going to summarize the key configuration tasks and troubleshooting notes.
Configuring WSS for Kerberos

1. Reference the following TechNet article to configure Kerberos authentication within WSS:
   • Configure Kerberos Authentication (Office SharePoint Server)
2. Insure Kerberos enabled end-to-end:
   • Run the following query to determine Kerberos is being used for SQL:
     • SELECT SESSION_ID,AUTH_SCHEMA,NET_TRANSPORT FROM SYS.DM_EXEC_CONNECTIONS WHERE @@SSPID = SESSION_ID
     • Verify Kerberos is being used on the WSS Web Front-end event logs. You should be able to filter the log to Event ID: 4624.
       • You can also use Fiddler to validate WWW-Authentication from the client browser to IIS.
3. Once you’re sure Kerberos is configured end-to-end within WSS, you should be good to proceed.

Configure UAG with ADFS 2.0
For the ADFS and UAG configuration make sure the common pre-requisites are configured properly. What I’m referring to is name resolution, certificates, and a working configuration. To insure this, I recommend configuring a sample claims-aware application to insure ADFS is working. This can be accomplished by using any of the step-by-step guides published by the PG.

• ADFS 2.0 Step-by-Step and How To Guides

The next step is to create a portal trunk in UAG and wire it up to the STS.

1. Within the UAG Management Tool, add an ADFS Authentication Server.
2. Specify the URL of the federation metadata and select the “Retrieve Metadata” button.
   • Select the claim value to be used as lead user value. I used Name but this can be something like UPN or Windows Account Name; whatever you want really.
3. Create a portal trunk which will use ADFS as an authentication mechanism.
4. Save and activate the configuration. The next step would be configuring UAG as an RP in ADFS.
   • Verify the federation metadata on UAG and save it to a file for later use.
5. Configure UAG as an RP Trust in ADFS. To do this, you will need to import the federation metadata from the file created in the previous step.
6. Edit the Claims Rules to pass data from the attribute store. In my configuration, the minimum was SAM-Account-Name mapping to Name. Save and test the configuration.
7. As a test, you should attempt to access the UAG Portal. You should be redirected to your IDP. If you have more than one identity provider, then the requestor will need to select their IdP within the HRD page. Otherwise, you should get the FBA login page presented by the IdP. Enter the appropriate credentials to successfully authenticate and be redirected to the RP (UAG Portal). The RP will consume the AuthN token and the end result is to successfully long into the UAG Portal.

Publish FIM through UAG
Now that requestors can successfully log into UAG using Federated AuthN, the next step is to publish FIM 2010 as an application within UAG.

1. Add an application within the existing trunk. UAG comes with a template to use with FIM 2010.
2. Specify the URL for FIM under the web servers’ properties.
3. Enable SSO under the authentication properties. Select “Use Kerberos constrained delegation for single sign-on. Additionally, select a value from this claim type as the shadow account user name for KCD when using federated authentication.The final step is to configure the SPNs in Active Directory for KCD to the UAG server object. Using the UAG Management Tool, Export KCD Settings to Active Directory. Then use Ldifde.exe to import the SPN value which is set on the msDS-AllowToDelegateTo attribute of the UAG computer object.
   • I prefer publishing applications directly through UAG. To do this, uncheck “Add portal and toolbar link” and “Open in a new window” within the Portal Link properties. Within the Portal Trunk configuration, I modify the “Portal home page” to the FIM Application and uncheck “Display home page within portal frame. Assuming, the FIM SPNs are configured properly…we can assume a working FIM Portal.
4. The final step is to test the configuration. Browse the FIM URL from an untrusted workstation outside of the network. The end result is the FIM Portal being rendered in the same way as if you were accessing it internally.

Chris Calderon

MSFT