Collaboration optimize

Prevent unwanted credentials prompts with SharePoint Document Libraries

Many SharePoint users are plagued with being asked for credentials when opening Word or Excel files from a Document Library. In this case, the fix was a change of authentication protocol.

sharepoint-logo-thumb-081913.jpg
We use SharePoint Foundation 2010 for our intranet, and we wanted to make more use of Document Libraries. We added sample documents to try it out. While PDF files opened fine in the browser, we found that opening Word or Excel files prompted us to enter a username and a password. Even when we entered valid credentials, the dialog kept reappearing, and we had to press Escape to cancel the prompt. It would appear once more; if we cancelled it again, the document opened.

Searching for a solution soon showed that we weren't alone, although nobody's scenario seemed to quite match ours. Some people, for example, were opening documents from a server on the Internet, or their SharePoint was configured over multiple servers. Ours was a single, internal server.

I posted a question in the very helpful Spiceworks community, where the first suggestion was to check SharePoint's Alternate Access Mappings. All seemed well, although adding one of my URLs to Internet Explorer's Intranet Zone Sites list seemed to reduce the number of credentials requests from two to one.

Many articles suggested adding a registry key: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters\AuthForwardServerList

The problem this is trying to solve is when Windows decides that your server is on the Internet, despite you adding it to the IE Intranet Zone Sites list, and therefore asks for credentials. The idea is that you add your SharePoint server name to this key, restart the WebClient service, and all is well. But that didn't work for us.

By design

Continuing my research, I tried using the Trusted Sites Zone instead of Intranet without any luck.

Prompted by this article, I tried this: "Go to Control Panel >> User Accounts >> Manage Your Credentials and remove any credentials stored". No better.

Prompted by the same post, I then tried this: "Try disabling 'Sharepoint OpenDocuments Class' add-on in IE". You guessed it -- no difference.

I even found a post suggesting this behaviour was "by design and cannot be avoided". I couldn't accept that.

To make matters worse, I'd been working on my own PC with Microsoft Office 2007. When I attempted to demonstrate the issue on a colleague's PC with Office 2010, documents didn't open at all. However, after a bit of tinkering, I did get some files to open. I had to click through the usual credentials prompts, plus an extra pop-up saying the file couldn't be opened.

Web.config

Eventually I found a tip on Stack Overflow that seemed to help. I added these lines into the web.config file found on the SharePoint server at C:\inetpub\wwwroot\wss\VirtualDirectories\80:

        <add verb="OPTIONS" allowed="false" />
        <add verb="PROPFIND" allowed="false" />

The credentials prompts stopped when opening Word or Excel files on my PC. Progress! Unfortunately, on PCs running Office 2010, the prompts were still there.

By now I'd been chasing this down for three months. I gritted my teeth and did more research, which led me to suspect a connection with Kerberos authentication. I brought my idea, and the story so far, back to the Spiceworks community.

Finally, a configuration change in SharePoint Central Administration solved the problem. As I posted at the time:

"The solution (for me) was to change the Authentication Provider for the SharePoint web application to use NTLM instead of Kerberos. This gave me two benefits:

  • No more unwanted credentials prompts when opening MS Office docs from the doc library (Office 2007 or Office 2010).
  • The setting of Integrated Windows Authentication (IWA) in IE now makes no difference whether enabled or disabled -- the user gets logged in and can open the documents either way."

So what was the root cause? We have another SharePoint installation, also configured with Kerberos, which doesn't suffer the same problem. My guess, therefore, is that Kerberos was never set up properly for some reason. (I seem to recall changing my mind about a few things during the initial setup project, and I may have done something out of sequence.) As one of the contributors on the Spiceworks community put it, "You need to set up a bunch of stuff for it to work. Just turning it on will not cause it to work."

Summary

Being asked for credentials when opening Word or Excel files from a Document Library is a common frustration for SharePoint users. In this case, it seems the Kerberos authentication protocol was misconfigured, and changing to NTLM cured the problem.

About

Mark Pimperton BSc PhD has worked for a small UK electronics manufacturer for over 20 years in areas as diverse as engineering, technical sales, publications, and marketing. He's been involved in IT since 1999, when he project-managed implementation ...

1 comments
klashbrook
klashbrook

Technically speaking... that's not a fix.  Falling back to NTLM is a workaround

And to be honest, we should all be striving to eliminate NTLM authentications, not disabling Kerberos.

NTLM is old, slow and out-dated. Plus it adds a great deal of load to your domain controllers with all those challenge/responses.

A better solution might be to ensure Kerberos is working correctly (easily done with WireShark), and implement the AuthForwardServerList registry setting as described here:  http://support.microsoft.com/kb/943280/en-us