12

I have a Windows 7 system built (per MS' instructions) with SharePoint 2010 Server. I'm writing a simple console application on it that attempts to use SharePoint's Managed Client Object Model to connect to the SharePoint instance running on the same system as the console application (this is a development rig).

using (ClientContext context = new ClientContext("http://localhost"))
   {
      context = new NetworkCredential("username", "password", "domain"); 

      Web web = context.Web;
      context.Load(web);

      Log.Debug("Loading web.");
      context.ExecuteQuery();

      Console.WriteLine(web.Title);
   }

Upon calling ExecuteQuery, the application throw a System.Net.WebException.

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

The user account I'm creating the NetworkCredential with is a site collection administrator (and, incidentally, is also a farm admin as this is just a development machine).

  1. Is there a way to configure the Managed Client Object Model's permissions?
  2. Why might a user with such credentials be Unauthorized to use to the Managed Client Object Model?

Update 1:

I'm seeing the 401 in the IIS log with:
sc-substatus = 2,
sc-win32-status = 5

Update 2:

Per Steve B's advise, I've done the following:

  1. Disabled Kerberos as an available authentication provider in my IIS 7 configuration (so it uses NTLM exclusively) by running the following command:
    • %WINDIR%\system32\inetsrv\appcmd set config /section:windowsAuthentication /-providers.[value='Negotiate']
      • The IIS web was already set to use Windows Authentication
  2. Restarted computer.
    • Trying upon returning yielded new log results. Described below.
  3. Created the DisableStrictNameChecking REG_DWORD key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters and set its value to a Decimal 1.
  4. Whitelisted the loopback check by creating the BackConnectionHostNames Multi-String Value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 and added my system's short and full hostnames (one per line) to the value.
  5. Restarted computer.
    • This yielded the same log results mentioned previously (again, provided below) but changed the logged server address from a complete IPv6 address to an IPv6 loopback address (::1).
  6. Disabled the loopback check entirely by creating REG_DWORD DisableLoopbackCheck at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and setting value to Decimal 1.
    • Restarted and tried again: this yielded no change since #5 so I reverted to the whitelist solution.

The codes in the log have changed with these adjustments. I see the following every time I run my application:

  1. 401.2, sc-win32-status 5
  2. 401.1, sc-win32-status 2148074254
  3. 401.1, sc-win32-status 2148074252
7

Solved !! Why WPF Authentication wouldn't work when Silverlight works. (WPF was trying to use Kerberos, Silverlight was using NTLM) - Simple fix:

ClientContext _clientContext = new ClientContext(sharePointSiteUrl);
Web _web = _clientContext.Web;

_clientContext.Load(_web, website => website.Title);
_clientContext.Load(_web.Webs);

CredentialCache cc = new CredentialCache();
cc.Add(new Uri(sharePointSiteUrl), "NTLM", CredentialCache.DefaultNetworkCredentials);
_clientContext.Credentials = cc;
_clientContext.AuthenticationMode = ClientAuthenticationMode.Default;

_clientContext.ExecuteQuery();
ListCollection _listCollection = _web.Lists;
  • 2
    As someone who doesn't really grok the various authentication methods for SharePoint, I've been having an almost identical issue, except for some users it would work and others it wouldn't. MANY MANY thanks for the pointer towards using (1) a credential cache and (2) the NTLM argument within it. Fixed the issue very nicely, and given me something to go and read up on. – tobriand Jul 2 '15 at 11:41
  • 1
    Many many thanks for taking the time to add this. Helped me too – Nicholas DiPiazza Nov 9 '17 at 18:10
  • Thanks heaps for taking your time to add this :) helped heaps – Egli Becerra May 20 at 7:04
4

try to use the CredentialCache (from memory) :

using (ClientContext context = new ClientContext("http://localhost"))
{
    CredentialCache cc = new CredentialCache();
    NetWorkCredential nc = new NetworkCredential("username", "password", "domain"); 

    cc.Add(new Uri("http://localhost"), "Negotiate", nc));

    context.Credentials = cc; 

    Web web = context.Web;
     context.Load(web);

    Log.Debug("Loading web.");
    context.ExecuteQuery();

    Console.WriteLine(web.Title);
}

