Let’s have a look at some of the authentication methods/options that are possible with TMG, Federation and Office 365. I believe Microsoft at some point will expand on the supported TMG scenarios for O365 and how these options work in conjunction with AD FS 2.0. In the meantime, there are a few TMG front-end pre-authentication methods/combinations to try out with O365 and AD FS 2.0.

As the diagram above illustrates, TMG supports a number of authentication types. Let’s have a look at authentication combinations with TMG and AD FS 2.0 with the Office 365 suite as a relying party.

No Authentication

The basic reverse proxy scenario, or No Authentication scenario as I’ll refer to it, is described here on the Office 365 community site.

http://community.office365.com/en-us/w/sso/293.aspx

This is the only Microsoft-documented TMG configuration thus far for Office 365. The article provides an excellent starting point for configuring TMG with AD FS 2.0, so I’d recommend beginning with this configuration.

From a user experience perspective, using OWA as an example, the user may approach the web application through the Microsoft portal at https://portal.microsoftonline.com or directly via https://www.outlook.com/mydomain.com. Once the user hits AD FS, the user logon is processed according to whether:

• If the machine isa domain member, the URL of the TMG (e.g. sts.mydomain.com) is in the trusted sites zone, and the browser is configured to automatically logon with username and password, then the user will silently logon to the on-premise AD FS and be redirected to their OWA mailbox
• If the machine is not a AD domain member, or the URL of the AD FS is not in the trusted sites zone, the user will be challenged to enter their domain username and password (NTLM)

 

With no AD FS proxy present, the TMG is setup to reverse proxy traffic to the AD FS backend. The user request is proxied to the AD FS server and the AD FS picks up the logon request.

This scenario is called No Authentication as a reference to the fact that TMG isn’t performing any pre-authentication itself. It’s simple and doesn’t “interfere” with the federation logon process like the other approachesdescribed. It’s downside, one can argue, is that this approach may be less than satisfactory from a security perspective, with some form of pre-authentication at the edge more preferable.

For browser-based clients there are pre-authentication options with TMG, in conjunction with authentication delegation to the AD FS service that can be used. They are:

• HTML Forms Authetnication
• HTTP Authentication
• SSL Client Certificate Authentication

From a Office 365 web application testing perspective (for browser-based applications), logon from the following apps was performed:

• Outlook Web  App
• Sharepoint Online
• Microsoft Office 2010 Clients (excluding Outlook)

HTML Forms Authentication

HTML Forms Authentication or Forms-based logon is likely familiar to most TMG administrators as it is often used in web publishing scenarios. The use enters their credentials via a form; username/password, One-Time-Password etc.

On the TMG-side, when configuring the web listener for HTML-Forms authentication, there are a number of authentication validation methods.

In this case we’re interested in seeing what authentication options are possible with the Delegation tab on the publishing rule and which ones are available according to the authentication validation method selected.

For a more detailed read on authentication methods versus supported delegation, refer to the following Technet article:

http://technet.microsoft.com/en-us/library/cc995215.aspx

Using Windows (Active Directory) as an authentication method, we can see on the publishing rule that a wide selection of delegation methods to AD FS are possible. For completeness, I tested a variety of HTML forms logon configurations using various authentication delegation methods:

I didn’t have an RSA Authentication Manager/ACE server in my sandpit so was unable to test SecurID.

Logon in the majority of pre-authentication scenarios using Forms Logon worked fine. Basic authentication didn’t work because the AD FS farm uses the default local authentication type of Integrated. Shifting Basic to the top of the pile in the AD FS web.config might have meant that basic delegation would have worked for forms-based username/password scenarios, but I can’t think of any reason why I would use basic delegation when integrated authentication (Negotiate) was available  

<localAuthenticationTypes>
  <add name=”Integrated” page=”auth/integrated/” />
  <add name=”Forms” page=”FormsSignIn.aspx” />
  <add name=”TlsClient” page=”auth/sslclient/” />
  <add name=”Basic” page=”auth/basic/” />

HTTP Authentication

With HTTP Authentication configured on the TMG (AD FS) web listener , the user will receive a challenge prompt rather than a form when the Office 365 relying party redirects the user to AD FS through TMG.

TMG then processes those logon details entered in the dialogue. Depending on the client authentication method we have selected (Basic, Digest or Integrated), there are typically fewer supported authentication validation methods against which credentials can be evaluated.

From a delegation perspective, I used the HTTP Basic Authentication method on the TMG side.

Results-wise,  the majority of pre-authentication mechanisms involving TMG and various delegation scenarios worked. The same caveats concerning configuring web publishing rules, delegation etc. apply here.

Changing the client authentication method to HTTP Integrated Authentication on TMG were unsuccessful (so far).

HTTP Authentication with Digest was not tested.

SSL Client Certificate Authentication

SSL Client Certificate Authentication is an interesting approach as it logs the user on using an X509 certificate. I issued my client (in this case my domain user account) with a client certificate from a local issuing CA. If the incoming connection does not possess a client certificate, then TMG can be configured to fallback to HTTP authentication, e.g. HTTP Basic.

Once OWA had redirected the browser to TMG, a selection dialog requesting the client certificate for authentication was prompted.

