I wrote in previous posts about some of the more unusual access scenarios involving Office 365 and UAG with AD FS 2.0.  In doing so I’d not gone through and covered setting up a basic  federated trunk scenario using UAG, AD FS 2.0 and Office 365. With  this post I’ll attempt to remedy that.

In a normal O365 federated identity setup, UAG would be configured as a relying party to provide single sign-on to web applications at the edge.  As a relying party UAG then processes security tokens issued by the AD FS security token service. For UAG admins, there is a key difference in the way UAG works with AD FS compared to other authentication services. Normally speaking, it is the UAG that is directly responsible for front-end authentication. Here, however, UAG adopts the role of an AD FS proxy and uses the AD FS infrastructure to provide the authentication and process the requisite claims required for single sign on to back end web applications. There is no authentication taking place on the UAG. This is borne out when we look at the web application configuration the for the trunk, with UAG configured like any other claims-aware application or relying party.

On the AD FS web application itself, we must allow unauthenticated access to the AD FS web server / farm

Additional authentication services cannot be used on the same trunk. Also, unlike the AD FS proxy, UAG does not provide a forms-based logon page. Instead it uses challenge/response. So a user who is accessing O365 from a non-domain joined machine can expect to an NTLM challenge response.

Because UAG does not process AD FS authentication, the request is proxied to the AD FS service in the backend using the Integrated Windows Authentication (IWA) handler. This can be seen in the redirect to https://sts.mydomain.com/adfs/ls/auth/integrated/……

Connecting to an Office 365 web resource from the Internet with a domain joined machine on the Internet,  users can logon via IWA and get the single sign-on experience to the O365 resource when the STS is in the Local Intranet zone of the browser. Looking at Fiddler, one can see a  kerberos service ticket in the negotiate header.

No Proxy-Authorization Header is present.

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
60 82 06 38 06 06 2B 06 01 05 05 02 A0 82 06 2C  `‚.8..+….. ‚.,
30 82 06 28 A0 30 30 2E 06 09 2A 86 48 82 F7 12  0‚.( 00…*†H‚÷.
01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 06 0A  …..*†H†÷……

From a non-domain joined machine, the fact that we’re doing IWA and and Negotiate means that it falls-back to NTLM (and the logon challenge/response)…..

No Proxy-Authorization Header is present.

Authorization Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00  NTLMSSP………
96 00 00 00 60 01 60 01 AE 00 00 00 00 00 00 00  –…`.`.®…….

Whether you like the idea of challenge/response over form-based logon is down to personal preference