La requête HTTP est non autorisé avec le schéma d'authentification client « Negotiate ».

Question

Je suis en train de déployer / Package Visual Studio un projet basé sur Visual Studio Extensions pour Windows Sharepoint Services 1.3 (mars 2009 CTP) mais obtenir l'erreur suivante!

  

La requête HTTP est non autorisé avec le schéma d'authentification du client   'Négocier'. L'en-tête d'authentification reçue du serveur était   'Negotiate, NTLM'

Je suis en mesure d'accéder à http://127.0.0.1:1378/SpService.svc par le navigateur; le service VSeWSS est en cours d'exécution sous le pool d'applications Sharepoint Administration centrale dont l'identité est service réseau. Sharepoint Services est installé avec les paramètres par défaut. Network Service est membre du groupe Administrateurs local.

La machine est Windows 2003 Standard Editon SP2 et fait partie du domaine et je suis connecté avec un utilisateur de domaine; mon utilisateur est membre du groupe Administrateurs local « machine et j'installé le Service Sharepoint avec ce login qui m'a fait membre de presque tous les groupes de sécurité requis Sharepoint (Ferme administrateur, Collection Administrateur etc)

Je l'ai essayé et stackoverflow http://social.msdn.microsoft. com / Forums / en-US / sharepointdevelopment forum et ont essayé presque tout proposé dans différents postes sur ces deux; mais rien de tout cela a fonctionné jusqu'à présent!

VSeWSS1.3.log a les entrées suivantes

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

I enlevé l'appareil de domaine; VSeWSS désinstallés, Sharepoint et IIS. Réinstallées IIS après avoir retiré la machine de domaine. Après avoir installé Sharepoint et VSeWSS; les choses ont commencé à travailler très bien!

Answer 2

Vous pouvez également essayer d'utiliser le nom d'hôte réel de l'ordinateur au lieu de l'adresse de réalimentation (de 127.0.0.1). Si vous utilisez localhost ou l'adresse de réalimentation, vous ne serez probablement pas capable de se connecter en utilisant Kerberos, qui provoquerait certains types de scénarios de délégation à l'échec.

Ce qui peut se produire est que votre navigateur peut être « retombait » silencieusement à l'aide de NTLM, et d'autres programmes, tels que le déploiement de VS ne se comportent pas de cette façon - ils utilisent souvent Kerberos. Donc, essayez d'utiliser le nom d'hôte au lieu de réalimentation. Si cela ne fonctionne pas, vous avez probablement un problème avec Kerberos sur votre machine. Si vous vous sentez vraiment noyau dur, vous pouvez lire sur Kerberos et télécharger une copie de Wireshark puis recherchez les messages d'erreur de classe « krb5 » pour voir exactement ce qui est un échec, mais c'est un investissement de temps assez grande.