La richiesta HTTP non è autorizzato con lo schema di autenticazione client 'Negoziare'.

Question

Sto provando a schierare / Package Studio progetto Visual sulla base di Visual Studio Extensions per Windows SharePoint Services 1.3 (marzo 2009 CTP), ma ottenendo il seguente errore!

  

La richiesta HTTP non è autorizzato con schema di autenticazione del client   'Negoziare'. L'intestazione di autenticazione ricevuto dal server è stato   'Negotiate, NTLM'

Sono in grado di accedere a http://127.0.0.1:1378/SpService.svc attraverso il browser; il servizio è in esecuzione con VSeWSS Amministrazione centrale SharePoint v3 del pool di applicazioni la cui identità è Servizio di rete. Sharepoint Services è installato con le impostazioni predefinite. Servizio di rete è membro del gruppo di amministratori locali.

La macchina è Windows 2003 Standard Editon SP2 e fa parte del dominio e sono entrato con un utente di dominio; il mio utente è membro del gruppo Administrators locale macchina' e ho installato SharePoint Service con questo login che mi ha fatto parte della quasi tutti i dati obbligatori Sharepoint gruppi di protezione (amministratore fattoria; raccolta siti amministratore etc)

Ho provato StackOverflow e http://social.msdn.microsoft. com / Forum / it-IT / sharepointdevelopment forum e hanno provato quasi tutto suggerito in diversi messaggi su questi due; ma nessuna di queste ha funzionato finora!

VSeWSS1.3.log ha le seguenti voci

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

Ho rimosso la macchina dal dominio; disinstallato VSeWSS, SharePoint e IIS. Reinstallato l'IIS dopo aver rimosso la macchina dal dominio. Dopo l'installazione di SharePoint e VSeWSS; le cose hanno cominciato a lavorare bene!

Answer 2

Si potrebbe anche provare a utilizzare il nome host effettivo del computer invece che l'indirizzo di loopback (127.0.0.1). Se si utilizza localhost o l'indirizzo di loopback, probabilmente non sarà in grado di effettuare il login utilizzando Kerberos, che causerebbe alcuni tipi di scenari di delega a fallire.

Quello che potrebbe accadere è che il browser potrebbe essere "ricadere" in silenzio a utilizzare NTLM e altri programmi, quali la distribuzione di VS non si comportano in questo modo - spesso utilizzano solo Kerberos. Quindi provare a utilizzare il nome host invece di loopback. Se questo non dovesse funzionare, probabilmente avete un problema con Kerberos sulla vostra macchina. Se ti senti davvero hard-core, è possibile leggere su Kerberos e scaricare una copia di WireShark e poi cercare i messaggi di errore di classe "krb5" per vedere esattamente ciò che sta fallendo, ma questo è un abbastanza grande investimento di tempo.