Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have an ASP.NET MVC app that connects to SharePoint 2010 via the Client OM. When I run ExecuteQuery(), I get a HTTP 401 error from SharePoint.

I have the MVC app set to impersonate the logged in user.

The impersonate setting in web.config (of the MVC app):

<configuration>
    <system.web>
        <identity impersonate="true" />
    </system.web>
</configuration>

The code:

Client Context ctx = new ClientContext("http://sharepoint.company.com/site");
ctx.Credentials = CredentialCache.DefaultNetworkCredentials;

Web web = ctx.Web;
ListCollection lists = web.Lists;

ctx.Load(web);
ctx.Load(lists);

ctx.ExecuteQuery();

The exception:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute() at Microsoft.SharePoint.Client.ClientContext.EnsureFormDigest() at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery() at MVCApp.Services.SharePointService.GetLibraries()

When I remove the impersonation setting from web.config, the Client OM uses the MVC app's app pool account to connect. When this happens, the connection is successful (after granting the app pool account permissions). Also, if I hard code a user credential instead of using DefaultNetworkCredentials, the connection works as well.

The app is configured for Windows authentication, and Anonymous authentication is disable in IIS.

Things we have tried:

  1. ensure the app pool accounts are able to delegate permissions.
  2. verified kerberos configuration (we removed some duplicate SPNs)
  3. connect from a different server (we are hosting this app on the SharePoint App Server). Connecting from this server means we can't connect to ANY sharepoint instance. Connecting from another server allows us to connect to our DEV environment, but not this server (QA) or our production environment.

What can I do to get the Client OM to delegate the user permissions when connecting to SharePoint?


Update

Interestingly, I tried a simple WebRequest to SharePoint, with identical results, which tells me that the issue is not caused by the Client OM:

WebRequest request = WebRequest.Create("http://lopenet.qa.gcu.edu");
request.Credentials = CredentialCache.DefaultNetworkCredentials;

using(WebResponse response = request.GetResponse())
using(StreamReader reader = new StreamReader(response.GetResponseStream()))
{
    return Content(reader.ReadToEnd(), "text/html");
}
share|improve this question
    
Just for the record, there is a closing '>' in your web.config for the identity item right? –  Zork Jun 8 '12 at 19:14
    
@Zork I just noticed that and fixed it. Yes, that was a typo. –  Kyle Trauberman Jun 8 '12 at 19:20
add comment

4 Answers 4

up vote 2 down vote accepted

This sounds a lot like you are hitting the notorious NTLM Double Hop Problem and I'm sorry to say that there is no way around it aside from changing your authentication to Claims or Kerberos. Neither of which should be taken lightly.

If your code runs on the one of the machines in the SharePoint farm you are attempting to interact with, then you can probably get around this by skipping the second 'hop' altogether and interacting with SharePoint directly via the Object Model on the server rather than through web services.

share|improve this answer
    
We are using Kerberos on the SharePoint side. Do I need to change any settings on the MVC app side? –  Kyle Trauberman Jun 8 '12 at 21:11
    
And as for using Server OM vs Client OM: I'm aware of that. The decision was made to use Client OM because this app may end up living on another server without SharePoint installed. –  Kyle Trauberman Jun 8 '12 at 21:13
    
If you are using Kerberos then you need to use it all the way from the original user request to your site to the calls to SharePoint –  Dave Wise Jun 8 '12 at 21:32
add comment

Do you have <authentication mode="Windows" /> in there somewhere as well? I believe that is also required.

The below link has some information on the output of a few variables based on the configuration settings of the web.config and IIS

http://stackoverflow.com/a/1688220/1282079

share|improve this answer
    
Yes, the app is configured for Windows Authentication, and Anonymous access is disabled. –  Kyle Trauberman Jun 8 '12 at 19:50
    
When I write the values of the variables in the answer you linked to, I get results as described in the last example, yet the connection to SharePoint still gives a 401. –  Kyle Trauberman Jun 8 '12 at 20:04
    
Dang, the only difference i see anywhere i look is that most people use the using statement to ensure everything is properly disposed (best practice), but I cant find anything else, sorry. –  Zork Jun 8 '12 at 20:22
    
And I am doing that, I just distilled the example for this question. Thanks for taking a look. :) –  Kyle Trauberman Jun 8 '12 at 21:12
add comment

Does the below link help? I am also facing a similar problem.

http://stackoverflow.com/questions/11691650/getlistitems-request-failed-with-http-status-401-unauthorized/11843756#11843756

share|improve this answer
1  
Some information as to why the url would be of help, would be more useful to people when scanning answers. –  Hugh Wood Nov 22 '12 at 16:56
add comment

Almost two years passed but recently I’ve had the same problem with SharePoint 2013 (I’ve actually accessed SP2013 with SP 2010 CSOM libraries). Finally I’ve managed to sort it out.

First, I assume the Kerberos authentication was functioning correctly in you case. Just to be on the safe side, you can turn off NTML authentication in IIS settings or display on your test page

Thread.CurrentPrincipal.Identity.AuthenticationType

Should be Negotiate. There’s no point in trying delegation when you actually log on with NTML, which can happen when you have both allowed.

Next, the update to your question. It helped me a lot, I’ve realized that we shouldn’t worry about CSOM when the simplest delegation with WebRequest doesn’t work. The problem is here.

And finally, this inconspicuous link from the S J answer can actually provide the solution – you mentioned all steps in configuring delegation except allowing delegation for the SERVER. Yes, you must configure that you trust both the account for delegation (which you mentioned) and this specific machine for delegation.

And one more quite obvious thing – the SharePoint itself needs to be properly configured for Kerberos authentication.

Once delegation for a web request works (e.g. loading the start page), you can do the same with CSOM. I’ve tested it, works like a charm.

The difference is that I’ve (1) used SP2013 with 2010 CSOM, (2) turned on delegation just for specific fragment rather than for the whole request:

string ImpersonatedSpLogin = null, ImpersonatedSpMail = null;

WindowsIdentity identity = (WindowsIdentity)User.Identity;
using (var impersonationContext = identity.Impersonate())
{
    using (ClientContext context = new ClientContext("http://myServer.somewhere.com/"))
    {
        context.Load(context.Web.CurrentUser);
        context.ExecuteQuery();
        ImpersonatedSpLogin = context.Web.CurrentUser.LoginName;
        ImpersonatedSpMail = context.Web.CurrentUser.Email;
    }

    impersonationContext.Undo();
}
// now you can verify by checking  ImpersonatedSpLogin and ImpersonatedSpMail

Hope that helps anyone.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.