there are also others cases where the return http code is 401, and subcode 401.1 or 401.2. Unfortunately the only way to discover them is to look inside IIS logs. the two have some causes that can be threated with different solutions. Tell us if it's the case.

[Edit] As you said you have a 401.2 error, take a look at my former answer here : 401 IIS Error for SearchAdmin.asmx. I bet it's the same.

  • The CredentialCache didn't fix it. Your implementation was close but nc, and "Negotiate" are in the wrong order in your example (switch them and it'll be right). My IIS log is reporting sc-status 401, sc-substatus 2, sc-win32-status 5 – antik Mar 21 '11 at 16:14
  • @antik: take a look at my edit – Steve B Mar 21 '11 at 16:22
  • @Steve: added a response to your edit to my question. – antik Mar 22 '11 at 1:23
  • @Steve: btw - I'd up vote your answer if I could: I do not have enough rep yet. – antik Mar 22 '11 at 1:29
  • can you try to use kerberos instead of ntlm ? it's more secure and can help you to solve your problem. The drawback is that you will have to set up a spn on your domain. – Steve B Mar 22 '11 at 9:37
3

My capability here has become functional but a lot has changed on the box since then so I won't be able to isolate which particular change resolved the issues I was experiencing.

The following considerations were relevant to the repair of this capability on my system:

  • Destroyed and re-created my web application.
  • I had a misconfigured element in my web.config. The element was inside of the element.
  • I (re-)added to the element of the web.config.

Also, I'm using the following in my console application to connect to the API:

Uri uri = new Uri("http://localhost");
using (ClientContext context = new ClientContext(uri))
{
   context.Credentials = CredentialCache.DefaultNetworkCredentials;

   Web web = context.Web;
   context.Load(web);

   context.ExecuteQuery();

   Console.WriteLine(web.Title);
}
  • 1
    Its probably the following line which worked: context.Credentials = CredentialCache.DefaultNetworkCredentials; – Vardhaman Deshpande Apr 28 '11 at 16:35
  • Thanks for the detailed question and the answer. I learned a lot while configuring my development laptop and the solution described above works. However, everytime I open the browser I get the annoying prompt requesting for username/password. Entering or canceling has no impact to the application. Any ideas? – user19599 Sep 18 '13 at 12:41
  • @user19599 Is your browser Firefox or Chrome? It sounds like your SharePoint is setup for NTLM authentication which Firefox and Chrome, last I looked, don't do out of the box without prompting the user like you're seeing. – antik Oct 1 '13 at 12:43
1
 ClientContext Context = new ClientContext("http://localhost");
 NetworkCredential Cred = new NetworkCredential("username", "password", "Domain");
 Context .Credentials = Cred ;
 Web web = Context.Web;
 Context.Load(web, w => w.Created);
 Context.ExecuteQuery();
 Console.WriteLine ("The web created date is:"+ web.Created.ToString());
 Console.ReadLine();
1

Try setting the context.Credentials explicitly as below:

using (ClientContext context = new ClientContext("http://localhost"))
{
  NetworkCredential Cred = new NetworkCredential("username", "password", "domain");
        context.Credentials = Cred;

  Web web = context.Web;
  context.Load(web);

  Log.Debug("Loading web.");
  context.ExecuteQuery();

  Console.WriteLine(web.Title);
}
0

I faced similar issue in Windows server 2008 R2 whereas my application worked fine in other machines. I was using the below method,

NetworkCredential (String userName, String password)

to create credential object for the ClientContext. I simply used another overloaded constructor of NetworkCredential Class which is,

NetworkCredential(String userName, SecureString password, String domainName)

and get this issue solved.

0

After struggling with the same issue, I looked at the SharePoint Office PNP core samples, and tried to login using the default browser login, you can try the below sample I got working

string myAdfsSharePoint= "https://abc.myTenant.com/sites/abc"; OfficeDevPnP.Core.AuthenticationManager am = new OfficeDevPnP.Core.AuthenticationManager(); SP.ClientContext ctx = am.GetWebLoginClientContext(myAdfsSharePoint);

Also, make sure to have the default browser signed in, Since I had to prepare an Offline utility for my Client, I was allowed to ! I had to include this DLL from Github OfficeCorePnp Samples

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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