SharePoint 2016: Office documents prompt for authentication on anonymous site


 

Consider the following scenario:

You have a SharePoint 2016 site that has been enabled for anonymous access.

You have some Microsoft Office (Word, Excel, PowerPoint, etc) documents in a library that anonymous users also have access to.

A user clicks on a (for example) Word document to open it. They receive a credential prompt, which is unexpected since the site is anonymous.

Clicking Cancel on the prompt may or may not allow the document to open in the client.

 

 

This may only happen if:

  • The client is using Internet Explorer (IE) or Edge for a browser.
  • The SharePoint 2016 farm build is less than 16.0.4639.1002.
  • The client has Microsoft Office installed.

 

Why are only IE and Edge affected?

Non-Microsoft browsers, (firefox, chrome, etc) just do an HTTP GET for the document. The document is downloaded to the local machine, where the Office client opens it.

Microsoft browsers (IE and Edge) try to do fancy integration stuff. They hand the URL off to the Office client and allow the client to do the connecting and opening.

Part of that process is issuing an HTTP OPTIONS call to the document library. That call receives a 401-unauthorized response from server, which is what produces the credential prompt.

Here's what that looks like in a Fiddler trace. Notice that the OPTIONS call comes from winword.exe, and not from the browser:

 

 

How can we make the prompt go away?

Step 1: First, you may need to upgrade your SharePoint 2016 farm.

Earlier builds will still respond to an anonymous OPTIONS call with a 401, even after you've completed step 3 (HTTP verbs) below.

I've tested this solution at the January 2018 public update build (16.0.4639.1002) and can confirm it works there.

January 2018 updates for SharePoint 2016:

https://support.microsoft.com/en-us/help/4011642

https://support.microsoft.com/en-us/help/4011645

 

Step 2: Disable Client Integration for the web application zone that you're using for anonymous access.

This step removes the MicrosoftSharePointTeamServices HTTP response header, in which case, the Office clients won't know it's a SharePoint site they're connecting to, and won't try to do the fancy integration stuff that creates the authentication prompts.

Go to Central Admin | Manage Web Applications | <your web app> | Authentication Providers | <Your anonymous zone>.

Set Enable Client Integration to "No"

 

Warning! You should not disable Client Integration on the Default zone for your web app. Doing so will prevent SharePoint Search from being able to crawl the content.

If you are using the Default zone for your public facing / anonymous access URL, you probably need to re-think your URL / web app configuration. Search must crawl the Default zone, in which case it's recommended to leave the Default zone as Windows authentication with Client Integration enabled. Extend the web app to another zone and use that as the public-facing / anonymous URL.

 

 

Step 3: Disable the OPTIONS verb for the anonymous web application zone.

Even with Client Integration disabled, the Office client will make an OPTIONS call to see if the server can do Web Distributed Authoring and Versioning (WebDAV).

We need to disable the use of the OPTIONS verb server-side so that the server responds to this call with a 404 – not found instead of a 401 – unauthorized.

Open IIS manager, choose your target site and choose Request Filtering.

Select the HTTP Verbs tab and select Deny Verb.

Type in OPTIONS and click ok:

 

 

 

 

Notes:

  • If you have multiple web-front-ends, this change needs to be made on all of them.
  • Like Step 2, this one assumes that this particular extension of your web application (zone) is only used for anonymous access. Making this change will break "Open with Explorer" (explorer view) functionality for the zone.

 

 

That's it. All browsers should now be able to open Office documents anonymously without prompting.

This is what the working scenario looks like in Fiddler.

We see that winword.exe still makes the OPTIONS calls, but the server responds with 404 this time, so the client is not prompted.

Word is able to handle this 404 and open the document directly.

 

 

 

 


Comments (0)

Skip to main content