web-dev-qa-db-fra.com

La requête HTTP n'est pas autorisée avec le schéma d'authentification client 'Ntlm'. L'en-tête d'authentification reçu du serveur était «Négocier, NTLM»

J'ai parcouru une tonne d'articles SO, et même d'autres sites, mais je n'arrive pas à faire fonctionner ce service. J'ai un service SOAP J'essaye de frapper et c'est configuré comme ceci:

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
        <binding name="PROVIDERSSoapBinding">
            <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
            </security>
        </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://xxx.xx.xx.xxx:9011/provider/services/PROVIDERS"
            binding="basicHttpBinding" bindingConfiguration="PROVIDERSSoapBinding"
            contract="ServiceReference1.ProviderRemote" name="PROVIDERS" />
    </client>
</system.serviceModel>

Cependant, j'obtiens l'erreur suivante lorsque je la frappe depuis mon application console:

La requête HTTP n'est pas autorisée avec le schéma d'authentification client 'Ntlm'. L'en-tête d'authentification reçu du serveur était "Négocier, NTLM".

Quelqu'un peut-il m'aider?

c#.netwcfsoap
19
Mike Perrenoud

Vous pouvez éliminer le client du problème en utilisant wftech , il s'agit d'un ancien outil mais je l'ai trouvé utile pour diagnostiquer les problèmes d'authentification. wfetch vous permet de spécifier NTLM, Negotiate et kerberos, cela pourrait bien vous aider à mieux comprendre votre problème. Comme vous essayez d'appeler un service et que wfetch ne sait rien de WCF, je suggère d'appliquer votre liaison de point de terminaison (PROVIDERSSoapBinding) au serviceMetadata alors vous pouvez faire une HTTP GET du WSDL pour le service avec le mêmes paramètres de sécurité.

Une autre option, qui peut être disponible pour vous, est de forcer le serveur à utiliser NTLM, vous pouvez le faire en modifiant la métabase (IIS 6) et en supprimant le paramètre Negotiate, plus de détails sur http: // support. Microsoft.com/kb/21538 .

Si vous utilisez IIS 7.x alors l'approche est légèrement différente, les détails sur la façon de configurer les fournisseurs d'authentification sont ici http://www.iis.net/configreference/ system.webserver/security/authentication/windowsauthentication .

Je remarque que vous avez bloqué l'adresse du serveur avec xxx.xx.xx.xxx, donc je suppose qu'il s'agit d'une adresse IP plutôt que d'un nom de serveur, cela peut entraîner des problèmes d'authentification, donc si possible, essayez de cibler la machine prénom.

Désolé de ne pas vous avoir donné la réponse, mais plutôt des conseils pour vous rapprocher du problème, mais j'espère que cela vous aidera.

Je terminerai en disant que j'ai rencontré ce même problème et mon seul recours était d'utiliser Kerberos plutôt que NTLM, n'oubliez pas que vous devrez enregistrer un SPN pour le service si vous suivez cette voie.

8
David Martin

Essayez de définir "clientCredentialType" sur "Windows" au lieu de "Ntlm".

Je pense que c'est ce que le serveur attend - c'est-à-dire quand il dit que le serveur attend "Négocier, NTLM", cela signifie en fait Windows Auth, où il essaiera d'utiliser Kerberos si disponible, ou retombera sur NTLM sinon (d'où le 'négocier')

Je fonde cela sur une lecture un peu entre les lignes de: Sélection d'un type d'informations d'identification

10
Chamila Chulatunga

Nous avons rencontré ce problème et découvert que l'erreur était levée lors de l'utilisation (IE dans notre cas) du navigateur connecté en tant que compte de processus, puis en modifiant le journal de session via 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 service Web * .asmx, qui était appelé sur un serveur à charge équilibrée, initiant un appel de service Web à lui-même à l'aide d'une liaison .NET3.5 de type WCF.

Code 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 les informations d'identification de session étaient les mêmes que celles du compte de processus du navigateur, alors seulement NTLM a été utilisé et l'appel a réussi. Sinon, cela entraînerait cette exception capturée:

La requête HTTP n'est pas autorisée avec le schéma d'authentification client 'Ntlm'. L'en-tête d'authentification reçu du serveur était "Négocier, 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, car il n'a pas été accordé un accès approprié.

4
ISZ

Si à la fois votre client et service est installé sur la même machine , et que vous rencontrez ce problème avec le correct ( lire: essayé et testé ailleurs) configurations client et service , alors cela pourrait valoir la peine d'être vérifié.

Vérifiez les entrées d'hôte dans votre fichier hôte

% windir%/system32/drivers/etc/hosts

Vérifiez si vous accédez à votre service Web avec un nom d'hôte et que ce même nom d'hôte a été associé à une adresse IP dans le fichier hosts mentionné ci-dessus. Si oui, les informations d'identification NTLM/Windows ne seront PAS transmises du client au service car toute demande pour ce nom d'hôte sera à nouveau acheminée au niveau de la machine.

Essayez l'une des solutions suivantes

  • Supprimez l'entrée Host de ce nom d'hôte du fichier hosts
    • OU
  • S'il n'est pas possible de supprimer l'entrée d'hôte, essayez d'accéder à votre service avec un autre nom d'hôte. Vous pouvez également essayer avec l'adresse IP au lieu du nom d'hôte

Edit: D'une manière ou d'une autre, la situation ci-dessus est pertinente dans un scénario à charge équilibrée. Cependant, si la suppression des entrées d'hôte n'est pas possible, la désactivation de la vérification de boucle sur la machine aidera. Reportez-vous à la méthode 2 de l'article https://support.Microsoft.com/en-us/kb/896861

3
ash

Vous devez définir les NTAuthenticationProviders sur NTLM

Article MSDN: https://msdn.Microsoft.com/en-us/library/ee248703 (VS.90) .aspx

Ligne de commande IIS ( http://msdn.Microsoft.com/en-us/library/ms525006 (v = vs.90) .aspx ):

 cscript adsutil.vbs set w3svc/WebSiteValueData/root/NTAuthenticationProviders "NTLM"
2
mistrykam

Je sais que cette question est ancienne, mais la solution à ma demande était différente des réponses déjà suggérées. Si quelqu'un comme moi a toujours ce problème et qu'aucune des réponses ci-dessus ne fonctionne, cela pourrait être le problème:

J'ai utilisé un objet Network Credentials pour analyser un nom d'utilisateur Windows + mot de passe à un tiers SOAP webservice. J'avais défini le nom d'utilisateur = "nom_domaine\nom d'utilisateur", mot de passe = "mot de passe" et domaine = " nom de domaine ". Ce jeu me présente cette étrange erreur Ntlm et non NTLM. Pour résoudre les problèmes, assurez-vous de ne pas utiliser le paramètre de domaine sur l'objet NetworkCredentials si le nom de domaine est inclus dans le nom d'utilisateur avec la barre oblique inverse. Supprimez donc le nom de domaine à partir du nom d'utilisateur et analyser dans le paramètre de domaine, ou laisser de côté le paramètre de domaine. Cela a résolu mon problème.

1
nivs1978