I'm developing an external application which will integrate partially with Sharepoint, it will basically provide the ability to scan straight to Sharepoint. I've been using the WSS3 webservices (I don't have MOSS at all), and I've developed a lot of functionality already for dealing with Site, Folder & List data.

(Using Win Server 2003 R2)

I have no problems or errors when using any part of the SP site with an Internet Browser, purely through my application.

It will need to be able to browse specific folders, so I've been trying to find a way to authenticate the user, which has proven surprisingly hard using just WSS3 as it doesn't have anything as convenient as Authenticate.asmx.

The fact that I am developing a WinForms application and not a web-part seems to be hindering me also, as I cannot get context on the site through SPContext.Current.

I have no problems or errors when using any part of the SP site with an Internet Browser, they arise purely with this method in my application.

All I really need is for the program to be able to browse Sharepoint with Administrator/Full Access powers. Could someone point me in the right direction on how to go about achieving this?

I've tried this method but I always get a SoapSeverException thrown, unsure where I am going wrong.

            using (Lists service = new Lists())
                service.UseDefaultCredentials = true;
                //service.Credentials = new System.Net.NetworkCredential(username, password);

                var list = service.GetList("Second List");
                // http://localhost:1339/Lists/Second%20List/

                // var list = service.GetListItems("aafas", null, null, null, null, null, null);

System.Web.Services.Protocols.SoapException was caught   Message=Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.   Source=System.Web.Services   Actor=""   Lang=""   Node=""   Role=""   StackTrace:
       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at SharepointWeb.ShareLists.Lists.GetList(String listName) in C:\----\Web References\ShareLists\Reference.cs:line 213
       at SharepointWeb.webserviceFunctions.isFullAccessAccount(String username, String password) in C:\----\SharepointWeb\webserviceFunctions.cs:line 238   InnerException:


2012-06-22 10:10:39 W3SVC1934813465 POST /_vti_bin/Lists.asmx - 80 - Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3615) 401 2 2148074254 2012-06-22 10:10:39 W3SVC1934813465 POST /_vti_bin/Lists.asmx - 80 - Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3615) 401 1 0 2012-06-22 10:10:39 W3SVC1934813465 POST /_vti_bin/Lists.asmx - 80 MyDomain\MyUser Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3615) 500 0 0

IIS Error Codes 401.2 - Denied by Server Configuration Win32 status code 2148074254 "No credentials are available in the security package." In other words, the client has not sent any credentials."

As detailed Here Every websites has had it's NTAuthenticationProviders value changed to Negotiate,NTLM

I have logged onto the domain control and added the Sharepoint server as Trusted for Delegation. This was to make sure that Kerberos to could work!

Still getting the same error in my IIS log! :(

  • Change to NTLM only, not Negotiate,NTLM unless you want to use Kerberos and you can call setspn on the domain controller. also, adding the server for trust to delegation is not required and could open some security breaches.
    – Steve B
    Commented Jun 22, 2012 at 10:45
  • @SteveB I have the same issue with NTLM without Negotiate. I'm aware that trust to delegation can cause some security issues, I don't think we could require clients change it, but have been trying to rule out possibles!
    – Amicable
    Commented Jun 22, 2012 at 11:00

1 Answer 1


On your web service proxies object, you can set up credentials (assuming integrated authentication, from a user that have rights on the target site):

using(var listServiceProxy = new ListsWebService.Lists())
    listServiceProxy.UseDefaultCredentials = true;

using WCF client, there are a bunch of config you have to apply.

[EDIT]According your comments, I bet on a 401.2 error, or maybe a 401.1.

As I explained in another question, you have to peform some tweaks :

401.1 and 401.2 are classic errors with SP.

First, if you set up SP to use NTLM, either move to kerberos (which requires operation on the domain) or force the NTLM as the only authentication provider :

c:\inetpub\adminscripts\adsutils.vbs set w3svc\root\xxxxx\NTAuthenticationProvider NTLM

the process is described here.

If you are on IIS 7, you have to use appcmd command as described here

Then, in some case, a loopback check is done. This occurs when a webrequest is done from and to the same box with a custom host header. This can be either disabled, or white listed in the registry using the procedure described here. Please make the effort to white list your hostname instead of disabling the check as it can open a security breach in your SI.

[Edit] According the James comment, added the advice to whitelist the hostname instead of disabling the security check

  • I seem to always get a SoapServerException when I try this manner. I've edited my question, wondering if I'm calling on the wrong site or something like that.
    – Amicable
    Commented Jun 21, 2012 at 10:20
  • What are the details of the exception?
    – Steve B
    Commented Jun 21, 2012 at 10:25
  • 1
    look into the server's IIS log file. Track the call to lists.asmx and hopely find the http status and substatus (401.1 for example).
    – Steve B
    Commented Jun 21, 2012 at 10:38
  • 1
    The substatus is very important. 401.1, 401.2, etc. are all possible value with different causes and resolutions.
    – Steve B
    Commented Jun 21, 2012 at 11:01
  • 1
    Glad you solved your problem. Microsoft have made improvement related to this point. Especially, the windows authentication provider can be set from the central admin now :)
    – Steve B
    Commented Jun 25, 2012 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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