Sharepoint Web Services. The HTTP request is not authorized using the ntlm client authentication scheme. The authentication header received from the server was "NTLM",

Question

I know that many questions about SO are similar to this, but I could not find it for this particular problem.

A few points, firstly:

• We have no control on our Sharepoint server. I cannot configure any IIS settings.
• I believe our version of the IIS server is IIS 7.0.
• Our Sharepoint server listens for requests through NTLM.
• Our Sharepoint server is in the same domain as my client computer.
• I am using .NET Framework 3.5, Visual Studio 2008

I am trying to write a simple console application for managing Sharepoint data using SharePoint web services. I added a link to the service, and the following is my app.config:

<system.serviceModel> <bindings> <basicHttpBinding> <binding name="ListsSoap" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="Transport"> <transport clientCredentialType="Ntlm" proxyCredentialType="Ntlm" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="https://subdomain.companysite.com/subsite/_vti_bin/Lists.asmx" binding="basicHttpBinding" bindingConfiguration="ListsSoap" contract="ServiceReference1.ListsSoap" name="ListsSoap" /> </client> </system.serviceModel> 

This is my code:

 static void Main(string[] args) { using (var client = new ListsSoapClient()) { client.ClientCredentials.Windows.ClientCredential = new NetworkCredential("username", "password", "domain"); client.GetListCollection(); } } 

When I call GetListCollection (), the following MessageSecurityException is thrown :

 The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'. 

With an internal WebException:

 "The remote server returned an error: (401) Unauthorized." 

I tried various bindings and various code settings to try to authenticate properly, but to no avail. I will list below.

---

I tried the following steps:

Using your own Win32 Impersonator before creating a client

 using (new Impersonator.Impersonator("username", "password", "domain")) using (var client = new ListsSoapClient()) { client.ClientCredentials.Windows.ClientCredential = new NetworkCredential("dpincas", "password", "domain"); client.GetListCollection(); } 

This caused the same error message.

---

Configure TokenImpersonationLevel for my client credentials

 using (var client = new ListsSoapClient()) { client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation; client.GetListCollection(); } 

This caused the same error message.

---

Using Security Mode = TransportCredentialOnly

 <security mode="TransportCredentialOnly"> <transport clientCredentialType="Ntlm" /> </security> 

As a result, another error message appeared:

 The provided URI scheme 'https' is invalid; expected 'http'. Parameter name: via 

However, I need to use https, so I cannot change the URI scheme.

---

I tried some other combinations that I don’t remember, but I will publish them when I will. I really am here. I see a lot of google links saying "switch to Kerberos", but my server seems to accept NTLM, not "Negotiate" (as it would be said if it searches for Kerberos), so unfortunately this is not an option .

Any help there people?

Answer 1

After a lot of trial and error, followed by a stagnant period, while I was waiting for the opportunity to talk with our server guys, I finally had the opportunity to discuss the problem with them and asked them if they would mind switching our Sharepoint authentication for Kerberos.

To my surprise, they said that this was not a problem, and in fact it was easy to do. They activated Kerberos , and I changed my app.config as follows:

 <security mode="Transport"> <transport clientCredentialType="Windows" /> </security> 

For reference, my full serviceModel entry in my app.config looks like this:

 <system.serviceModel> <bindings> <basicHttpBinding> <binding name="TestServerReference" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="2000000" maxBufferPoolSize="2000000" maxReceivedMessageSize="2000000" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="Transport"> <transport clientCredentialType="Windows" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="https://path/to/site/_vti_bin/Lists.asmx" binding="basicHttpBinding" bindingConfiguration="TestServerReference" contract="TestServerReference.ListsSoap" name="TestServerReference" /> </client> </system.serviceModel> 

After that, everything worked like a charm. Now I can (finally!) Use Sharepoint Web Services. So, if someone else cannot get their Sharepoint web services to work with NTLM, see if you can convince system administrators to switch to Kerberos.

Answer 2

Visual studio 2005

• Create a new console application project in Visual Studio
• Add the web link to the Lists.asmx web service.
  • Your url will probably look like this: http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx
  • I named my web link: ListsWebService
• Write the code in program.cs (I have a list of problems here)

