Category Archives: Forefront TMG

TMG 2010 and Office 365 Single Sign Out with AD FS 2.0

A while back (June 2011), I wrote a post on how to implement TMG, Single Sign-On (SSO) and strong authentication with Office 365. It was, as it turns out, an incomplete story. 

Tristan Watkins has written an excellent article on how to implement single sign-out using TMG with Office 365 and ADFS 2.0. It goes into great detail about issues with sign-out from non-federated proxies with ADFS/O365 and explains the various nuances associated with Office 365 sign-in…. you can read this article here:

http://tristanwatkins.com/index.php/office-365-single-sign-out-isa-tmg-adfs-proxy/

TMG Pre-Authentication Options with Office 365

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.

image

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)

image 

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.

image

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

image

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.

image

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:

image

image

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 Smile 

<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.

image

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.

image

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

image

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).

image

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.

image

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).

image

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)

image

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.

image

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.

  image

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).

image

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

image

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.

image

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

image

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.

image

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:

image

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

image 

While this distinction is important in understanding how the client works, it makes no difference to TMG Smile  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.

image

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).

image

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.

image

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 Smile … 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

O365 and TMG with Strong Authentication (Part II)

Using TMG as a strong-authentication capable proxy for passive O365 clients and reverse proxy for rich/active clients

In the previous post I looked at configuring TMG  to allow it to support both strong authentication of Office 365 (passive) web clients and at the time act as a reverse proxy for rich/active clients that use classical username/password for authentication.

Attached is a diagram highlighting the high-level communication flows associated with the previous post.  I’ve emphasised the HTTPS traffic between the Federation Gateway and TMG for rich/active clients (the thick arrow), as it’s bi-directional in nature.

o365 Blog Diagram

Unlike the passive client where all communication occurs through HTTP redirects, rich/active clients  bounce around from server to server. This makes building a solution that supports multiple (strong/weak) authentication schemes difficult to implement and why, in the long term, customisation of the AD FS proxy pages may be the easiest route.

O365 and TMG with Strong Authentication (Part I)

This post looks at how TMG 2010 may occupy a role of hybrid AD FS Proxy for Office 365.

In previous posts on this blog we looked at using TMG as an AD FS 2.0 proxy .. When testing this back in Q4 2010, there was some uncertainty when testing (at least on my part), as to whether TMG as an AD FS proxy replacement was actually a supported configuration. Happily, it looks like these questions  have been answered. In TechEd in Atlanta, the Office 365 deck on Identity and Access Solutions (OSP215) describes TMG as an alternative proxy offering for Office 365.  

Here TMG substitutes the role of the AD FS proxy for corporate users using identity federation, with it being responsible for authentication of browser traffic (passive clients) coming from the Internet and traffic from Microsoft (active/MEX clients). One of the things about TMG  is its flexibility and versatility. This was borne out in testing and it’s possible to support multiple flavours of access through a single web listener. For example, let’s say we need to support strong authentication for external / Internet-based clients using OWA 365 and Sharepoint 365, whilst at the same time we support internal/external users with rich clients, using conventional username and passwords, running Outlook and Lync. Let’s list those again:

  • Single factor (username/password) authentication for rich/active clients inside/outside the corporate environment… covering ActiveSync access from the outside, Outlook 200x from the inside/outside and  MEX clients, such as Lync 2010 inside/outside
  • Single-factor authentication (username/password) for passive clients inside the corporate environment (OWA/Sharepoint)
  • Two factor authentication (2FA) for passive clients outside the corporate boundary (OWA/Sharepoint)

Inside the organisation, passive clients make use of the local AD FS 2.0 instance (rather than TMG), whereas Rich/Active clients use a more complex process . In fact, the latter makes for an interesting challenge, for any would-be admin, as the Microsoft Federation Gateway needs to call-back to the on-premise AD FS instance. Normally speaking, active and rich clients must, therefore, go through the AD FS Proxy for logon. In this post, we substitute the AD FS Proxy role for TMG, so that we may leverage capability that TMG can offer  (I’m using the example of strong authentication).

The key to making this approach work with TMG lies in creating multiple web publishing rules, each with their own authentication requirements, using a single web listener. In doing so, we:

  • Create a web publishing rule that allows direct communication to the AD FS back-end for active and rich clients (effectively anonymizing authentication on the listener for the published paths in question)
  • Create a web publishing rule that triggers authentication (two-factor) on the TMG front-end and then uses delegation to the AD FS back-end using Negotiate authentication. 

We are then able to support access requirements for both two-factor (external) logon from the browser, whilst also supporting the ability of single factor logon for active/rich clients, domain-joined and non-domain joined……..

There are a couple of tweaks in the TMG configuration necessary to ensure compatibility with AD FS 2.0…..

  • Disable Verify Normalization on the HTTP Filtering tab of each publishing rule
  • Disable Block High-Bit Characters on the HTTP Filtering tab of each publishing rule
  • Disable Link Translation on each publishing rule

