Sharepoint Single Sign-On, Impersonation and the Double-Hop Problem

How do you overcome the identity double hop problem?

Windows credentials can only make one “hop” between machines on a network. The first hop is from the user’s browser to the web server; from here, to get to another machine on your network, a second hop is required.

There are two ways to work around this problem: 1) establish a delegation relationship between the web server and the other network machine, and configure the AD domain to allow Kerberos Protocol Transition, or 2) use the Win32 LogonUser API to switch to the user’s identity on the web server before making that single hop out to the other network machine.

Sharepoint Single Sign-On uses the second approach. The first approach is complex and probably akin to using a sledge hammer to crack a nut.

The great thing about the Sharepoint SSO service is that when creating Enterprise Application Definition’s, you can decide what credential fields are stored, so you can store, obviously, User names and Passwords, DB connection strings, Domain names and, well, other stuff you can put in a string.

So, as an example, a web part needs to collect information from a network machine to display in it’s UI to a user. You have two choices here, either the resource access needs to be done under the security context of the user (impersonation model), or, the resource access can be done under the security context of some ad-hoc user account (the trusted sub-system model).

In summary the webpart will retrieve security credentials from SSO, create an impersonation security context with those credentials using the LogonUser API, perform the resource access and then undo the impersonation.

We can overcome the double-hop problem using Sharepoint SSO while fulfilling both security models;

1. Trusted Sub-system Model

Create an SSO Enterprise Application Definition of type Group – all users will access network resources using the same credentials:

MbosDoDefSSO Display Name:   Mbos ESB Domain Access
  Type: Group
Username (Unmasked) = esbprocess
Password (Masked) = *****
Domain (Unmasked) = MIT

2. Impersonation Model

Create an SSO Enterprise Application Definition of type Individual – all users will access network resources using their own credentials:

MbosLoDefSSO Display Name:   Mbos ESB LogData Access
  Type: Individual
Username (Unmasked) = hardingp
Password (Masked) = *****
Domain (Unmasked) = MIT

First you’ll need to configure Sharepoint SSO, try google or this post here.

So assuming that you’ve configured SSO and set up these EAD’s, the next requirement is some code to do the impersonation which you can write, find on google or copy this one here.

Finally, you’ll want some code to get credentials from SSO, which I’ve reproduced below.

One thing to note, is that if you create an EAD of type Individual (Windows Authentication), when you call ISsoProvider.GetCredentials, a SingleSignonException exception will be generated if SSO doesn’t have credentials stored for the calling user, for the EAD.

In this case, you can make a call to ISsoProvider.GetCredentialManagementUrl to get the credential management URL to allow the user to enter their SSO credentials (for this EAD).

Putting these pieces together, accessing network resources either on behalf of the calling user, or as an ad-hoc user, can be accomplished as shown below;

    // get sso creds
    var ssoApp = SharepointSSO.GetEnterpriseApplication(C_SSO_EadId);
    using (new Network.Impersonator(ssoApp.Fields["Username"], ssoApp.Fields["Domain"], ssoApp.Fields["Password"],
          // perform your network resource access here


Sharepoint Single Sign-On accessor code.

using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;
using Microsoft.SharePoint.Portal.SingleSignon;

namespace Tools.Sharepoint.SSO
 class SSOApplication
  public IDictionary Infomation
  { get; set; }

  public IDictionary Fields
  { get; set; }

 class SharepointSSO
  private static string ConvertSecureStringToString(System.Security.SecureString pValue)
   IntPtr lValuePointer = IntPtr.Zero;
   string lValueAsString;
    lValuePointer = Marshal.SecureStringToBSTR(pValue);
    lValueAsString = Marshal.PtrToStringBSTR(lValuePointer);
   catch (Exception ex)
    lValueAsString = ex.Message;
    if (lValuePointer != IntPtr.Zero)
   return lValueAsString;

  public static SSOApplication GetEnterpriseApplication(string eadID)
   if (string.IsNullOrEmpty(eadID)) throw new ArgumentException("an EAD ID is required", "eadID");

   var ssoProvider = SsoProviderFactory.GetSsoProvider();
   var ssoCreds = ssoProvider.GetCredentials(eadID);
   var ssoApp = ssoProvider.GetApplicationInfo(eadID);
   var ssoFields = ssoProvider.GetApplicationFields(eadID);

   var creds = new SSOApplication
                 Infomation = new Dictionary(),
                 Fields = new Dictionary()
   creds.Infomation["ID"] = ssoApp.ApplicationName;
   creds.Infomation["Display Name"] = ssoApp.ApplicationFriendlyName;
   creds.Infomation["Contact Name"] = ssoApp.ContactName;
   creds.Infomation["Type"] = ssoApp.Type.ToString();

   for (int idx = 0; idx < ssoFields.Length; idx++)
    string ssoEvidence = ConvertSecureStringToString(ssoCreds.Evidence[idx]);
    creds.Fields[ssoFields[idx].Field] = ssoEvidence;

   return creds;

Published by

Phil Harding

SharePoint Consultant, Developer, Father, Husband and Climber.

3 thoughts on “Sharepoint Single Sign-On, Impersonation and the Double-Hop Problem

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.