After processing the client certificate,  logon was completed and access to OWA given. Note that Client Certificate Authentication only supports Kerberos Delegation as a delegation method. This approach deserves a little more attention and I’ll look at how this works in a future post. In particular, I’m curious how smart cards would work in this configuration and/or with the TLSClient option in the AD FS backend.

Web Publishing Rules

On the TMG side, two publishing rules are required.

• a web publishing rule for web applications that will use forms-logon such as Sharepoint Online, Outlook Web App, Office  etc,
• a web publishing rule for rich applications such as Outlook Anywhere, Lync Communicator Client and ActiveSync. that have special requirements.

Passive Clients: Outlook Web App / Sharepoint Online / MSOL Portal / Office 2010 (except Outlook)

Attached are the relevant screenshots for the  Office 365 web applications that will use TMG for pre-authentication (forms-based logon).

The To: field in the publishing rule is important. In the above example, the computer name field contains myserver.mydomain.local, referring to the FQDN of the test AD FS server. In a highly available AD FS scenario where the admin wishes to use Kerberos Constrained Delegation, this field will be blank and the load-balanced URL and service principal name (SPN) of the AD FS federation service will need to be configured with the AD FS application pool service account (via the Delegation tab in AD Users and Computers)

The public name of the TMG matches that of the AD FS federation service and an (A) record is registered to the public IP of the TMG FBA listener.

We also need to specify certain paths for TMG as pre-authentication scenarios require two publishing rules, with the public URL of the AD FS service being shared across the two rules.

 

With forms logon example I’m using Kerberos Constrained Delegation.  If Kerberos is to be used as the delegation method (recommended), ensure that the TMG computer account is trusted for delegation in AD Users and Computers, either for the AD FS server (single server scenario) or for the application pool (AD FS farm scenario).

We’re bridging SSL traffic as AD FS is HTTPS only.

The built-in All Authenticated Users group should be used in this rule, contrasting with the All Users group mentioned later in the Outlook Anywhere / EAS / Lync configuration section.

As the Office 365 wiki article mentions, AD FS 2.0 requires link translation to be disabled.

HTTP Filtering will also need to be modified to ensure that Verify normalization and Block high bit characters are disabled.

Let’s have a look at how TMG works for our non browser-based friends.

Active/MEX Clients: Outlook Anywhere / Lync 2010 Communicator / Exchange ActiveSync

As mentioned earlier, a second web publishing rule is required for certain “rich” clients. Active clients (Outlook/ActiveSync) and MEX clients in Microsoft speak, cannot be authenticated at the TMG. Instead,  we must adopt the reverse proxy approach for selective paths to the AD FS service endpoints  that can handle authentication of these clients.

The Active client uses a password proxy-based mechanism where the Office 365 Exchange service will authenticate against Exchange services on  behalf of the client using Basic Authentication.  We can see the WS-Trust service endpoint used on the AD FS service handler.

Conversely, the MEX client is a true federation web service (MEX = Metadata Exchange) that can perform authentication without the use of a “proxy”. This supports multiple forms of authentication. The metadata document for MEX clients is:

I’ve included the MEX above MEX path in the publishing rule for reference. It’s not mandatory. The actual service handler for authentication:

 

While this distinction is important in understanding how the client works, it makes no difference to TMG   We use the same publishing rule, with anonymous access through TMG for Active/MEX clients and a connection proxied to AD FS where the actual authentication is processed. 

Configuring this second web publishing rule, be aware of the following key points:

• All Users on the users tab is required rather than Authenticated Users  (TMG is not authenticating)
• Publish only the relevant service endpoints for Active and MEX clients through this rule (and optionally federation metadata)
• Delegation is set to none but the clients may authenticate directly
• All the other TMG configuration setup points are as is

Again, I’ve attached screenshots and hopefully they’ll assist.

The paths field needs to contain the AD FS service endpoints that are used by the Outlook client (/adfs/services/trust/2005/usernamemixed/*) and Lync (/adfs/services/trust/2005/windowstransport/*). The Federation Metadata (/federationmetadata/2007-06/*) and MEX endpoints  (/adfs/services/trust/mex*) are optional (I use them for testing the publishing rule).

UPDATE: 05/09 – /adfs/services/trust/mex  needs to stay in the web publishing rules otherwise connection problems may arise.

The clients communicate directly with the AD FS endpoints, so no pre-authentication via TMG is possible.

With the absence of authentication on the listener for the above paths, the All Users user set should be used rather than the All Authenticated Users user set seen in the previous rule.

Summary

I always finish these posts thinking I’ve forgotten something … I did find this Technet article a useful reference.

http://support.microsoft.com/kb/2510193

A word of caution, aside from the usual test test test waiver I throw in, it’s important that you think of the use cases under which you intend to deploy this type of configuration. If there are other relying parties that are in use behind AD FS 2.0 then it will serve you well to test integration-wise whether these are affected. TMG is not federation-aware and we animate the logon process to federation services through credential delegation. While this works well enough in this scenario, TMG is effectively becoming the Internet proxy for AD FS activity.

Share your experiences and have fun testing!

Mylo