Die HTTP-Anforderung ist nicht autorisierte mit Client-Authentifizierungsschema ‚Verhandeln‘.

Question

Ich versuche, zu Verteilen / Paket eines Visual Studio-Projekt auf Basis von Visual Studio-Erweiterungen für Windows Sharepoint Services 1.3 (März 2009 CTP), aber die folgenden Störung zu erhalten!

  

Die HTTP-Anforderung ist mit Client-Authentifizierungsschema nicht autorisierte   'Verhandeln'. Der Authentifizierungs-Header von dem Server empfangen wurde   'Verhandeln, NTLM'

Ich bin in der Lage, den Zugang http://127.0.0.1:1378/SpService.svc durch Browser; VSeWSS Dienst läuft unter Sharepoint Central Administration v3 Anwendungspool, deren Identität Netzwerkdienst. Sharepoint Services wird mit den Standardeinstellungen installiert. Network Service ist Mitglied der lokalen Administratorgruppe an.

Die Maschine ist Windows-2003 Standard Editon SP2 und einen Teil der Domäne ist, und ich bin auf mit einem Domain-Benutzer angemeldet; mein Benutzer ist Mitglied der Maschine Gruppe lokaler Administratoren und ich installierte Sharepoint-Dienst mit dieser Anmeldung, die mir Mitglied fast alle gemacht erforderlich Sharepoint Security Groups (Farm Administrator, Site Collection Administrator usw.)

Ich habe versucht, und http://social.msdn.microsoft. com / Foren / en-US / sharepointdevelopment Forum und haben in verschiedenen Posten auf diese beiden vorgeschlagen fast alles versucht; aber nichts davon hat funktioniert so weit!

VSeWSS1.3.log hat die folgenden Einträge

2010/02/12 16:49:01    Error
Error: System.ServiceModel.Security.MessageSecurityException
System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   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()

Answer 1

entfernte ich die Maschine aus der Domäne; uninstalled VSeWSS, Sharepoint und IIS. Neu installierte die IIS nach der Maschine aus der Domäne zu entfernen. Nach der Installation von Sharepoint und VSeWSS; Dinge zu arbeiten begann gut!

Answer 2

Sie können auch versuchen, den tatsächlichen Hostnamen des Computers verwenden, anstatt die Loopback-Adresse (127.0.0.1). Wenn Sie localhost oder die Loopback-Adresse verwenden, wird nicht Sie wahrscheinlich in der Lage sein, mit Kerberos anmelden, die bestimmten Arten von Delegierungsszenarien verursachen würde zum Scheitern verurteilt.

Was kann passieren, dass das Browser „zurückzufallen“ leise Bereitstellung unter Verwendung von NTLM und andere Programme, wie zum Beispiel VS werden verhalten sich nicht so - sie oft nur Kerberos verwenden. So versuchen, den Host-Namen anstelle von Loopback verwenden. Wenn das nicht funktioniert, haben Sie wahrscheinlich ein Problem mit Kerberos auf Ihrem Rechner. Wenn Sie wirklich harten Kern fühlen, können Sie sich über Kerberos lesen und eine Kopie von Wireshark herunterladen und dann suchen die „KRB5“ Klassenfehlermeldungen genau zu sehen, was ausfällt, aber das ist eine ziemlich große Zeitinvestition.