Oi! Why can't I have my document, SharePoint?

Not a Sitecore issue this week – but an issue I've been suffering from whilst working on Sitecore projects none the less. Like many IT companies working in the Microsoft space, we have a SharePoint site where our project documents live. Quite regularly, when I try to open one of those documents I get a login popup. Despite the fact that SharePoint is in my "Local Intranet" sites in Internet Explorer.

Recently this managed to annoy me enough that I took the time to investigate and fix the issue. Here's what I found:

It doesn't really make sense at first: I click a document in SharePoint and get this:

I know I'm logged in to the network, I know that the DNS name for the SharePoint site is in my IE "Local Intranet" sites and I know that "automatic logon" is allowed for those sites. So why the login dialog?

After a bit of rooting around the Internet, and the usual game of "what are the correct Google keywords for my problem" I came across a Microsoft Knowledge Base article: KB943280 "Prompt for Credentials When Accessing FQDN Sites From a Windows Vista or Windows 7 Computer". Whilst this dates from 2011, this has allowed me to work out the issue.

It turns out to be down to how Windows accesses WebDAV shares. The Windows components that are used to access WebDAV are not the same ones that IE uses to deal with ordinary HTTP requests. So while you may be using IE (and its security settings) to access the SharePoint site, the attempt to load the document from SharePoint itself uses the "Windows HTTP Services" components by default – and crucially these never look at the IE Security settings.

These alternative components are configured to only ever send username and password information to sites that appear to be local. And it decides what "local" is based on the URL. If it's just a server name, i.e.: http://MyServer/document.docx then that's local. If it's a fully qualified DNS name, i.e. http://myserver.mycompany.com/document.docx then that's remote and security data will not be sent automatically.

And that's the root of the issue – I'm a full-time remote worker. Hence I am accessing SharePoint via a fully qualified DNS name since NetBIOS / WINS names don't work for me on the end of a VPN tunnel.

So how do I fix this?

I suppose I could just create a HOSTS file entry for the NetBIOS name of the SharePoint server. But that seems a bit inelegant. Load balancing, virtual machines or just a plain old migration to a new version make it seem more likely that eventually the IP address would change and I'd be confused for a while about why SharePoint appeared broken. Rather than hiding the symptom, I need to fix the underlying issue.

Reading through the Knowledge Base article above, it talks about two things. Firstly, a patch to change the behaviour of the Windows HTTP Services components to allow configuration to override this setting. And secondly it talks about the registry settings you can use.

Since the article was last revised years ago, I tried a quick test to see if the code in the hotfix was already present in my (well patched) install of Windows 7. Turns out that it is – so chances are you can skip the patching bit of the KB article if you're running a recent release of Windows. I'm not sure about Windows 8, as I don't have a machine to try it on, however.

The article talks about adding a single registry setting. Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters cretae a new "Multi-String value" entry called AuthForwardServerList. Modify its value, and enter DNS names for the server(s) you want to be treated as Local Intranet sites for the purposes of WebDAV.

You can use wildcards, protocols etc if you want, but make sure you think about the security implications of your settings. For example having http://myserver.* is a security risk, as this means WebDAV requests to a server named myserver.nastyhacker.com would get authentication data sent automatically. There is more detail about the security implications in the article, so if you're not sure read the details.

Having added the setting:

And then restarted the WebClient service:

I can now click files in SharePoint and not have to enter my credentials. Success.

↑ Back to top