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!

4 thoughts on “O365 and TMG with Strong Authentication (Part I)

  1. Hi,

    Very informative post but I’d like to get some clarification on the endpoints that are being used by the different kinds of clients:

    /adfs/services/trust/2005/usernamemixed is the active endpoint used by the following clients: ActiveSync, POP, IMAP, SMTP, Outlook on any version of Windows today, Outlook on XP and Vista beyond the beta? So this is the one used by Office 365 to obtain the token after the client has submitted username and password to Office 365 (e.g. from an ActiveSync client)

    /adfs/services/trust/mex/ is the avtive endpoint used by Lync, Outlook 2010 on Windows 7 at GA, Outllook 2007 on Windows 7 post GA? These clients connect to this endpoint directly to obtain a token and submit it to Office 365.

    I am looking for some definitive statement on this but that seems to be hard to find among the thousands of pages of information…. 🙂

    Regards
    Geert

    1. Hi Geert,

      Thanks for your comments. I understand that there are changes due to the way that GA will handle username/password prompts in Outlook for federated identities to ensure a SSO experience, which will include switching the way W7 Outlook clients will behave (as you state using /adfs/services/trust/2005/usernamemixed to /adfs/services/trust/mex). I’m testing with UAG in the proxy role at the moment as a Relying Party and I have yet to see this fixed (as of the 28th/GA)…I’ll have to revert back to the default AD FS proxy configuration to confirm this though.

      Regards,
      Mylo

  2. Hi,

    In your above article are you stating that when using the UAG server and ADFS trunk that ActiveSync will not authenticate and work properly?

    Thanks,
    Rick

    1. Hi Rick,

      Yes I am. UAG supports the WS-Federation Passive profile, which limits you to Outlook Web App and Sharepoint Online.

      Regards,
      Mylo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s