Authentication requests when you open Office documents


When you open a Microsoft Office document from a web server, you may be prompted for authentication. The specific technical reasons for this are discussed in Microsoft Knowledge Base article 838028.  However, that article doesn't explain to how to handle the issue. KB 838028 describes the behavior in Microsoft Office 2003. However, the same underlying behavior also exists for more recent versions of Microsoft Office.

This document provides an overview of the issue and the various approaches to handling it. Currently, there is no resolution. Therefore, the most appropriate workaround depends on what functionality is required for the intended audience and which configurations are workable. In most situations, a compromise approach is necessary.


When Internet Explorer tries to open an Office document, the appropriate Office application is started and provided the path of the document. The application then tries to access the document directly from the server. This differs from other browsers and other file types. Most browsers download the file, and then call the application to open the file from the local cache. However, if the local file is changed and saved, the changes are not saved to the server copy.

To establish the richest experience possible, the Office application first communicates with the server to determine the server type and which web authoring protocol is available. The application does this by making an OPTIONS request directly to the server.

Because it's a new process that is accessing the server, the Office application is required to renegotiate authentication. This method is more secure than a method in which the new process uses an existing authentication that was established by the browser. 


In most Intranet instances, this issue is most easily addressed by configuring the server to use Integrated Windows Authentication, and then configuring the client to enable automatic logon. When authentication is requested, the user name and the password of the currently logged-on Windows user is then automatically sent to the server without prompting the user.

