# HTTP 401, Unauthorized using the Managed Client Object Model

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"))
{

Web web = context.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
-

try to use the CredentialCache (from memory) :

using (ClientContext context = new ClientContext("http://localhost"))
{
CredentialCache cc = new CredentialCache();

context.Credentials = cc;

Web web = context.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.

 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

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.ExecuteQuery();

Console.WriteLine(web.Title);
}

-
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
 ClientContext Context = new ClientContext("http://localhost");
Context .Credentials = Cred ;
Web web = Context.Web;
Context.ExecuteQuery();
Console.WriteLine ("The web created date is:"+ web.Created.ToString());

-

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;

CredentialCache cc = new CredentialCache();
_clientContext.Credentials = cc;
_clientContext.AuthenticationMode = ClientAuthenticationMode.Default;

_clientContext.ExecuteQuery();
ListCollection _listCollection = _web.Lists;

-

Try setting the context.Credentials explicitly as below:

using (ClientContext context = new ClientContext("http://localhost"))
{