Office 2016 client application not presented with ADFS Home Realm Discovery

%3CLINGO-SUB%20id%3D%22lingo-sub-1365350%22%20slang%3D%22en-US%22%3ERe%3A%20Office%202016%20client%20application%20not%20presented%20with%20ADFS%20authentication%20chooser%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1365350%22%20slang%3D%22en-US%22%3EAdditional%20info...%20compared%20fiddler%20capture%20on%20what%20should%20be%20a%20very%20similar%20conversation%20between%20browser%20accessing%2Fauthenticating%2Fauthorizing%20to%20SharePoint%20(on-premise)%20versus%20office%20client%20application%20accessing%2Fauthenticating%2Fauthorizing%20to%20SharePoint.%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20Office%20application%20capture%20presents%20a%20FedAuth%20cookie%20and%20all%20items%20in%20the%20header%20I%20would%20expect.%20The%20response%20it%20gets%20back%20includes%3A%3CBR%20%2F%3EX-Forms-Based_Auth_Required%3A%20%5Badfs%20URI%5D%20...%20at%20the%20end%20of%20this%20URL%20i%20see%20a%20parameter%20'context%3DMSOFBA'%3CBR%20%2F%3E%3CBR%20%2F%3EHowever%20when%20I%20look%20at%20the%20browser%20capture%2C%20I'm%20seeing%20'RedirectToIdentityProvider%3D%5Burl%20for%20User%20domain%20ADFS%5D.%3CBR%20%2F%3E%3CBR%20%2F%3ESo%20I'm%20assuming%20SharePoint%20intuitively%20holds%20a%20trust%20token%20for%20a%20UserDomain%20user%20via%20it's%20claims.%20Trusted%20by%20SharePoint%20because%20it%20trusts%20it's%20own%20Resourcedomain%20ADFS.%20However%2C%20Office2016%20client%20application%20has%20no%20such%20relationship%20and%20all%20it%20gets%20from%20SharePoint%20is%20%22you%20need%20to%20go%20over%20here%20to%20authenticate%20which%20is%20to%20the%20same-domain%20ADFS%20login%20form%20page%22%3F%3CBR%20%2F%3E%3CBR%20%2F%3ESimilarly%2C%20if%20i%20use%20a%20browser%20to%20go%20to%20%22%3CA%20href%3D%22https%3A%2F%2Fnamespace.com%2Fsites%2Fsite%2FShared%2520Documents%2F%3Fcontext%3DMSOFBA%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fnamespace.com%2Fsites%2Fsite%2FShared%2520Documents%2F%3Fcontext%3DMSOFBA%3C%2FA%3E%22%20...%20I%20get%20sent%20to%20a%20provider%20chooser...%20If%20i%20choose%20ADFS%2C%20i%20then%20get%20the%20ADFS%20Authentication%20Chooser%20which%20is%20what%20I%20need%20the%20Office%202016%20client%20application%20to%20do...%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1364050%22%20slang%3D%22en-US%22%3EOffice%202016%20client%20application%20not%20presented%20with%20ADFS%20Home%20Realm%20Discovery%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1364050%22%20slang%3D%22en-US%22%3E%3CP%3EADFS%202016%20(resource%20domain)%20with%20federated%20ADFS%202016%20partner%20(user%20domain).%3C%2FP%3E%3CP%3EBoth%20ADFS%20environments%20are%20published%20with%20a%20Web%20Application%20Proxy%20residing%20in%20the%20same%20DMZ.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20using%20a%20browser%2C%20and%20navigating%20to%20a%20site%20within%20the%20sharepoint%20environment%20(externally)%2C%20we're%20prompted%20with%20the%20ADFS%20authentication%20chooser%20page%20(presented%20from%20the%20Resource%20ADFS).%26nbsp%3B%20This%20allows%20us%20to%20choose%20whether%20to%20login%20using%20User%20domain%20credentials%20or%20Resource%20domain%20credentials.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20we%20use%20an%20Office%202016%20client%20application%2C%20however%2C%20we%20are%20not%20presented%20with%20the%20authentication%20chooser%20page%2C%20we're%20only%20presented%20with%20the%20Resource%20login%20form.%26nbsp%3B%20This%20is%20unexpected%20and%20naturally%20prevents%20anyone%20from%20the%20User%20domain%20from%20being%20able%20to%20authenticate%20and%20thus%20can't%20open%20a%20file.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20haven't%20been%20able%20to%20find%20any%20references%20online%20for%20this%20issue%2C%20so%20any%20help%20would%20be%20greatly%20appreciated.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F130%22%20target%3D%22_blank%22%3E%40Trevor%20Seward%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUPDATE-1%3A%3C%2FP%3E%3CP%3E%3CSPAN%3EAdditional%20info...%20compared%20fiddler%20capture%20on%20what%20should%20be%20a%20very%20similar%20conversation%20between%20browser%20accessing%2Fauthenticating%2Fauthorizing%20to%20SharePoint%20(on-premise)%20versus%20office%20client%20application%20accessing%2Fauthenticating%2Fauthorizing%20to%20SharePoint.%3C%2FSPAN%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSPAN%3EThe%20Office%20application%20capture%20presents%20a%20FedAuth%20cookie%20and%20all%20items%20in%20the%20header%20I%20would%20expect.%20The%20response%20it%20gets%20back%20includes%3A%3C%2FSPAN%3E%3CBR%20%2F%3E%3CSPAN%3EX-Forms-Based_Auth_Required%3A%20%5Badfs%20URI%5D%20...%20at%20the%20end%20of%20this%20URL%20i%20see%20a%20parameter%20'context%3DMSOFBA'%3C%2FSPAN%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSPAN%3EHowever%20when%20I%20look%20at%20the%20browser%20capture%2C%20I'm%20seeing%20'RedirectToIdentityProvider%3D%5Burl%20for%20User%20domain%20ADFS%5D.%3C%2FSPAN%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSPAN%3ESo%20I'm%20assuming%20SharePoint%20intuitively%20holds%20a%20trust%20token%20for%20a%20UserDomain%20user%20via%20it's%20claims.%20Trusted%20by%20SharePoint%20because%20it%20trusts%20it's%20own%20Resourcedomain%20ADFS.%20However%2C%20Office2016%20client%20application%20has%20no%20such%20relationship%20and%20all%20it%20gets%20from%20SharePoint%20is%20%22you%20need%20to%20go%20over%20here%20to%20authenticate%20which%20is%20to%20the%20same-domain%20ADFS%20login%20form%20page%22%3F%3C%2FSPAN%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSPAN%3ESimilarly%2C%20if%20i%20use%20a%20browser%20to%20go%20to%20%22%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fnamespace.com%2Fsites%2Fsite%2FShared%2520Documents%2F%3Fcontext%3DMSOFBA%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fnamespace.com%2Fsites%2Fsite%2FShared%2520Documents%2F%3Fcontext%3DMSOFBA%3C%2FA%3E%3CSPAN%3E%22%20...%20I%20get%20sent%20to%20a%20provider%20chooser...%20If%20i%20choose%20ADFS%2C%20i%20then%20get%20the%20ADFS%20Authentication%20Chooser%20which%20is%20what%20I%20need%20the%20Office%202016%20client%20application%20to%20do...%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUPDATE-2%3A%20(Perhaps%20this%20is%20more%20of%20an%20ADFS%20response%20question)%3C%2FP%3E%3CP%3EI%20had%20a%20chance%20to%20read%20through%20a%20fair%20amount%20of%20the%20Microsoft%20online%20documentation%20on%20MS-OFBA.%26nbsp%3B%20From%20what%20I%20understand%2C%20the%20Office%202016%20client%20application%20is%20abiding%20by%20the%20MS-OFBA%20protocol%20by%20including%20specific%20options%20in%20the%20Request%20header.%26nbsp%3B%20Additionally%2C%20ADFS%20also%20appears%20to%20be%20responding%20properly%20with%20Response%20headers%3A%3CBR%20%2F%3E*%20X-Forms_Based_Auth_Required%3A%20%5Bparameterized%20URI%5D%3C%2FP%3E%3CP%3E*%20X-Forms_Based_Auth_Return_Url%3A%20%5BURL%20to%20web%20application%5D%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20the%20biggest%20question%20I%20haven't%20been%20able%20to%20find%20an%20answer%20to%20is%3A%3C%2FP%3E%3CP%3EHow%20do%20we%20force%20ADFS%20to%20present%20the%20ADFS%20Home%20Realm%20Discovery%20(HRD)%20page%20(When%20Office%202016%20client%20app%20authenticates)%20instead%20of%20automatically%20displaying%20the%20'local'%20Active%20Directory%20provider%20login%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20found%20some%20potential%20in%20modifying%20the%20ADFS%20onload.js%2C%20but%20am%20not%20sure%20this%20is%20the%20right%20path.%3C%2FP%3E%3CP%3E--to%20be%20continued--%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1364050%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EADFS%202016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Eclaims%20authentication%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%202016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%202016%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Occasional Contributor

