Hello,

I am aware variations of this question appear all over the place on multiple forums, however none I can find seem to address this specific scenario.

We have a SharePoint 2013 SP1 farm published via Server 2012 Web Application Proxy with ADFS 3.0 pre-authentication. Users connect via IE with SharePoint Office integration enabled. Internal users are able to connect on either HTTP or HTTPS via AAMs, external users are for obvious reasons only able to connect to SharePoint via HTTPS through the WAP.

• Internal domain users can open and edit documents from document libraries seamlessly in Office 2010/2013 as one would expect.
• Internal non-domain users are given an NTLM prompt on connection to when attempting to open each new document from a document library. (Done to attempt to rule out the Web Application Proxy as the cause)
• External users, both domain connected and non-domain connected receive an browser style ADFS prompt when attempting to open each new document from a document library.

The second scenario would suggest that persistent cookies are not enabled or the client has the SharePoint site in a zone which does not have protected mode enabled. It would also lead me to expect that if I configured the site to use pass-through auth on the Web Application Proxy that external users would receive similar behaviour, and thus still leave a problem for users accessing SharePoint from personal or non-domain connected machines externally.

I have however confirmed that persistent cookies are enabled on the SharePoint farm, and this is as far as I can tell the default setting in SharePoint 2013. In addition all client devices I have tested with have the URL of the SharePoint site in either the Intranet or Trusted Sites zone, both of which have Protected Mode disabled in our environment. I have seen the additional possible solutions to this problem which indicate enabling the setting of 'Automatic logon with current username and password' for the Trusted Sites zone, however as I need this to work on non-domain connected machines I don't believe passing local user credentials will help this us any way.

The third connection scenario is our preferred method of publishing SharePoint externally, and I expect exhibits the most issues due to the wish to use AFDS pre-auth, thus meaning even domain connected machines are not silently passing NTLM credentials. I'm not however convinced that these symptoms aren't the same root cause as the second scenario. That said, I don't seem to be able to find within the Web Application Proxy and setting one way or another to confirm that the supposedly persistent cookies given by SharePoint are not being replaced with session cookies by the WAP.

I've come to a point where I'm a little stumped, all the more in depth solutions I've seen for this issue seem to relate to niche settings on TMG or ISA servers which aren't present in the fairly basic Web Application Proxy role (despite it being the nearest replacement for these end of life products).

I'd be extremely grateful of any ideas or suggestions for further diagnostics if anyone is able to offer them.

Many Thanks,

• Edited by Marc3742 Wednesday, January 28, 2015 9:34 AM

Hi Marc, I have exactly the same problem. I opened several Microsoft calls about this. The last call had the following result:

Currently Web Application Proxy does not accept persistent cookies. One solution is already out:

• Please use Workplace Join to get a persistent cookie

Another solution will hopefully come with the Februar Rollup for Windows Server 2012 R2. Then Web Application Proxy should support persistent cookie.

You also need to set following Office Registry Key:

• Install December 9, 2014 update for Office 2013: http://support.microsoft.com/KB/2920734
• The following registry entry to be added: [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet] "RefreshFormBasedAuthCookie"=dword:00000001

Maybe this will also work with Office 2010 and Office 2007.

• Marked as answer by Marc3742 Monday, February 09, 2015 9:04 AM

That's annoying, thanks for letting me know, I'll have to keep an eye out for rollup notes that indicate this has been implemented.

The following Hotfix worked for me:

http://support.microsoft.com/kb/3020813