In trying to drive a process from a SharePoint list, I ran across a problem…
I couldn’t create a web reference in my C# project due to some really weird problem… In the “Add web reference” wizard, I entered my URL, and was surprised by a pop-up titled “Discovery Credential”, asking me for credentials for the site.
Since I was on the local domain and had “owner” permissions to the site, I thought I would just waltz in and get the WSDL.
Ok, so it wants creds… I gave it my own.
After a few attempts and access denied errors, I hit Cancel, and was rewarded by, of all things, the WSDL display… but I still couldn’t add the reference.
After quite a bit of wrestling, it turns out there was an authentication provider configuration problem. The site was configured to use Kerberos authentication, but the active directory configuration was not set up correctly. (I believe it needed someone to use SetSPN to update the Service Principal Name (SPN) for the service.)
One way to resolve the problem was to set the authentication provider to NTLM, but in my case, I didn’t have, (and wasn’t likely to get) that configuration changed in the site (a SharePoint Web Application) I really needed access to.
In order to make it work, I had to initially create my reference to a similar, accessible site.
Then, I had to initialize the service as such, in code:
private void InitWebService()
SmokeTestSite.Lists workingLists = new SmokeTest.SmokeTestSite.Lists();
workingLists.Url = "http://host/sites/mybrokensite/_vti_bin/lists.asmx";
workingLists.UseDefaultCredentials = true;
workingLists.Proxy = null;
lists = workingLists;
What this accomplishes is it unregisters all authentication managers in your application domain. (This can only be done once in the same app domain. Attempts to unregister the same manager more than once while the program’s running will throw an exception.)
So by having all the other authentication managers disabled in the client, the server would negotiate and agree on Ntlm authentication, which succeeds.