I have a MOSS 2007 server where I have developed a custom SharePoint web 
service that searches using FullTextSQLQuery(). The web service is called 
from a web portal (a custom ASP.NET application) on another server in 
another Windows domain. The end user access the web portal using IE and 
Windows authentication, and through the web portal uses my search web service.

This means that I cannot call my search web service using the IE user's 
credentials, as I don't have his password (web portal and MOSS on different 
domains). Otherwise, if I could do it, then FullTextSQLQuery() would run 
using that user's context, which would solve my problem.

Can I impersonate the IE user before running FullTextSQLQuery? Presently, I 
try to do it by impersonating my application pool user to gain full access, 
then impersonate the IE user by passing the user token to SPSite():
  Guid siteID = SPContext.Current.Site.ID;
  SPUser user = SPContext.Current.Web.AllUsers[userName];
  SPUserToken token = user.UserToken;
  SPSecurity.RunWithElevatedPrivileges(delegate()
  {
    using (SPSite site = new SPSite(siteID, token))
    {
      FullTextSqlQuery kwQuery = new FullTextSqlQuery(site);
      . . .
     }
   }

However, this does not work. I do get search results but they include 
artifacts that the user has no access to. It seems like passing the user 
token to SPSite() has no effect.

Can I do true impersonation without providing a password? Or what are my 
other options to perform a user specific search?

Regards,
         Henrik

• Moved by Mike Walsh FIN Thursday, December 03, 2009 6:56 AM search q (From:SharePoint - Development and Programming)

Hi Henrik.

Have you tried settings up your ASP.NET application to use impersonation ?
That should make the web service call in the context of the calling user.

Regards,
Magnus

Hi Magnus,

and thanks for your reply.

In this case impersonation will not work. The ASP.NET application and MOSS are on different domain, and that will cause a Kerberos double hop problem. The IE user is authentaticated to the ASP.NET application but cannot pass the credentials on to the MOSS server. The double hop problem can be solved, but it requires a lot of Windows configuration, and this is a web service we plan to roll out to customers, where we cannot affect the servers.

Is there any way to programatically do the impersonation without a password?

Henrik

First try removing the RunWithElevatedPrivileges call and see if it works.

Unfortunately no. RunWithElevatedPriviliges() allows me to get all search results, without any user specific filtering done. If I try just

Guid siteID = SPContext.Current.Site.ID;
SPUser user = SPContext.Current.Web.AllUsers[userName];
SPUserToken token = user.UserToken;
SPSite site = new SPSite(siteID, token);
FullTextSqlQuery kwQuery = new FullTextSqlQuery(site);
. . .

then the search results will be filtered using the user name that called the web service, not the user userName. It seems that "token" in SPSite(siteID, token) has no effect - it does work when I use methods like SPWeb.GetSubwebsForCurrentUser() but not for FullTextSqlQuery().

Can I then use the user that called the web service to get search results? No, because when calling the web service you have to provide a user name and a password, and the password I haven't - the IE user authenticates himself using Windows authentication.

Henrik

Oh well it was worth a try. I did try creating an IntPtr from the SPUserToken and then pass that to the WindowsIdentity.Impersonate method to see if that would work but the SPUserToken in SharePoint cannot be duplicated for impersonation. The SPSite that is passed to the FullTextSqlQuery constructor is basically for getting the SearchContext used for searching and has no effect on security trimming. Looks like you will have to figure how to use Kerberos or somehow do your own security trimmming.

Here's how I did something similar. On a SharePoint farm that was kerberos enabled, I deployed a custom webservice that allowed me to do impersonated searching. see my post here: http://vishalseth.com/post/2013/11/05/Impersonated-Searching-against-SharePoint.aspx

I was able to accomplish this on my SharePoint 2010 environment. Blogged about it here: http://vishalseth.com/post/2013/11/05/Impersonated-Searching-against-SharePoint.aspx