Windows 7 Prompting for Authentication When Accessing SharePoint Documents



I’m still enjoying the experience as a new Windows 7 user. However, one of the problems I ran into recently was the repeated and constant prompting for username and password when accessing a document in my SharePoint repository. Actually, I was getting prompted twice despite the fact the SharePoint server is on my local network and in the same domain. Once for the initial SharePoint logon and the second when accessing office documents in a document repository. The first prompt was an easy fix and was due to the fact I access my SharePoint Site using its Fully Qualified Domain Name (FQDN) at sharepoint.company.com. As a result, IE believed the local SharePoint server to be on the Internet and thus considered in the Internet Zone.

To fix this:

1. Open IE, Select Tools –>Internet Options  -> Security Tab and Select Sites

image

2. Ensure “Automatically detect intranet network” is checked and click Advanced

image

3. Add your SharePoint server’s fully qualified domain name. In my case, I chose to use an asterisk as a wildcard (*.companyname.com) to represents all hosts in my local intranet.

WARNING: Be very careful when using a wildcard on this setting to ensure your credentials are only used to connect to trusted servers on your “internal” network and not on the Internet. As an example, you would never want to use *companyname.com which can be easily spoofed and lead to passing internal domain credentials to a non-trusted external system.

image

4. In addition, when back on the Security tab, Click Custom Level and scroll down to the bottom of the Local Intranet Zone settings and ensure “Automatic logon only in Intranet zone” is checked.

image

5. Close and re-open your browser. You should no longer be prompted when accessing your local domain’s SharePoint server.

Well, that took care of issue number one but I was still getting prompted when opening an Office 2007 document from a SharePoint Document Repository. However, once the credentials are entered, the prompt goes away… for a while. Actually, I believe the credentials are simply not cached between logons and return when I access the document repository following logons or reboots. Anyway, this turned out to be due to the fact Microsoft changed the way online documents are accessed via Web Distributed Authoring and Versioning (WebDav). According to KB 943280, a windows Vista Client will be prompted for a username and password under the following conditions:

  1. A proxy server is not configured in Internet Explorer
  2. WebDav is used to access a fully qualified domain name site

Well, I can tell you that I did not have a proxy server configured and my SharePoint document repository was certainly a WebDav site accessed via FQDN

Although the KB article is meant for Vista, Windows 7 is essentially Vista version 2 so I figured it would hold the key. However, the hotfix listed in the article would not be applicable as it was included way back with Vista SP1 anyway and Windows 7 was bound to include that functionality.

Anyway, the fix for this is as follows:

1. Open Registry Editor to: HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

2. Add a new key using Multi-String Value

3. Enter AuthForwardServerList  for the new key name

4. Edit the new key and enter the FQDN of the SharePoint or WebDav Server.

(In my case, I used *.companyname.com again. )

5. Close Registry editor, go to services in Computer Management and restart the WebClient service.

Alternatively, you can simply open a command prompt with elevated permissions and enter the following line (edited with your server info of course):

reg add HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters /v AuthForwardServerList /t REG_MULTI_SZ /d *.companyname.com

You can restart WebClient in the same command prompt, type: Net Stop WebClient && Net Start WebClient

That’s it, seamless passthrough authentication to SharePoint!

Reference: http://support.microsoft.com/kb/943280/en-us



Subscribe / Share

Article by Paul Beckford

Paul Beckford is an IT professional based in Denver, Colorado. Over the last dozen years, Paul has worked “hands-on” in an IT Operations role deploying and supporting a multitude of technologies, such as Network Infrastructure, Windows and Linux servers, most Microsoft Back Office & Infrastructure applications, Virtual Computing, Mobile Computing and Information Security. Paul Beckford tagged this post with: , , , Read 88 articles by
14 Comments Post a Comment
  1. [...] de Windows de los clientes para que funcione MS Office correctamente, como vimos en el webinar, o lidiar con la solicitud de contraseña varias veces. Si activamos SSL no es necesario modificar el registro en los clientes. Además, recuerda que se [...]

  2. Victor C says:

    This solved the problem one of our users was having. I had to do both steps because the problem still occurred after I did the 1st step. Creating the registry entry completed the solution. Thank you very much for this tip.

  3. Cris Vinluan says:

    Thanks for the hot tip?

  4. Malte says:

    Great solution.
    The credential requests became quite annoying.

  5. Ted says:

    Thank you Paul,

    Your IE fix worked great, but I’m concerned about the security implications you mention. I have a server offsite using WebDav, not SharePoint. We’re using it as an organization wide file server accessible over the web. Will the spoofing potentially give someone access to our files? I am only using Windows Authentication, not Basic, on an SSL connection. We access it by mapping to https://files.ourdomain.com. Is there a way to do this securely without the constant prompting that makes everyone want to kill me?

    THANKS!

  6. David says:

    Thanks for the solution.

  7. You know, the first solution I proposed above (adding *.companyname.com to local intranet) worked great when I tested and when we rolled it out but over time, there continued to be reports of a few users who were still getting prompted. I’m not entirely certain why it fixed it for most folks and not others, but in the end, we had to eliminate the wildcard and use the actual FQDN such as servername.companyname.com

  8. pmh says:

    Paul, thanks for the tip. The reg fix worked perfect for me with a https FQDN sharepoint site using ie8 running on win7 with office 2007.

    My setup is slight different than yours. We have our https site setup in
    ie8 trusted sites as were using a self signed ssl cert. Our custom level is set to “Auto logon with current user name and password” Main reason we use this is because the laptops are joined to our domain.

    Works really well, no need for the user to auth to anything other than when they log into their laptop with user id and pw.

    Thanks for a really great tip.

    Paul.

  9. Hi Jawad, Thanks for the tip. I’m going to test that out as soon as I get a chance.

  10. Jawad says:

    Another solution is
    http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/023f4b23-3ce6-4d83-8cb0-7398b88ba6ab/?prof=required

    WebDav needs to be removed from the feature list of IIS (Web Server) to make the sharepoint 2007 work in Windows Server 2008 R2 x64 environment. hope it helps.

  11. David says:

    This seemed to work for us! Thank you!

  12. Richard says:

    I was thrilled to see this solution. Our XP users do not have this problem but all Win7 do get prompted for authentication. I was disappointed that this solution did not work for us.

    • Hi Richard,

      Sorry to hear the solution did not work for you. Everyone’s environment is different so perhaps the root cause is slightly different for you. If you find the answer your looking for, perhaps you can post and update here so everyone can benefit?

      Thanks, Paul

Leave a Reply




Be Cool - Shop @ Geeks.com


1 FREE Audiobook RISK-FREE from Audible