As we have seen, passive clients have a different connection scenario than active clients. As passive clients can actually input data, this can be used to configure the request for additional authentication data. When users are accessing Outlook Web Access they are redirected to the federation services to retrieve their token. This is where we can add the additional authentication hop. Users who reside within the internal network are not required to add additional information as their device and location are already in a trusted location. Therefore this authentication path is excempted from the picture below and described later.

federation authentication with strong authentication

The figure above describes the authentication path for passive clients. The incomming request for the SAML token is forwarded by the firewall to the TMG server. As the inbound request indicates the authentication type used, TMG is able to separate the passive client traffic from the active client traffic. TMG requires based on rules that a radius authentication must take place to validate the passive client traffic. The user will be shown a login page when connecting to the federation services. The user enter his authentication information (username + token code) and the radius request is sent to the radius server. The radius server will validate the user by token validity and Active Directory information. If the user has entered the correct information the ‘radius successfully authenticated’ message is sent to the TMG server. In this case the user is validated on the TMG server and the TMG server requests a Kerberos constrained delegation ticket from Active Directory on behalf of the user. Then the TMG server creates a connection to the federation website with the obtained kerberos ticket on behalf of the user. The federation service validates the Kerberos ticket and thus validates the user and sends the SAML token dedicated for the MSOL federation service.

So how do we distinguish the traffic of a passive client from an active client. It seems that the path used towards the federation service is different. Thus the client will use a specific path on the generic federation service URL to request a token claim.

Table 1: Federation URLs

The TMG can use a single web listener and two rules to identify the traffic. The web listener is configured to use radius authentication in combination with forms or basic authentication. The passive path uses this authentication mechanism in combination with kerberos constained delegation, while the active path discards the authentication all together but allows the request through. Basically the request is just proxied.

The authentication information for the passive clients is received by the TMG server and will be forwarded to the Radius server for external validation. If that validation is successful the TMG server will have authenticated the user. However, the TMG server is yet unable to impersonate the user in order to retrieve the information from the federation server, as the user did not (yet) authenticate with the federation services website. Therefore the TMG server uses Kerberos constained delegation with protocol transition to be able to impersonate the user when contacting the federation services website on behalf of the just authenticated user. To be able to do this the TMG server will require special permissions within Active Directory (and therefore the TMG must be a member of the domain).

While clients on the internal network are not required to add additional information when accessing the Outlook Web Access services, additional configuration is required. While internal clients use the internal DNS services and external clients use public DNS services there is a distinctive difference. Internal clients can be sent to a different IP address for services than external clients. While there is only one TMG farm/server, this server/farm will have additional IP addresses to distinc internal users from external users. Requests inbound to the TMG server on the secondary IP address will not be required to have additional authentication information, so this rule setup is the same as the rule for active clients.

Secondly as requests to the federation services for active clients is unauthenticated one might add a federation proxy into the architecture. All active clients can be redirected to the federation proxy (ADFS Proxy) for additional security. This also complies with the Microsoft rule that active clients must use federation proxy services (although tests prove that this is not required).

In order to sent the active clients to the federation proxy, while directing passive clients directly to the federation server, the specify computer option in each web access rule can be used. Do not forget to enable the send original host header option in the rule as well for the request to work, else the certificates will break the authentication.

And there you have it.. two factor authentication for Office 365 OWA access while retaining the option for rich clients to use the normal authentication mechanism.

Big thanks to The Access Onion for the paths.. 🙂