To enable Internet Explorer to allow automatic logon, the option must be enabled for the zone in which the site is located. The Local Intranet zone has a default configuration of automatic logon with the current user name and password. The Local Intranet zone is defined as including the following:

  • All network connections that were established by using a Universal Naming Convention (UNC) path
  • Websites that bypass the proxy server or that have names that do not include periods (such as http://local)

    Note These websites are included only if they are not assigned to either the Restricted Sites or to the Trusted Sites zone. The Trusted zone has a default configuration of automatic logon only in the Intranet zone.

When you open Microsoft Office documents by using 2007 Microsoft Office on Windows Vista or a later version of Windows, the application tries to establish a Web-based Distributed Authoring and Versioning  (WebDAV) connection to the web server through the Web Client service. Starting in Windows Vista, the Web Client service uses the WinHTTP network protocol and does not use the zone manager. The logged-on user credentials are automatically passed only if one of the following criteria is met:

  • The site is a NetBIOS name (it has no periods in the URL).
  • A proxy is detected, and the site URL matches the proxy bypass criteria.
  • All the following conditions are true:
    • The site is a fully qualified domain name (FQDN).
    • The Webclnt.dll version is 6.0.6000.20729 or a later version.
    • The site URL matches the criteria that are specified in the AuthForwardServerList Web Client service parameter registry value. (For more information, see Knowledge Base article 943280.)

If your Windows logon credentials match those that are required by the website, Integrated Windows Authentication should allow the client to be configured to automatically log on by using the Windows user name and password. Notice that using Integrated Windows Authentication over an Internet-facing connection is not recommended or supported.

Keep in mind that if the credentials of the currently logged-on user are not what is required to access the document (for example, if the server and the workstation are not in trusted domains), the user is prompted to enter credentials. The general guideline is that if you must provide credentials to access a site, you typically must provide credentials to open a document.

When Integrated Windows Authentication is not a viable logon method, the occurrence of credential prompts can become problematic. In this situation, consider the following alternative methods and also their drawbacks.

Method 1: Full functionality that carries a calculated risk

Using Forms Based Authentication (FBA) together with persistent cookies

The only way to maintain direct-edit functionality and also not be prompted by the Office application is to implement a proxy/firewall server by using Forms Based Authentication together with persistent cookies. For example, you can use an Internet Security and Acceleration (ISA) server or a Forefront Threat Management Gateway. However, we advise caution because persistent cookies are not discriminating and can let unintended applications take advantage of the shared authentication. This exposure can be reduced by an appropriate configuration of the time-out settings. However, this introduces an element of risk.

By using HTML Forms Based Authentication together with persistent cookies in ISA 2006, applications outside the browser (such as Office applications) can use cookies. However, the cookies are "persistent." They are not deleted when you close the browser or the Office application, and so they could be accessed if the user was working in an Internet cafe or another public location. However, cookie time-outs still apply, based on the time-out configuration in the ISA server settings.

There is an option to "use persistent cookies only on private computers." This reduces this vulnerability, but the users must select "private computer" in the FBA form to enable the persistent cookie feature. (Users should select "private computer" only when they use computers that they own or trust.)

Note By default, beginning in Windows Vista together with Internet Explorer 7, persistent cookies are not shared unless the site is in the Trusted zone. This is because of the "Protected Mode" setting in Internet Explorer. For an explanation and a workaround, see Microsoft Knowledge Base article 932118.

Method 2: Client approaches that can reduce the effect

Leave the application open

Users who want to maintain direct-editing functionality but who cannot use FBA together with persistent cookies can reduce the effect of multiple prompts by leaving the application open after the first access is made. By closing only the document instead of the application, another document that uses the same application can be opened without prompting the user for credentials because the executing process is already authenticated. Documents of different types that require a different application still require a prompt for each new application that has to access the site.

Select "remember the password"

The requests for credentials can also be less intrusive if the user selects the option to remember the password. This should be done only if the client computer is in a private trusted environment. This method should not be used on a public computer. (Many companies set a policy that prohibits saving passwords.)  Saving the password does not eliminate the request. However, this prepopulates the field so that only a single click or keystroke is required as a response. If this approach is used, the site should be added to the Trusted Sites zone.

Preconfigure the OPTIONS result

As mentioned in Knowledge Base article 838028, the OPTIONS call is not run if the information was previously obtained and cached in the Office Protocol Discovery Cache.

Important Editing the registry key or values directly is not recommended. The easiest way to prepopulate the information is to copy and distribute the information after it was successfully populated on a test computer. The saved information is temporary because Office periodically clears the cache. By default, the information expires after approximately two weeks, although this time limit can be extended. An update was included in Office 2003 Service Pack 3 (and is also available in 2007 Microsoft Office) that lets you extend time up to 10 years. (See Knowledge Base article 916658.) The downside of using this registry entry is that if the web authoring protocol or server type changes, Office 2003 still assumes that the old information is valid.

The Office Protocol Discovery Cache

The Office Protocol Discovery Cache contains subkey entries for each web folder that is opened and that has successfully responded to an OPTIONS request. The registry subkey that is used by Office 2003 is as follows:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\Server Cache

Note 2007 Microsoft Office uses a similar subkey but includes the version number "12.0" instead of "11.0." Microsoft Office 2010 uses "14.0" instead of "11.0."

The maximum number of cache entries can be set through the MaxCount registry value under the same Server Cache key. Office removes old entries to increase available space if the maximum count is reached. If no space can be cleared, the results of the OPTIONS call are not cached.

Preconfiguring the OPTIONS response may not eliminate all requests for credentials. A PROPFIND or HEAD request can also cause a request for authentication.

Method 3: Alternative configurations if the web server does not support DAV or if reduced functionality is acceptable

You can also configure a site so that additional credentials are not required by forcing the use of the locally cached document. However, the configuration affects all users for that specific URL, and direct-editing functionality is disabled. Therefore, users will not be able to save directly to the server from the Office application. The documents must be edited offline and then uploaded to the server. The best approach depends on the specific scenario and the desired behavior.

Note Using Web servers that respond to a PROPFIND by returning a 200 response can also cause an authentication prompt if cookies are present. When the Windows WebClient service sends a PROPFIND request, it assumes that if the target host supports the PROPFIND request, it will return an appropriate 207 MULTI-STATUS response by having XML that contains the properties, values, and individual status. The WebClient service also assumes that if the target host does not support PROPFIND, it returns an error status such as "405 Method Not Allowed." However, if the WebClient service instead receives a response that has a status code of 200 and that does not contain well-formed XML, an "Invalid Parameter" error is internally generated and passed to the evaluation routine. Unfortunately, the "Invalid Parameter" error can also be generated when the service finds an expired cookie. Because the evaluation routine does not know who raised the error, it checks whether cookies were present in the request. If no cookies were in the request, the "Invalid Parameter" error can be safely ignored, and the service eventually concludes that it is not a WebDAV server. However, if cookies are present, the service cannot make that determination. Therefore, it treats the error as an expired cookie, and converts it to "Access Denied" before passing it back up the chain of calls. Eventually, the "Access Denied" error is consumed by a component that interprets it as a requirement for credentials and generates the Windows Authentication prompt. Both the following alternatives address this specific cause.

Use a content-type attachment (non-SharePoint)

When Internet Explorer issues the GET request, a web application may be able to explicitly mark the content as a read-only download when a live editing session is not intended. For servers that provide files through a custom web application (such as ASP or ASP.NET), this situation is discussed in Knowledge Base article 899927. See the "Hyperlinks from Internet Explorer to Office" section that describes how to use the "Content-Disposition:Attachment" header.

If the server is hosting files directly from the file system, and if the Office files are in a separate folder from other files, the header may be added at the folder level in the web server configuration. This separation is preferred so that other files do not pick up the header unintentionally.

If the content-disposition header has to be added to only certain file types, you can use URL rewrite in IIS to change the content disposition header. For information about how to do this, see the following Azure Support Team Blog article:

Disable WebDAV and/or the support of the OPTIONS and PROPFIND verbs (SharePoint and non-SharePoint)

If the web application is not intended to be used for WebDAV, the Web Service Extension that provides the WebDAV functionality can be set to Prohibited on a default server that is running IIS. (This might be WebDAV or FrontPage Server Extensions.) If the site provides WebDAV functionality through another extension, the provider of that extension should be involved. For example, to do this by using Windows SharePoint Services (WSS), the site should be configured to disable Client Integration, or the OPTIONS and PROPFIND verb should be inhibited. (To inhibit the OPTIONS and PROPFIND verbs on Internet Information Services (IIS) version 6, remove the verbs from the <httpHandlers> registration line in the web.config file. In IIS 7.0, use the HTTP Verbs tab of the Request Filtering feature to deny the verbs.) Be aware that this approach will open the content in read-only mode because this approach disables direct-edit functionality.

Note Office 2010 may issue a HEAD request in addition to the OPTIONS request. We recommend that you do not suppress the HEAD request because it may be used by other applications for other purposes.

Allow the OPTIONS call for anonymous (non-SharePoint)

To determine the server type and what type of web authoring protocol is available, Office first sends an OPTIONS call. The OPTIONS call requires browse or list permissions in order to succeed.

To prevent the second authentication request, the OPTIONS response must have a Return Status value other than a "401" code. If the web server is using a web application to access the files, the application could be changed to handle the OPTIONS request (such as by using a "405: Method Not Allowed" message).

However, if the files are located in the file system on the web server, you can avoid the unwanted request by changing permissions to allow the OPTIONS call to succeed. This generates a correctly formed "200" response. For an IIS server, you can do this by enabling Anonymous access for the site in IIS Manager.

Note Use this workaround only if the native IIS WebDAV Web Service Extension is providing the WebDAV functionality. If FrontPage Server Extensions are being used, you should not implement this workaround . This may seem counterintuitive for a site that is providing only restricted access. However, the limited access can be enforced at the file-system level. Because the OPTIONS request requires only List Content permission (typically at the root of the site), the folder permissions should be changed to "deny read" and "deny write" for the account that is used for anonymous access. (This account is defined in IIS Manager, sometimes by using the friendly name of "Internet Guest Account.") This allows required permissions to satisfy the OPTIONS call, but it still denies access to any content. The Office application will then open the document from the Internet cache.