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
4 thoughts on “Just Another Relying Party: Federation with Forefront UAG 2010 SP1 and Office 365”
We are trying to configure UAG 2010 SP1 as trusted relaying party for ADFS 2.0 for use with Office 365 federation but can’t find any detailed guide on how to configure the “Claim rules” when adding the UAG as a “Relaying Party Trust” on the ADFS server so I have two questions for you!
Question 1: There are three different types of rules
◦Issuance Transform Rules
◦Issuance Authorization Rules
◦Delegation Authorization Rules
Wich one to use? 🙂
Question 2: After selection the correct rule, you click “Add rule” and get to choose a “Claim Rule Template”… Wich one is the correct one and how (if you need to) do you configure it?
Any help with this issue would be greaty appreciated!
Try creating an Issuance Transform Rule and use the Pass thru claims template, passing thru the same attribute that you’ve defined also on the UAG side when configuring AD FS. If I recall correctly, UAG defaults to Name, so try Passing Name thru to the UAG relying party as a claim in the issuance transform screen in AD FS.
We solved it!
After configuring the UAG trunk (to be used as ADFS proxy) to use ADFS 2.0 and point to to the ADFS farm (wich in our case had no relaying trust or rules) you then do this: http://onlinehelp.microsoft.com/Office365-enterprises/ff652560.aspx and it will add Office 365 as under “Relying Party Trusts” and configure some custom “Issuance Transform sRules” rules and a “Issuance Authorization Rule” needed on the ADFS server to work with Office 365 federation!
Worked like a charm 🙂
Thank you for replying, appreciated!
Pretty gud article! Clears my doubts.