La solicitud HTTP no está autorizado con el esquema de autenticación de cliente 'negociar'.

Question

Estoy tratando de implementar / Paquete de un proyecto de Visual Studio basado en las extensiones de Visual Studio para Windows Sharepoint Services 1.3 (marzo de 2009 CTP) pero conseguir el siguiente error!

  

La solicitud HTTP no está autorizado con el esquema de autenticación de cliente   'Negociar'. El encabezado de autenticación recibido del servidor era   'Negociar, NTLM'

Soy acceder a la http://127.0.0.1:1378/SpService.svc a través del navegador; VSeWSS servicio se ejecuta en el grupo de aplicaciones de Administración central de SharePoint v3 cuya identidad es Servicio de red. Sharepoint Services se instala con la configuración predeterminada. Servicio de red es miembro del grupo de administradores locales.

La máquina es Windows 2003 Standard Editon SP2 y forma parte del dominio y yo soy iniciar la sesión con un usuario de dominio; mi usuario es miembro del grupo de administradores locales máquina' y yo instalado servicio de SharePoint con este inicio de sesión que me hizo miembro de la casi totalidad requerida Sharepoint grupos de seguridad (administrador de la comunidad Sitio Colección administrador etc)

He tratado stackoverflow y http://social.msdn.microsoft. com / foros / es-eS / sharepointdevelopment foro y han intentado casi todo lo sugerido en diferentes puestos en estos dos; pero nada de eso ha funcionado hasta ahora!

VSeWSS1.3.log tiene las siguientes entradas

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

Quité la máquina de dominio; desinstalado VSeWSS, Sharepoint y IIS. Vuelto a instalar el IIS después de retirar la máquina de dominio. Después de instalar Sharepoint y VSeWSS; las cosas comenzaron a trabajar muy bien!

Answer 2

También puede intentar utilizar el nombre de host real del equipo en lugar de la dirección de bucle invertido (127.0.0.1). Si utiliza localhost o la dirección de bucle de retorno, probablemente no será capaz de iniciar la sesión utilizando Kerberos, lo que causaría ciertos tipos de escenarios de delegación a fallar.

Lo que puede estar ocurriendo es que el navegador puede "caer hacia atrás" en silencio a utilizar NTLM, y otros programas, como el despliegue de VS no se comportan de esa manera - que a menudo sólo se utilizan Kerberos. Así que trate de usar el nombre de host en lugar de bucle invertido. Si eso no funciona, es probable que tenga un problema con Kerberos en su máquina. Si se siente realmente núcleo duro, se puede leer sobre Kerberos y descargar una copia de WireShark y luego buscar los mensajes de error de clase "KRB5" para ver exactamente lo que está fallando, pero esto es una inversión de tiempo bastante grande.