web-dev-qa-db-fra.com

La requête HTTP n'est pas autorisée avec le schéma d'authentification client 'Ntlm'

Lors de l'appel d'un service Web, j'obtiens l'erreur suivante:

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 "NTLM". 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 "NTLM".

J'ai une application Silverlight 4 qui appelle un service Web WCF, à la fois sur mon IIS (7). Mon service Web WCF appelle un autre service Web ASMX, installé sur un autre serveur Web, à l'aide de NTLM ( Authentification Windows). Les deux serveurs, le mien et celui hébergeant le service Web ASMX sont dans le même domaine.

Lorsque le client Silverlight ouvre l'application à partir du serveur à l'aide de http://localhost/MySiteName tout fonctionne bien. Mais lorsque le client Silverlight ouvre l'application à partir d'un autre client, qui n'est pas le serveur mais toujours dans le même domaine, en utilisant http://MyServerName/MySiteName alors j'obtiens l'erreur.

L'authentification Windows est activée dans mon IIS. L'authentification anonyme est désactivée dans mon IIS.

La configuration de liaison pour appeler mon service Web WCF est la suivante:

    <binding name="winAuthBasicHttpBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>

La configuration de liaison pour appeler le service Web ASMX est la suivante:

    <binding name="ClNtlmBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Ntlm" />
      </security>
    </binding>
c#.netwindowssilverlightwcf
13
kruvi

OK, voici les choses qui me viennent à l'esprit:

  • Votre service WCF s'exécutant probablement sur IIS doit être exécuté dans le contexte de sécurité qui a le privilège qui appelle le service Web. Vous devez vous assurer dans le pool d'applications avec un utilisateur qui est un utilisateur de domaine - idéalement un utilisateur dédié.
  • Vous ne pouvez pas utiliser l'emprunt d'identité pour utiliser le jeton de sécurité de l'utilisateur pour le renvoyer à ASMX à l'aide de l'emprunt d'identité depuis my WCF web service calls another ASMX web service, installed on a **different** web server
  • Essayez de remplacer Ntlm par Windows et testez à nouveau.

OK, quelques mots sur l'emprunt d'identité. Fondamentalement, c'est un problème connu que vous ne pouvez pas utiliser les jetons d'emprunt d'identité que vous avez obtenus sur un serveur pour passer à un autre serveur. La raison semble être que le jeton est une sorte de hachage utilisant le mot de passe de l'utilisateur et valide pour la machine générée à partir de sorte qu'il ne peut pas être utilisé à partir du serveur intermédiaire.

MISE À JOUR

La délégation est possible sous WCF (c'est-à-dire le transfert de l'emprunt d'identité d'un serveur à un autre serveur). Regardez ce sujet ici .

18
Aliostad

Il y a longtemps que la question n'a pas été publiée, mais j'ai rencontré le même problème dans un scénario similaire. J'ai une application console et je consommais un service Web et notre serveur IIS où le service Web a été placé a l'authentification Windows (NTLM) activée.

J'ai suivi ce lien et cela a résolu mon problème. Voici l'exemple de code pour App.config:

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="Service1Soap">
                <security mode="TransportCredentialOnly">
                    <transport clientCredentialType="Ntlm" proxyCredentialType="None"
                        realm=""/>
                    <message clientCredentialType="UserName" algorithmSuite="Default"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://localhost/servicename/service1.asmx" 
            binding="basicHttpBinding" bindingConfiguration="ListsSoap"/>
    </client>
</system.serviceModel>
7
Yogesh Jindal

Pour moi, la solution consistait à utiliser "Ntlm" comme type d'informations d'identification, similaire à la solution de Jeroen K. Si j'avais le niveau d'autorisation, je le ferais plus sur son message, mais permettez-moi de publier tout mon code ici, qui prendra en charge Windows et d'autres types d'informations d'identification comme l'authentification de base:

    XxxSoapClient xxxClient = new XxxSoapClient();
    ApplyCredentials(userName, password, xxxClient.ClientCredentials);

    private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
    {
        clientCredentials.UserName.UserName = userName;
        clientCredentials.UserName.Password = password;
        clientCredentials.Windows.ClientCredential.UserName = userName;
        clientCredentials.Windows.ClientCredential.Password = password;
        clientCredentials.Windows.AllowNtlm = true;
        clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
    }
4
Sander Postma

J'ai dû déplacer le domaine, le nom d'utilisateur et le mot de passe de

client.ClientCredentials.UserName.UserName = domaine + "\\" + nom d'utilisateur; client.ClientCredentials.UserName.Password = mot de passe

à

client.ClientCredentials.Windows.ClientCredential.UserName = nom d'utilisateur; client.ClientCredentials.Windows.ClientCredential.Password = mot de passe; client.ClientCredentials.Windows.ClientCredential.Domain = domaine;

3
Jeroen K

1) J'ai dû faire ce qui suit avec ma configuration: (Ajouter BackConnectionHostNames ou Désactiver la vérification de boucle) http://support.Microsoft.com/kb/896861

2) Je travaillais sur un système de développement sur un réseau de développement isolé. Je l'avais fait fonctionner en utilisant le nom d'ordinateur du système de développement dans l'URL du service Web, mais quand j'ai modifié l'URL en l'URL qui serait utilisée dans la production (plutôt que le nom de l'ordinateur), j'ai commencé à obtenir l'erreur NTLM.

3) J'ai remarqué que le journal de sécurité montrait que le compte de service ne se connectait pas avec une erreur similaire à celle de l'article MSDN.

4) L'ajout de BackConnectionHostNames m'a permis de me connecter au serveur via un navigateur fonctionnant sur le serveur, mais le compte de service contenait toujours des erreurs NTLM lors de la tentative d'authentification pour les services Web. J'ai fini par désactiver la vérification de boucle et cela l'a corrigé pour moi.

0
WWC

Vous pouvez peut-être vous référer à: http://msdn.Microsoft.com/en-us/library/ms731364.aspx Ma solution consiste à changer 2 propriétés authenticationScheme et proxyAuthenticationScheme en "Ntlm", puis travaux.

PS: Mon environnement est le suivant - Côté serveur: .net 2.0 ASMX - Côté client: .net 4

0
Sega