SharePoint - SharePoint and Double Hop Issue

Asked By Mr. Smith

21-Jul-08 11:14 AM

Hello all I am trying to understand what might be wrong here so if someone
could point me in the correct direction I would gladly appreciate it.

Issue:   Computers which are not members of active directory having issues
when access sites which pass authentication information to other servers.

My Description:  Users access my SharePoint site where links are setup to
perform a "double -hop" to another server such as CRM.  These sites are all
hosted internally and seem to work just fine.
However, we a non domain user tried to access the site in the same manner
they are propped for domain user / password.  Password information is
entered by the user and they can browse SharePoint just fine so it seems,
but when they try to access the link which should pass their security over
to the CRM server it fails with an anonymous user logon failure.

Question:  Why does this happen, what can I do to correct this outside of
adding that computer to the domain.  And is there any KB out there which
covers this?

Thanks for any help you all might provide

Mr. Smith
Systems Administrator

21-Jul-08 12:33 PM

Hi Mr. Smith,

To understand the Double-Hop issue and why it occurs, there is an excellent
blog post which you can find here:

http://blogs.msdn.com/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx

As for possible resolutions, there are two directions you can look. Kerberos
authentication (versus NTLM) or Single Sign On (available via MOSS 2007).

Hope this helps,

Jerry

--
-- Jerry D. Sevier
Microsoft Practice Director
Tech-Pro, Inc
Blog: http://www.jerrysevier.com
{SharePoint} {Commerce Server}

22-Jul-08 10:59 AM

This isn't really the double-hop problem.  Following a link from one server
to another is still single-hop--the server does not pass credentials because
it's not involved in the transfer; it merely tells the client browser where
to make it's next request.  It's the same as if you typed the URL for the
second server in your browser.  A double-hop problem occurs when one server
makes a request of another server using the client's credentials...which it
does not have.  But creating a link to another server just transfers the
browser from one to another--still only one hop.

In your case, you have two scenarios.  Domain users and non-domain users.
Domain users browsing the intranet zone do not have to log in on each server
because their local machine is already authenticated, and IE passes their
credentials to intranet sites.  If your non-domain users log on to one
server, and then go to another one, they have to log on each time, because
their local machine is not authenticated to the network.  You can manually
add a site to the Intranet Zone in your browser, then saved passwords will be
used each time they visit that same server.

It does seem a little weird that you have non-authenticated users on your
network, though, unless you're talking about an extranet scenario.



Regards,
Mike Sharp

25-Aug-08 10:42 AM

In addition to rdcpro:

When an application (CRM or MOSS) uses an FQDN url, internet explorer thinks
this is an Internet hosted site. Even if you explicitly put it in the
intranet zone.

The solution is to install SP1 for windows vista and change a registry
setting that will follow below.
If you don't want to install SP1, you can install the hotfix as described in
the following article: http://support.microsoft.com/?id=943280

The registry setting:

After you apply this hotfix, you have to create a registry entry. To do
this, follow these steps: 1. Click Start, type regedit in the Start Search
box, and then press ENTER.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
3. On the Edit menu, point to New, and then click Multi-String Value.
4. Type AuthForwardServerList, and then press ENTER.
5. On the Edit menu, click Modify.
6. In the Value date box, type the URL of the server that hosts the Web
share, and then click OK.

Note You can also type a list of URLs in the Value date box. For more
information, see the "Sample URL list" section in this article.
7. Exit Registry Editor.
After this registry entry is created, the WebClient service will read the
entry value. If the client computer tries to access a URL that matches any of
the expressions in the list, the user credential will be sent successfully to
authenticate the user, even if no proxy is configured.

Note You have to restart the WebClient service after you modify the registry.

Sample URL list
The following is a sample URL list:
https://*.Contoso.com
http://*.dns.live.com
*.microsoft.com
https://172.169.4.6

25-Aug-08 01:40 PM

That is close, but not exactly correct.

The problem with Vista and FQDN is when an application uses WebDAV, which
uses the Webclient service.  This usually occurs when an Office application
attempts to connect with the server, but it could happen with IE if it's
using WebDAV.  In Windows XP, the Webclient service used WinInet, which knows
about and obeys the IE zones, but with Vista it now uses WinHTTP, which has
no clue about the IE zones, hence the mods that Heine suggested are needed.

But Internet Explorer still knows about the Intranet zone on Vista, unless
you're using it to access a WebDAV resource.  For normal FQDNs to web sites,
IE will handle Intranet Zone sites just fine, even on Vista.

Unfortunately, IMHO the published Microsoft fix not a good one for
non-domain users, because you can't really have people messing with their
registry, and a registry-based whitelist is not a good solution to the
problem.  Within a domain, you can use a group policy to do this, but
obvously not for non-domain users.  I really wish Microsoft would address
this problem, but it seems like it's not even recognized that people would
use a FQDN on an intranet.  It's been a showstopper for me with clients who
use hosted SharePoint and Vista.  You lose all the office integration
features that they want.  At that point, you might as well use Forms Auth.

Regards,
Mike Sharp