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.

• Support identity federation at the edge
• Support claims-aware applications for SSO
• Support for strong/two-factor authentication with Office 365 web applications
• Replace the AD FS Proxy function
• Utilize access policies for web-based applications
• AD FS Single Sign-Out

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:

  • Microsoft Online Services Assistant has been installed
  • Microsoft Online Services Module for Powershell has been installed
  • MS Online domain has been converted from standard use to federated

• Directory Synchronization between the organization/Office 365 tenancy is active.
• An AD FS 2.0 server/farm is available and configured in the corporate environment.
• UAG 2010 SP1 is a member of the corporate Active Directory domain. *
• The Federation Services Endpoint certificate (SSL certificate) used by AD FS has been exported and imported into the UAG computer certificate store. This will be assigned to the trunk.
• The external (A) record for the AD FS service points to the UAG federated/non-federated trunk. For client hosting a HOSTS file will suffice initially.

* 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:

• for front-end authentication, with the AD FS 2.0 server as a federated trunk
• for federated back-end authentication, whilst using a non-federated trunk on UAG

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

• Create a Portal Trunk
• Assign the trunk a name (imaginatively called ADFS in this example)
• Give the public host name the same name as the federation services endpoint URL (e.g. sts.mydomain.com)

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.

• Start the Add Relying Party Trust wizard.
• Import data about the relying party published online

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:

• Front-End authentication using classic UAG authentication
• Back-End authentication using claims-based authentication through AD FS 2.0

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:

1. Select a web application template
2. Define a name and type for the application
3. Define endpoint / access policies
4. Specify the address/location of the web server
5. Specify how (SSO) credentials are passed to the published application
6. Define whether the application will be shown within the portal

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