ADFS 2016 (resource domain) with federated ADFS 2016 partner (user domain).

Both ADFS environments are published with a Web Application Proxy residing in the same DMZ.

 

When using a browser, and navigating to a site within the sharepoint environment (externally), we're prompted with the ADFS authentication chooser page (presented from the Resource ADFS).  This allows us to choose whether to login using User domain credentials or Resource domain credentials.

 

When we use an Office 2016 client application, however, we are not presented with the authentication chooser page, we're only presented with the Resource login form.  This is unexpected and naturally prevents anyone from the User domain from being able to authenticate and thus can't open a file.

 

I haven't been able to find any references online for this issue, so any help would be greatly appreciated.

 

@Trevor Seward 

 

 

UPDATE-1:

Additional info... compared fiddler capture on what should be a very similar conversation between browser accessing/authenticating/authorizing to SharePoint (on-premise) versus office client application accessing/authenticating/authorizing to SharePoint.

The Office application capture presents a FedAuth cookie and all items in the header I would expect. The response it gets back includes:
X-Forms-Based_Auth_Required: [adfs URI] ... at the end of this URL i see a parameter 'context=MSOFBA'

However when I look at the browser capture, I'm seeing 'RedirectToIdentityProvider=[url for User domain ADFS].

So I'm assuming SharePoint intuitively holds a trust token for a UserDomain user via it's claims. Trusted by SharePoint because it trusts it's own Resourcedomain ADFS. However, Office2016 client application has no such relationship and all it gets from SharePoint is "you need to go over here to authenticate which is to the same-domain ADFS login form page"?

Similarly, if i use a browser to go to "https://namespace.com/sites/site/Shared%20Documents/?context=MSOFBA" ... I get sent to a provider chooser... If i choose ADFS, i then get the ADFS Authentication Chooser which is what I need the Office 2016 client application to do...

 

UPDATE-2: (Perhaps this is more of an ADFS response question)

I had a chance to read through a fair amount of the Microsoft online documentation on MS-OFBA.  From what I understand, the Office 2016 client application is abiding by the MS-OFBA protocol by including specific options in the Request header.  Additionally, ADFS also appears to be responding properly with Response headers:
* X-Forms_Based_Auth_Required: [parameterized URI]

* X-Forms_Based_Auth_Return_Url: [URL to web application]

 

So the biggest question I haven't been able to find an answer to is:

How do we force ADFS to present the ADFS Home Realm Discovery (HRD) page (When Office 2016 client app authenticates) instead of automatically displaying the 'local' Active Directory provider login?

 

I have found some potential in modifying the ADFS onload.js, but am not sure this is the right path.

--to be continued--

0 Replies