La requête HTTP N'est pas autorisée avec le client authentication scheme 'Ntlm'. L'en-tête d'authentification reçu du serveur était 'Negotiate, NTLM'

essayez de configurer ' clientCredentialType 'en' Windows 'au lieu de'Ntlm'.

je pense que c'est ce que le serveur attend - i.e. quand il dit que le serveur attend "Negotiate,NTLM", cela signifie en fait Windows Auth, où il va essayer D'utiliser Kerberos si disponible, ou retomber sur NTLM si non (d'où le 'negotiate')

je me base sur une certaine lecture entre les lignes de: sélectionner un type de justificatif d'identité

nous avons rencontré ce problème et avons découvert que l'erreur était lancée en utilisant (C'est-à-dire dans notre cas) le navigateur s'est connecté en tant que compte de processus, puis en changeant la session se connecter à travers l'application (SharePoint). Je crois que ce scénario passe deux schémas d'authentification:

1. Négocier
2. NTLM

l'application hébergeait un *.asmx web service, qui était appelé sur un serveur de charge équilibrée, l'amorce d'un appel de service web à elle-même en utilisant un WCF-like .NET3.5 binding.

Code qui a été utilisé pour appeler le service web:

public class WebServiceClient<T> : IDisposable
{
    private readonly T _channel;
    private readonly IClientChannel _clientChannel;

    public WebServiceClient(string url)
        : this(url, null)
    {
    }
    /// <summary>
    /// Use action to change some of the connection properties before creating the channel
    /// </summary>
    public WebServiceClient(string url,
         Action<CustomBinding, HttpTransportBindingElement, EndpointAddress, ChannelFactory> init)
    {
        var binding = new CustomBinding();
        binding.Elements.Add(
            new TextMessageEncodingBindingElement(MessageVersion.Soap12, Encoding.UTF8));
        var transport = url.StartsWith("https", StringComparison.InvariantCultureIgnoreCase)
                            ? new HttpsTransportBindingElement()
                            : new HttpTransportBindingElement();
        transport.AuthenticationScheme = System.Net.AuthenticationSchemes.Ntlm;
        binding.Elements.Add(transport);

        var address = new EndpointAddress(url);

        var factory = new ChannelFactory<T>(binding, address);
        factory.Credentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;

        if (init != null)
        {
            init(binding, transport, address, factory);
        }

        this._clientChannel = (IClientChannel)factory.CreateChannel();
        this._channel = (T)this._clientChannel;
    }

    /// <summary>
    /// Use this property to call service methods
    /// </summary>
    public T Channel
    {
        get { return this._channel; }
    }
    /// <summary>
    /// Use this porperty when working with
    /// Session or Cookies
    /// </summary>
    public IClientChannel ClientChannel
    {
        get { return this._clientChannel; }
    }

    public void Dispose()
    {
        this._clientChannel.Dispose();
    }
}

nous avons découvert que si le justificatif de session était le même que le compte de processus du navigateur, alors juste NTLM a été utilisé et l'appel a été réussi. Sinon, il en résulterait cette exception capturée:

la requête HTTP N'est pas autorisée avec le client authentication scheme 'Ntlm'. L'en-tête d'authentification reçu du serveur a été "Negotiate, NTLM".

en fin de compte, je suis assez certain que l'un des schémas d'authentification passerait l'authentification tandis que l'autre ne le ferait pas, parce qu'il n'a pas été accordé l'accès approprié.