locked
Auth Prompts on Document Libraries via Web Application Proxy RRS feed

  • Question

  • 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
    Wednesday, January 28, 2015 9:33 AM

Answers

  • Hi,

    a shame, that the new persistent cookie feature was not promoted and "hidden" in that hotfix. A really great step forward and a must have for us.

    What we had to do to get it to work:

    • Install KB3020813 on the WAP server
    • Set the access cokie expiration time per web application:

      Get-WebApplicationProxyApplication yoursite.domain.com | Set-WebApplicationProxyApplication -PersistentAccessCookieExpirationTimeSec 86400

    • Add the site to the Internet Explorer Trusted Sites list.

    Worked flawless for us.

    Thomas





    • Edited by Thomas Ko Tuesday, June 30, 2015 6:55 AM
    • Proposed as answer by Thomas Ko Tuesday, June 30, 2015 6:56 AM
    • Marked as answer by Marc3742 Tuesday, June 30, 2015 7:45 AM
    Tuesday, June 30, 2015 6:54 AM

All replies

  • 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 9, 2015 9:04 AM
    • Unmarked as answer by Marc3742 Tuesday, June 30, 2015 7:45 AM
    Sunday, February 8, 2015 8:43 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.

    Monday, February 9, 2015 2:20 PM
    • Edited by superdomi Sunday, March 8, 2015 7:57 AM
    Saturday, March 7, 2015 10:57 PM
  • We have the same problem.

    Do we need to cofigure anything after installing the hotfix on the WAP server?

    Monday, May 25, 2015 5:03 PM
  • Hi,

    a shame, that the new persistent cookie feature was not promoted and "hidden" in that hotfix. A really great step forward and a must have for us.

    What we had to do to get it to work:

    • Install KB3020813 on the WAP server
    • Set the access cokie expiration time per web application:

      Get-WebApplicationProxyApplication yoursite.domain.com | Set-WebApplicationProxyApplication -PersistentAccessCookieExpirationTimeSec 86400

    • Add the site to the Internet Explorer Trusted Sites list.

    Worked flawless for us.

    Thomas





    • Edited by Thomas Ko Tuesday, June 30, 2015 6:55 AM
    • Proposed as answer by Thomas Ko Tuesday, June 30, 2015 6:56 AM
    • Marked as answer by Marc3742 Tuesday, June 30, 2015 7:45 AM
    Tuesday, June 30, 2015 6:54 AM
  • Thanks Thomas,

    The missing step from the hotfix installation was indeed to set the PersistentAccessCookieExpirationTimeSec on the application itself. The moment I applied that to our SharePoint sites (had previously tried just the hotfix with no additional configuration) it all started working perfectly.

    Tuesday, June 30, 2015 7:48 AM
  • What does the value -PersistentAccessCookieExpirationTimeSec 86400 mean?

    What is max, min value and how do you determine what is best?

    Tuesday, June 30, 2015 8:22 AM
  • The value means, that the persistent cookie will expire in 86400 seconds. But how that interacts with the expiration settings seems to be unclear, no real documentation around. To get an idea about it, I found that http://tristanwatkins.com/coordinating-adfs-2012-r2-token-lifetime-logon-prompt-enforce-revocation-session-duration-public-network/
    Tuesday, June 30, 2015 4:38 PM