Here is the code.

 using System; using System.Collections.Generic; using System.Text; using System.Xml; namespace WebServicesConsoleApp { class Program { static void Main(string[] args) { try { ListsWebService.Lists listsWebSvc = new WebServicesConsoleApp.ListsWebService.Lists(); listsWebSvc.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials; listsWebSvc.Url = "http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx"; XmlNode node = listsWebSvc.GetList("Issues"); } catch (Exception ex) { Console.WriteLine(ex.ToString()); } } } } 

---

Visual studio 2008

• Create a new console application project in Visual Studio
• Right-click the link and add the service link
• Put the URL in the List.asmx service on your server
  • Example: http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx
• Click Go
• Click OK
• Make the following code changes:

Change the app.config file to:

 <security mode="None"> <transport clientCredentialType="None" proxyCredentialType="None" realm="" /> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> 

To:

 <security mode="TransportCredentialOnly"> <transport clientCredentialType="Ntlm"/> </security> 

Modify the program.cs file and add the following code to your main function:

 ListsSoapClient client = new ListsSoapClient(); client.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials; client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation; XmlElement listCollection = client.GetListCollection(); 

Add using statements:

 using [your app name].ServiceReference1; using System.Xml; 

Link: http://sharepointmagazine.net/technical/development/writing-caml-queries-for-retrieving-list-items-from-a-sharepoint-list

Answer 3

After many answers that did not work, I finally found a solution when anonymous access is disabled on the IIS server. Our server uses Windows authentication, not Kerberos. This is thanks to this blog post .

There were no changes to web.config.

On the server side, the .SVC file in the ISAPI folder uses MultipleBaseAddressBasicHttpBindingServiceHostFactory

Service class attributes are:

 [BasicHttpBindingServiceMetadataExchangeEndpointAttribute] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] public class InvoiceServices : IInvoiceServices { ... } 

On the client side, the key that earned was the http binding security attribute:

 EndpointAddress endpoint = new EndpointAddress(new Uri("http://SharePointserver/_vti_bin/InvoiceServices.svc")); BasicHttpBinding httpBinding = new BasicHttpBinding(); httpBinding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; httpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Ntlm; InvoiceServicesClient myClient = new InvoiceServicesClient(httpBinding, endpoint); myClient.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation; (call service) 

Hope this works for you!

Answer 4

If I remember correctly, there are some problems with adding SharePoint Web Services as a link to VS2K8 Support Services. You need to add it as an “old style Web Reference” for it to work properly.

Answer 5

I have the same setup as yours and it works fine for me. I think that maybe the problem lies somewhere in your moss configuration or on your network.

You said that moss is in the same domain as your application. If you have access to the site with your user (who is registered on your computer) ... you tried:

 client.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials; 

Answer 6

I had exactly the same problem last week - WCF behaves strangely on one server - why?

For me, the solution was quite simple. Sharepoint has its own set of permissions. My client tried to log in as a user who was not explicitly granted access to the web service through the SharePoint control panel.

I added the user to the Sharepoint and bang whitelist - it just worked.

Even if this is not a problem, please note that

The HTTP request was not authorized using the ntlm client authentication scheme. The authentication header received from the server was NTLM.

It means (in English) that you simply do not have permission. Your protocol is probably right - your user simply has no rights.

Answer 7

I would try to connect to your Sharepoint site using this tool here . If this works, you can be sure that the problem is in your code / configuration. This may not solve your problem right away, but it eliminates that something is wrong with the server. Assuming it doesn't work, I would investigate the following:

• Does your user really have sufficient rights on the site?
• Is there a proxy server that is interfering? (Your configuration is a bit like a proxy. Can you bypass it?)

I think there is nothing wrong with using the Transport security mode, but I'm not sure about proxyCredentialType="Ntlm" , maybe this should be set to None.

Answer 8

I had this problem before.

 client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation; 

do this against your wcf proxy before making the call.

Answer 9

try it

 <client> <endpoint> <identity> <servicePrincipalName value="" /> </identity> </endpoint> </client> 

I encountered this error before when I was working in webfarm and this fixed it for me.

Answer 10

This problem was even stranger to us. Everything works if you previously visited the sharepoint site from a browser before you made a SOAP call. However, if you made the SOAP call first, we would throw the above error.

We were able to solve this problem by installing the sharepoint certificate on the client and adding the domain to the local intranet sites.