Authentication requests when you open Office documents

When you open a Microsoft Office document from a web server, you might be prompted for authentication. The specific technical reasons are discussed in Microsoft Knowledge Base article 838028.  However, that article covers the underlying problem without offering any specific approaches on how to contend with the issue. That article was written to describe the behavior in Office 2003, but the same underlying behavior exists for the more current versions of Microsoft Office as well.

This document is intended to provide an overview of the issue and the various approaches to dealing with the issue. Currently there is no panacea. So, the most appropriate alternative will depend on what functionality is required for the intended audience and what configurations are workable. In most cases, a compromise approach will be required.

When Internet Explorer opens an Office document, the appropriate Office application is started with the path of the document. The Office 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 call the application to open the file from the local cache. However, when this occurs, if the opened file is changed and saved, the changes are only made to the local copy and not to the server copy.

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

As a new process 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. The user name and the password of the currently logged-on Windows user is then automatically sent to the server when authentication is requested without prompting the user.

To enable Internet Explorer to allow automatic logon, the option must be enabled for the zone where the site is. 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 all network connections that were established by using a Universal Naming Convention (UNC) path and websites that bypass the proxy server or that have names that do not include periods (such as http://local), as long as 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 on 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 with 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 "dots" in the URL).
• A proxy is detected, and the site URL matches the proxy bypass criteria.
• The site is a fully qualified domain name (FQDN), the webclnt.dll version is greater than or equal to 6.0.6000.20729, and the site URL matches the criteria that are specified in the Web Client service parameter registry value AuthForwardServerList. (See Knowledge Base article 943280 for more information.)

If your Windows logon credentials match those that are needed by the site, Integrated Windows Authentication should allow the client to be configured to automatically log on by using the Windows user name and password. Please be aware 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 needed to access the document (such as when 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 viable, the occurrence of credential prompts can become problematic. The following methods are some alternatives and their drawbacks:

Method 1: An alternative with full functionality but with a calculated risk

Using Forms Based Authentication (FBA) 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 with persistent cookies such as an Internet Security and Acceleration (ISA) server or a Forefront Threat Management Gateway. However, caution is advised because persistent cookies are not discriminating and can allow unintended applications to also take advantage of the shared authentication. This exposure can be reduced by an appropriate configuration of the time-out settings, but an element of risk is introduced.

In ISA 2006, by using HTML Forms Based Authentication with persistent cookies, 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 in another public location. However, cookie timeouts still apply, based on the timeout configuration in the ISA server settings.

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

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

Method 2: Client approaches that can reduce the impact

Leave the application open � For those who want to maintain direct-editing functionality but for whom FBA with persistent cookies is not an option, the users can reduce the impact 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 the user being prompted for credentials because the executing process has already been authenticated. Documents of different types that require a different application do still require a prompt for each new application that needs 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 only be done if the client computer is in a private trusted environment, and it should not be used on a public computer. (Many companies set a policy that prohibits the saving of passwords.)  Saving the password will not eliminate the request but will pre-populate it with the information so that only a single click/keystroke is needed to respond. The site should be added to the Trusted Sites zone if this approach is used.

Preconfigure the OPTIONS result � As mentioned in Knowledge Base article 838028, the OPTIONS call is not executed 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 clears the cache periodically. By default, it expires after approximately two weeks, although this time limit can be extended. An update was included in Office 2003 Service Pack 3 (and also available in 2007 Microsoft Office) that allows for the extension of this 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 will still assume 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 key 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 key but includes "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 result in a request for authentication.

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

There are also ways to configure a site so that additional credentials are not required by forcing the use of the locally cached document. However, the configuration will affect 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 with a 200 response can also result in 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 then it will return an appropriate 207 MULTI-STATUS response with XML containing the properties, values and individual status. The WebClient service also assumes that if the target host does not support PROPFIND that it will return an error status like 405 Method Not Allowed. However, if the WebClient service instead receives a response with a status code of 200 that does not contain well-formed XML then an 'Invalid Parameter' error is internally generated and passed along to the evaluation routine. Unfortunately the 'Invalid Parameter' error can also be raised when examining cookies and an expired cookie is found. Since the evaluation routine does not know who raised the error it does a check to see if cookies were present on the request. If there were no cookies present in the request then the 'Invalid Parameter' is safe to ignore and the service eventually concludes that it is not a WebDAV server; however, with cookies present it cannot make that determination so it treats it as an expired cookie and converts the error to 'Access Denied' before passing it back up the chain of calls. Eventually the 'Access Denied' is consumed by a component that interprets it as a needs for credentials and the Windows Authentication prompt is thrown. Either of the two alternatives that follow will address this specific cause.

Use content-type of 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 providing files through a custom web application (such as ASP or ASP.NET) this is discussed in Knowledge Base article 899927. See the "Hyperlinks from Internet Explorer to Office" section, which 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 folder separate from other files, the header may be added at the folder level in the web server configuration - the separation is prepferred so that other files do not pick up the header unintentionally.

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 engaged. For example, to do this with 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. On 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. It is not recommended to 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 needs browse or list permissions to succeed.

To prevent the second authentication request, the OPTIONS response must have a Return Status of something 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 with a "405: Method Not Allowed" message). However, if the files are located in the file system on the web server, the unwanted request can be avoided by changing permissions to allow the OPTIONS call to succeed and thereby result in a correctly formed "200" response.

For an IIS server, you can do this by enabling Anonymous access for the site in IIS Manager.

Note Only use this workaround if the native IIS WebDAV Web Service Extension is providing the WebDAV functionality. If FrontPage Server Extensions are being used, this workaround should not be implemented. 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 only requires 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 (as defined in IIS Manager but sometimes with the friendly name of "Internet Guest Account"). This allows required permissions to satisfy the OPTIONS call but still denies access to any content. The Office application will then open the document from the Internet cache.

The following Microsoft Knowledge Base articles contain more information about opening files or links in Microsoft Office:

838028 How documents are opened from a Web site in Office 2003

899927 You are redirected to a logon page or an error page, or you are prompted for authentication information when you click a hyperlink to a SSO Web site in an Office document

932118 Persistent cookies are not shared between Internet Explorer 7 and Office applications in Windows Vista

916658 You are prompted for credentials every two weeks when you try to view a Web resource in Office 2003

943280 You are prompted to enter your credentials when you access an FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured

[MS-OCPROTO]: Office Client Protocols Overview This overview discusses protocols that are shared by all of the client applications in Microsoft Office, and those protocols that are used by only specific Office applications to communicate with server applications.

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.