ansaurus

Question

VseWss - The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'

Answer 1

+1 A:

You also might try using the computer's actual hostname instead of the loopback address (127.0.0.1). If you use localhost or the loopback address, you probably won't be able to login using Kerberos, which would cause certain types of delegation scenarios to fail.

What may be happening is that your browser may be "falling back" silently to using NTLM, and other programs, such as VS's deployment don't behave that way -- they often only use Kerberos. So try using the hostname instead of loopback. If that doesn't work, you probably have an issue with Kerberos on your machine. If you are feeling really hard-core, you can read up on Kerberos and download a copy of WireShark and then look for the "KRB5" class error messages to see exactly what is failing, but this is a pretty large time investment.

Dave Markle 2010-02-12 10:57:18

http://machine:1378/SpService.svc and http://machine.mydomain:1378/SpService.svc, both opening fine in the browser; the stated error comes only in Visual Studio when I try to Deploy or Package my project!

Khurram Aziz 2010-02-12 10:59:17

edited (see post).

Dave Markle 2010-02-12 11:36:13

Answer 2

A:

Thanks Dave for the details and trying to nail the problem down....In WireShark I am getting the following

Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2010-02-12 12:24:43 (UTC)
susec: 881956
error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)
Realm: MyDomain
Server Name (Service and Instance): host/127.0.0.1
- Name-type: Service and Instance (2)
- Name: host
- Name: 127.0.0.1

Khurram Aziz 2010-02-12 12:35:34

Right. This is because you are using 127.0.0.1. Stop doing that! Use your machine name instead. There is no service principal defined on your domain for the loopback address.

Dave Markle 2010-02-12 20:49:57

Answer 3

A:

I have a fellow developer who has similar setup and his Visual Studio is packaging / deploying fine; we both have local Sharepoint Service installed where we are developing our modules independently! I am the second to setup the dev environment. Is this because KDC has issued him the host/127.0.0.1 ticket and to me its rejecting? With this in mind; I searched Windows registry for http://127.0.0.1:1378/SpService.svc and have replaced it to http://MyMachine:1378/SpService.svc (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\VSeWSSServiceURL). In IIS > VseWss web site; have changed site ip from 127.0.0.1 to All Unassigned. http://MyMachine:1378/SpService.svc is opening fine in browser (IE and Chrome); but as this service is not exposing the meta data so couldnt check it through WCFTestClient.

After IISRESET and restarting Visual Studio; I am now getting "The HTTP request was forbidden with client authentication scheme 'Negotiate'; however there is no KDC error now atleast...

VseWSS1.3.log has the following entry

2010/02/12 18:10:15    Error
Error: System.ServiceModel.Security.MessageSecurityException
System.ServiceModel.Security.MessageSecurityException: The HTTP request was forbidden with client authentication scheme 'Negotiate'. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---
Server stack trace: 
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateAuthentication(HttpWebRequest request, HttpWebResponse response, WebException responseException, HttpChannelFactory factory)
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.SharePoint.Tools.SPServiceReference.ISPService.GetWeb(String url)
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionDeployer.ValidateProjectDeployURL()
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionDeployer.Deploy()

Khurram Aziz 2010-02-12 13:36:48

Answer 4

A:

I removed the machine from domain; uninstalled VSeWSS, Sharepoint and IIS. Reinstalled the IIS after removing the machine from domain. After installing Sharepoint and VSeWSS; things started working fine!

Khurram Aziz 2010-02-17 08:45:02

ansaurus

tags:

views:

answers:

VseWss - The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'

related questions