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.

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.