6

After migration from sp2013 to new sp2016 server farm we have problems with office client integration.

on sp2013 farm, if there was no persistant cookie written from IE, the client application redirected to the adfs sign in page and did an auth for the office client application.

on the new sp2016 farm, a windows authentication prompt pops up.

ULS Log from sp2013 server gives me the correct behavior:

OPTION call to the Document with an 403 FORBIDDEN => goes to 302 adfs login redirect

ULS Log from the sp2016 gives me a strange behavior:

OPTION call to the document with 403 FORBIDDEN => After that: END OF CALL

strange: fiddler doesnt show me the 403... he shows me 401 access denied...

stranger: the windows authentication prompt shows the url of the portal and not of the adfs sign in page. The authentication prompt doesnt acceppt any credentials, which I pass into it => makes sense, because there is no NTLM or Basic auth configured on this zone.

The settings are the same on both farms (sp2013/sp2016)... https, LDAPCP, same ADFS, same office online server

I want to force sharepoint open the adfs sign in page for login :/ not windows auth prompt

ULS from non working farm:

01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Logging Correlation Data    xmnv    Medium  Name=Request (OPTIONS:https://[url_of_my_portal])   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwhz   Medium  SPRequestModule.BeginRequestHandler End be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  Web Content Management  Publishing  aytib   Medium  ObjectCachePerRequest Global:True, Enabled:False    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Application Authentication  bjvyg   Medium  SPApplicationAuthenticationModule: Clear outgoing token context from SpThreadContext    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh6   Medium  SPRequestModule.PostAuthenticateRequestHandler Begin    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Authentication Authorization    agb9s   Medium  Non-OAuth request. IsAuthenticated=False, UserIdentityName=, ClaimsCount=0  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Runtime ajd6k   Medium  Value for isAnonymousAllowed is : True  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Runtime ajd6l   Medium  Value for checkAuthenticationCookie is : False  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh7   Medium  SPRequestModule.PostAuthenticateRequestHandler End  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh8   Medium  SPRequestModule.PostAuthorizeRequestHandler Begin   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh0   Medium  SPRequestModule.PostResolveRequestCacheHandler Begin    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh1   Medium  SPRequestModule.PostResolveRequestCacheHandler End  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime aj1kn   Medium  SPRequestModule.AcquireRequestStateHandler  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh2   Medium  SPRequestModule.PostAcquireRequestStateHandler Begin    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwh3   Medium  SPRequestModule.PostAcquireRequestStateHandler End  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwhu   Medium  SPRequestModule.PreRequestExecuteAppHandler Begin   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Claims Authentication   airze   Verbose Current identity context: '{"anonymous":"true","nameid":"@","userId":"@"}'  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Claims Authentication   anvuv   Medium  Context has no SMTP/UPN claims. IdentityContext: '{"anonymous":"true","nameid":"@","userId":"@"}'   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x23FC  SharePoint Foundation   Asp Runtime avwhv   Medium  SPRequestModule.PreRequestExecuteAppHandler End be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x0EE8  SharePoint Foundation   General af71    Medium  HTTP Request method: OPTIONS    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x0EE8  SharePoint Foundation   General af75    Medium  Overridden HTTP request method: OPTIONS be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x0EE8  SharePoint Foundation   General af74    Medium  HTTP request URL: https://[url_of_my_portal]    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x0EE8  SharePoint Foundation   General a08yd   Medium  Getting content database b0a853e3-6682-4ddb-a267-988b92539eaf from webApp 47db0ff9-ccf4-4518-9831-3b91e1f8bf8f version 2928535. be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x0EE8  SharePoint Foundation   Runtime an85c   Medium  recordStatus called with status(0x001E0002): Access Denied. be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Asp Runtime avwia   Medium  SPRequestModule.PostLogRequestHandler Begin be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Asp Runtime avwib   Medium  SPRequestModule.PostLogRequestHandler End   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Asp Runtime avwic   Medium  SPRequestModule.EndRequestHandler Begin be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Runtime ftc9    Medium  Access Denied: PreSendRequestHeaders, insufficient permission.  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Site Cache  az4z8   Medium  Looking up SPSite by ID 64da4339-0bc1-4970-b4bf-3510105f867a in memory. be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Flighting Infrastructure    awjmz   Medium  Using legacy MSO-FBA header.    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Site Cache  az4z8   Medium  Looking up SPSite by ID 64da4339-0bc1-4970-b4bf-3510105f867a in memory. be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   General b6p2    Medium  Sending HTTP response 403 - text/plain:403 FORBIDDEN.   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.03  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Runtime aigd0   Medium  An Exception occurred when setting the headers in PreSendRequestHeaders. This is error is ignorable in most cases. Error: System.Threading.ThreadAbortException: Thread was being aborted.     at System.Threading.Thread.AbortInternal()     at System.Threading.Thread.Abort(Object stateInfo)     at System.Web.HttpResponse.AbortCurrentThread()     at Microsoft.SharePoint.Utilities.SPUtilityInternal.SendResponse(HttpContext context, Int32 code, String strBody, String strContentType, Dictionary`2 headers)     at Microsoft.SharePoint.Utilities.SPUtilityInternal.Send403(HttpContext context)     at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)     at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PreSendRequestHeaders(Object oSender, EventArgs ea) be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Monitoring  b4ly    Medium  Leaving Monitored Scope: (Request (OPTIONS:https://[url_of_my_portal])) Execution Time=9.0951; CPU Milliseconds=4; SQL Query Count=0; Parent=None   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Asp Runtime avwid   Medium  SPRequestModule.EndRequestHandler End   be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Application Authentication  arftr   Medium  SPApplicationAuthenticationModule.IsBearerChallengeRequested: Return 'True'.    be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Claims Authentication   ah26c   Verbose SPOAuthHttpChallenge: Setting WWW-Authenticate header to:Bearer realm="87d64469-386e-4b12-bfc2-a405b44ca0e2",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000005-0000-0000-c000-000000000000@*,5148fd17-f9b2-4739-aa9d-462fedfcba7c@87d64469-386e-4b12-bfc2-a405b44ca0e2,00000003-0000-0ff1-ce00-000000000000@87d64469-386e-4b12-bfc2-a405b44ca0e2",cookie_uri="https://[url_of_my_portal]/_api/SP.OAuth.NativeClient/Authenticate"  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Claims Authentication   a1dea   Medium  SPOAuthHttpChallenge: Adding OAuth WWW-Authenticate challenge without clearing others.  be74d09d-6a91-200e-ee4e-df98ffb0a421
01.31.2017 16:22:51.04  w3wp.exe (0x0E8C)   0x13CC  SharePoint Foundation   Claims Authentication   ax3f1   Verbose SPSuspendedFeaturesHttpHeader: Setting x-ms-suspended-features header to:features=""    be74d09d-6a91-200e-ee4e-df98ffb0a421
  • Do you use ADFS&WAP with Kerberos or SAML Authentication? – MHeld Feb 1 '17 at 16:29
  • We configured with SAML Auth – domsen123 Feb 2 '17 at 8:22
4

And, here's an update: KB3203432 - https://support.microsoft.com/en-us/help/3203432/descriptionofthesecurityupdateforsharepointserver2016june13-2017 did seem to fix this problem (the 401 vs 403 issue) without using the module above. However, it then created another problem for us in our on-premises SP 2016 system with Office 2016 (and claims auth via AD FS). A note in the KB says this:

Administrators who wish to suppress modern authentication with Office 2016 applications can now configure the SPSecurityTokenServiceConfig object when the SuppressModernAuthForOfficeClients property is set to $false.

But in fact, after the update, the default value of SuppressModernAuthForOfficeClients is set to $false, which causes Office clients to fail authentication with the cryptic "Your organization's policies..." message. To get back to normal, you have to do this:

$c = get-spsecuritytokenserviceconfig
$c.SuppressModernAuthForOfficeClients=$true
$c.update()
5

Try this solution:

  1. HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity
  2. Check if EnableADAL key is present
  3. If not present then create new REG_DWORD key with name EnableADAL and value 0

This worked for me

  • Hi Miler, this solution is working... but after some research, I've read, that EnableADAL = 0 means "Microsoft Online Sign-in Assistant only."... Can you explain me, why I need to set this registry key on clients... because "reg key not presend" should be "modern authentication only"... – domsen123 Feb 14 '17 at 11:12
  • Hi domsen123, i can only guess that office client is not compatible with modern authentication on ADFS 3.0, and it seems that works with Microsoft Online Sign-in Assistant. Maybe ADFS 4.0 fully supports office client modern authentication .. – Miler Feb 14 '17 at 12:53
  • I wrote in the technet forum to get an explanation about this. Victoria from the MS Continget Staff wrote the following: "Office 2016 client application has modern authentication turned on by default(no registry key or the registry key EnableADAL=1) which will not work with SharePoint server, so we need to set the registry key EnableADAL=0 to turn off the modern authentication." social.technet.microsoft.com/Forums/office/en-US/… – domsen123 Feb 15 '17 at 9:24
3

I was having the exact same problem. Using SharePoint 2016, Office 2016, and ADFS 4.0/2016, the only way I can get it to work is to disable ADAL. ADAL is not supported for on-premise Exchange, so I wonder if the same is true for SharePoint as well. SharePoint 2013 in the exact same environment works OK.

Poking around in Fiddler, I can see a few differences with ADAL enabled/disabled. With it enabled, the request headers are different, the server returns a 401 vs a 403, and there is also a bit about hitting an OAuth URL.

With ADAL enabled: OPTIONS hxxps://sharepoint.domain/Shared%20Documents/ HTTP/1.1 Connection: Keep-Alive Authorization: Bearer User-Agent: Microsoft Office Word 2014 (16.0.4456) Windows NT 10.0 X-Office-Major-Version: 16 X-MS-CookieUri-Requested: t X-FeatureVersion: 1 X-MSGETWEBURL: t X-IDCRL_ACCEPTED: t Host: sharepoint.domain

HTTP/1.1 401 Unauthorized Content-Type: text/plain; charset=utf-8 Server: Microsoft-IIS/8.5 X-SharePointHealthScore: 0 SPRequestGuid: 75fed49d-4537-0085-da92-b195d2c7ea26 request-id: 75fed49d-4537-0085-da92-b195d2c7ea26 X-Forms_Based_Auth_Required: hxxps://sharepoint.domain/_login/default.aspx?ReturnUrl=/_layouts/15/error.aspx X-Forms_Based_Auth_Return_Url: hxxps://sharepoint.domain/_layouts/15/error.aspx X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically. x-ms-suspended-features: features="" X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 16.0.0.4483 X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly WWW-Authenticate: Bearer realm="{Removed GUID}",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000003-0000-0ff1-ce00-000000000000@{Removed GUID}",cookie_uri="https://sharepoint.domain/_api/SP.OAuth.NativeClient/Authenticate" Date: Tue, 14 Feb 2017 17:45:15 GMT Content-Length: 13

403 FORBIDDEN

With ADAL disabled: OPTIONS hxxs://sharepoint.domain/Shared%20Documents/ HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft Office Word 2014 (16.0.4456) Windows NT 10.0 X-Office-Major-Version: 16 X-MSGETWEBURL: t X-IDCRL_ACCEPTED: t Host: sharepoint.domain

HTTP/1.1 403 FORBIDDEN Content-Type: text/plain; charset=utf-8 Server: Microsoft-IIS/8.5 X-SharePointHealthScore: 0 SPRequestGuid: da02d59d-d5b7-0085-da92-b5fe7b8c3434 request-id: da02d59d-d5b7-0085-da92-b5fe7b8c3434 X-Forms_Based_Auth_Required: hxxps://sharepoint.epi.ophth.wisc.edu/_login/default.aspx?ReturnUrl=/_layouts/15/error.aspx X-Forms_Based_Auth_Return_Url: hxxs://sharepoint.epi.ophth.wisc.edu/_layouts/15/error.aspx X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically. X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 16.0.0.4483 X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly Date: Tue, 14 Feb 2017 19:02:05 GMT Content-Length: 13

403 FORBIDDEN

1

I'm currently having the same problem, and I have an open support case with Microsoft.

My environment is mostly Mac users, running various versions of Office For Mac 2016. There are also a few stragglers who haven't upgraded, and are still running Office for Mac 2011.

Unfortunately, I didn't catch this issue while testing my upgrade from 2010->2013->2016, so it's affecting my production environment.

While working with Microsoft to address the root cause of the issue, I developed workaround that transparently proxies the HTTPS requests and rewrites the headers. I am running this proxy in production.

Specifically, it removes the "Authorization" header from the client's request BEFORE the request is delivered to the server. This causes the server not to respond with a WWW-Authenticate header, and instead it sets the FedAUTH cookie - thereby enabling the Office Client application to load the document.

There are still some occasional issues: * Sometimes the client application displays the Site Collection Home Page instead of the ADFS login page * The Office for Mac client needs to be 15.30. Older versions of 2016 do not work (though 2011 works fine).

This forces the clients to always display the ADFS Sign in page.

I posted the sanitized server setup script here: https://github.com/crossan007/SharePoint-Office-16-Claims-Proxy

After cloning the repository, and installing vagrant / virtual box, you can run "vagrant up" and it will automatically start and configure the proxy server locally on your machine.

I'll follow up on this post when I get more details.

1

I dug into this, and here's the answer and a solution. The short answer is that SharePoint 2016 is returning a 401 status when it should return a 403 (as noted by the OP) and this is a bug. The specific use case that it breaks is that you open Word, then access a document that's stored in SharePoint from your recently accessed documents list. Assuming that you weren't previously authenticated, you are then prompted for Windows credentials even though (a) you're off-domain, and (b) the web application doesn't have NTLM enabled.

What's actually happening is that SP is generating the 403, but it's getting changed into a 401 by one of the modules in the pipeline. The solution that I found to work is to create an HttpModule and use that with your web application. The sole purpose of this module is to end the request with a 403 status before it can go awry. It does it only under a certain set of circumstances: the user agent is MS Office, and the http verb is "OPTIONS". Here's the code:

using System;
using System.Web;

namespace SP2016FilterModule
{
    public class SP2016FilterModule : IHttpModule
    {
        /// <summary>
        /// You will need to configure this module in the Web.config file of your
        /// web and register it with IIS before being able to use it. For more information
        /// see the following link: http://go.microsoft.com/?linkid=8101007
        /// </summary>
        #region IHttpModule Members

        public void Dispose()
        {
            //clean-up code here.
        }

        public void Init(HttpApplication context)
        {
            context.EndRequest += new EventHandler(OnEndRequest);
        }

        #endregion

        public void OnEndRequest(Object sender, EventArgs e)
        {
            var context = sender as HttpApplication;
            var request = context.Request;
            var response = context.Response;

            if (request.HttpMethod == System.Net.Http.HttpMethod.Options.Method
                && !request.IsAuthenticated
                && request.UserAgent.ToLower().Contains("microsoft office")
                && (response.StatusCode == 401 || response.StatusCode == 403))
            {
                response.StatusCode = 403;
                response.Write("403 FORBIDDEN");
                response.Flush();
                context.CompleteRequest();
            }
        }
    }
}

When you put the reference to this module in your (SharePoint web application) web.config, be sure to put it at the top, so it gets run first, because it's one of the other modules below that's responsible for the breakage. It looks like this (note that you'll have to sign your assembly in visual studio and generate your own strong name):

<modules runAllManagedModulesForAllRequests="true">
  <remove name="AnonymousIdentification" />
  <remove name="FileAuthorization" />
  <remove name="Profile" />
  <remove name="WebDAVModule" />
  <remove name="Session" />
  <add name="SP2016FilterModule" type="SP2016FilterModule.SP2016FilterModule, SP2016FilterModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=**your PKT here ***" />
  <add name="SPNativeRequestModule" preCondition="integratedMode" />

As a side note, the business in the referenced articles about "modern authentication" (what does that even mean?) is completely misguided and not helpful. Applying registry settings to every client that might access your system is also probably not a viable solution for most people.

1

This seems to have been fixed by KB3203432 - https://support.microsoft.com/en-us/help/3203432/descriptionofthesecurityupdateforsharepointserver2016june13,2017

1

Scott, this saved my day. After several days of investigation this was finally the solution. Thanks a lot for this post!!

We have NTLM and ADFS Trusted Provider activated on the Web Apps Default Zone and Used LDAPCP and SPBypassLoginPage which works great without the need of extending the Web App and use two different Zones for NTLM and ADFS Trusted Provider.

  • This does not provide an answer, once you have enough reputations you comment everywhere. – Asad Refai Mar 7 '18 at 12:23
0

The post above by Scott D Carson Solves the "Your organizations policies are preventing you from completing this action" I have been working on this and on the phone with our identity management providers helpdesk since CHRISTMAS!!!!!. Thank you so much Scott for probably saving my job. I have googled my brains off and finally came across this by accident. Im a one man show and I thought it was never going to happen.

$c = get-spsecuritytokenserviceconfig
$c.SuppressModernAuthForOfficeClients=$true
$c.update()

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.