You're prompted for credentials when you open documents anonymously in SharePoint Server 2016
Article
Applies to:
SharePoint Server 2016
Applies to:
Microsoft SharePoint Server 2016
Windows Installer (MSI) based version of Microsoft Office 2016 applications (does not apply to Microsoft 365 applications)
Anonymous access that is enabled for the SharePoint site or library
Accessing Office documents anonymously
Accessing Office documents by using a different account than the one that you used to logged in to Windows
Symptoms
When you open documents in SharePoint Server 2016 by using Windows Installer (MSI) based version of Office applications, you are prompted for credentials if the conditions in the "Applies to" section are met.
Why this issue occurs
Office applications send an Authorization: Bearer header for compatibility with SharePoint Online and OneDrive for Business. SharePoint Server 2016 sends an HTTP 401 authentication prompt because of an issue in the way that SharePoint Server 2016 on-premises handles requests that have the Authorization: Bearer header, and also because of the absence of the X-IDCRL_ACCEPTED: t header.
How to work around this issue
To work around this issue, disable OPTIONS requests for the affected web applications, and then use the URL Rewrite rules to effectively remove the Authorization: Bearer header from HEAD requests. Only supported URL Rewrite rules for SharePoint Server 2016 are used to remove a request header value. For more information, see Supportability of rewrites and redirects in SharePoint 2016, 2013, 2010, and 2007.
To implement this workaround, follow these steps.
Step 1: Block OPTIONS requests for the web application through Web.config
To block OPTIONS requests, change the Web.config file for the web application as follows:
Step 4: Add a rule to stop processing URL rewrite rules for other request methods
You can add a rule to stop processing further URL rewrite rules if the request method is not HEAD (change only HEAD requests). To do this, follow these steps:
Select the web application, and then select URL Rewrite.
In the right pane, select Add Rule(s) to add a new rule.
Type a rule name, such as Authrule-HEADonly.
In the Match URL section, specify the following values:
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: ^(?!.*\.aspx).*$
Ignore case option: selected
In the Conditions section, select Add, and then specify the following values:
Condition input: {REQUEST_METHOD}
Check if input string: Does Not Match the Pattern
Pattern: HEAD
Ignore case option: selected
Edit the Action section as follows:
Action type: None
Stop processing of subsequent rules option: selected
In the right pane, select Apply -> Back to Rules.
Note
Make sure that the rule is enabled. To do this, look for the Disable Rule option in the right pane. This option is displayed after you select the rule.
Step 5: Add a URL Rewrite rule to remove the Authorization: Bearer header
To effectively remove the Authorization: Bearer header for requests, use a URL Rewrite rule, as follows:
Select the web application, and then select URL Rewrite.
In the right pane, select Add Rule(s) to add a new rule.
Type a rule name, such as Authrule.
In the Match URL section, specify the following values:
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: ^(?!.*\.aspx).*$
Ignore case option: selected
In the Server Variable section, select Add, specify the following values and then select OK:
Server variable name: HTTP_Authorization
Value: None
Replace the existing value option: selected
In the Action section, specify the following values
Action Type: None
Stop processing of subsequent rules: selected
In the right pane, select Apply -> Back to Rules.
Note
Make sure that the rule is enabled. To do this, look for the Disable Rule option in the right pane. This option is displayed after you select the rule.
Resolve this issue in the SharePoint Server 2016 farm
Repeat all the steps from the previous section on every SharePoint Web Front End (WFE) server in the farm to make sure that all servers are configured identically. If you have already used rewrite rules, the two rules from the previous section need to be set as the last two in the list because the HEAD rule will disable subsequent rules.
Because of limitations in the IIS URL Rewrite extension, the rules can't currently be combined in a way that lets them work correctly. This situation may change in a future revision of the extension, or an alternative configuration may be found in the future. For now, these methods are the best confirmed way to resolve this issue by using URL Rewrite.