Also, please ensure that:

  • DNS records for the AD FS Proxy point to the TMG web listener
  • A SAN or wildcard certificate is installed on the TMG listener with the appropriate FQDNs for the AD FS Federation Service endpoint (hint: export the certificate plus private key from AD FS and import into TMG)
  • Kerberos Delegation is configured for the AD FS Farm Application Pool Account or ADFS Computer Account (if the AD FS server is a single machine)

We create two publishing rules with the public name matching that of our AD FS 2.0 server/farm, sts.mydomain.com. :

Rule Authentication Delegation Paths Users
#1 Kerberos Constrained Delegation /adfs/ls/* All Authenticated Users
#2 No delegation, but client may authenticate directly /adfs/services/trust/2005/usernamemixed/*/adfs/services/trust/mex/* All Users

 

  • Rule #1 applies for the passive clients doing two-factor authentication on the web listener
  • Rule #2 applies for the rich/MEX and Active client profiles for Lync and ActiveSync/Outlook respectively.

The more restrictive rule (two-factor) should be applied first in the firewall list. As a general rule of thumb, let the TMG Logs and Reports tracker, together with Fiddler, help debug any protocol issues that may arise.

Next stop ….. UAG !!!!

(FOOT) NOTES

According to official documentation, Office 365 strong authentication scenarios include:

  1. Two-factor authentication at Windows/Domain Logon
  2. Two-factor authentication via Forefront UAG 2010 SP1 for web applications
  3. Two-factor authentication via customized AD FS Proxy sign-in pages

If you have a fully-fledged public key infrastructure with smart cards, then you’re probably wondering what the fuss is about 😉

Option 2 looks promising.. However, after testing it and then reading and then re-reading the Office documentation, it appears that the working two-factor scenarios are limited to passive clients only (OWA/Sharepoint) and that Outlook and ActiveSync (O365) are not supported via UAG. Because a UAG server doing 2FA is acting as non-federated trunk, rich/active clients get stumped during authentication. Now, this may be possible to get working with some tweaking  but it looks like some sacrifices would be required (e.g. disabling access policies on the trunk). I’m hoping I’m missing something here and some bright spark will put me right, part the clouds and show how it can be done Smile

Option 3 is very much possible if you’re prepared to roll up your sleeves and do some sort of customization of the ADFS Proxy sign-in pages to support 2FA, with your strong authentication vendor of choice. I’d expect to see some sort of progress from MS on this, given that Office 365 launches this month.

Getting this working through TMG was really the motivation for me here. If, as a prospective Office 365 customer, you have a requirement for strong authentication for external users, whilst at the same time you need to support traditional username/password logon internally, then maybe this option can assist..… as ever, your mileage may vary and please don’t deploy before testing this to death in anything close to production!

TMG 2010 as an AD FS 2.0 Proxy?

Back in November when testing TMG and AD FS 2.0, I messed around with TMG delegation and AD FS 2.0 with little success. A couple of months on and a bit of time away from the problem seems to have helped!

With no AD FS Proxy functionality within TMG  at present, the latter is unable to act as an in-line authentication proxy for claims-aware applications such as Sharepoint 2010; unlike UAG functionality in SP1.  TMG can, however, supplant the AD FS proxy functionality for logon purposes (in a roundabout way).  In this post I illustrate how.

It’s done by setting up two web listeners within TMG, so I’m kind of cheating.  Yes, there’s always a downside 😉

image

As per standard TMG fayre, each listener should have their own public IP address and appropriate certificates for the domain in question. In my test setup, I used the same wildcard certificate for both. Each listener should be configured thus:

  • A  listener using FBA with Active Directory should be configured. This will perform the  AD FS proxy function.
  • A listener with no authentication configured. This is used for reverse proxy of traffic to claims-aware web applications.

In addition, at least two web publishing rules are required:

image

The first is for the AD FS server(s) sts.mydomain.com, and the second for  the claims-aware web application(s) that need to be published. In this example, it’s Sharepoint 2010 Teamsites and teams.mydomain.com.

When configured correctly (oxymoron.. see the footnote at the end), TMG works in a proxy capacity  for the AD FS service. One possible use case for this that springs to mind could be for mixing authentication schemes on the web listener against the username/password on the federated logon, e.g. SecurID on the TMG instance and then delegation to the back-end AD user account. 

In short, the key to this process working is using a separate listener for the TMG “AD FS Proxy”, independent of the reverse proxy listener used for the claims-aware web applications.

Footnote

As usual, this is a test sandpit. Don’t use it in a production environment, until you’ve battered it senseless with the testing stick.  I’ve tried this with various authentication schemes so far and it works. Will continue testing… if I break it meanwhile, I’ll post an update. Enjoy!