Partager via

Échec d’authentification à partir de serveurs Non-Windows NTLM ou Kerberos

  • Article

Cet article fournit une solution à plusieurs problèmes d’échec d’authentification dans lesquels les serveurs NTLM et Kerberos ne peuvent pas authentifier les ordinateurs Windows 7 et Windows Server 2008 R2. Cela est dû à des différences dans la façon dont les jetons de liaison de canal sont gérés.

Numéro de la base de connaissances d’origine : 976918

Symptômes

Windows 7 et Windows Server 2008 R2 prennent en charge la protection étendue pour l’authentification intégrée, qui inclut la prise en charge du jeton de liaison de canal (CBT) par défaut.

Vous pouvez rencontrer un ou plusieurs des symptômes suivants :

  • Les clients Windows qui prennent en charge la liaison de canal ne peuvent pas être authentifiés par un serveur Kerberos non Windows.
  • Échecs d’authentification NTLM à partir de serveurs proxy.
  • Échecs d’authentification NTLM provenant de serveurs non Windows NTLM.
  • Échecs d’authentification NTLM lorsqu’il existe une différence de temps entre le client et le contrôleur de domaine ou le serveur de groupe de travail.

Cause

Windows 7 et Windows Server 2008 R2 prennent en charge la protection étendue pour l’authentification intégrée. Cette fonctionnalité améliore la protection et la gestion des informations d’identification lors de l’authentification des connexions réseau à l’aide de l’authentification Windows intégrée (IWA).

Il s’agit d’ON par défaut. Lorsqu’un client tente de se connecter à un serveur, la demande d’authentification est liée au nom du principal du service (SPN) utilisé. De même, lorsque l’authentification a lieu à l’intérieur d’un canal TLS (Transport Layer Security), elle peut être liée à ce canal. NTLM et Kerberos fournissent des informations supplémentaires dans leurs messages pour prendre en charge cette fonctionnalité.

En outre, les ordinateurs Windows 7 et Windows 2008 R2 désactivent LMv2.

Résolution

Pour les échecs où des serveurs Non-Windows NTLM ou Kerberos échouent lors de la réception de cbt, vérifiez auprès du fournisseur une version qui gère correctement cbT.

Pour les échecs où des serveurs non Windows NTLM ou des serveurs proxy nécessitent LMv2, vérifiez auprès du fournisseur une version qui prend en charge NTLMv2.

Solution de contournement

Importante

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier. Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du Registre, consultez Comment sauvegarder et restaurer le Registre dans Windows .

Pour contrôler le comportement de protection étendue, créez la sous-clé de Registre suivante :

  • Nom de la clé : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
  • Nom de la valeur : SuppressExtendedProtection
  • Type : DWORD

Pour les clients Windows qui prennent en charge la liaison de canal qui ne parviennent pas à être authentifiés par des serveurs Kerberos non Windows qui ne gèrent pas correctement la cbt :

  1. Définissez la valeur d’entrée de Registre sur 0x01. Cela permet de configurer Kerberos pour qu’il n’émette pas de jetons CBT pour les applications non corrigées.
  2. Si cela ne résout pas le problème, définissez la valeur d’entrée de Registre sur 0x03. Cela permet de configurer Kerberos pour ne jamais émettre de jetons CBT.

Remarque

Il existe un problème connu avec Sun Java qui a été résolu pour prendre en charge l’option selon laquelle l’accepteur peut ignorer toutes les liaisons de canal fournies par l’initiateur, ce qui retourne la réussite même si l’initiateur a passé des liaisons de canal conformément à la norme RFC 4121. Pour plus d’informations, consultez Ignorer la liaison de canal entrant si l’accepteur n’en définit pas.

Nous vous recommandons d’installer la mise à jour suivante à partir du site Sun Java et de réactiver la protection étendue : Modifications apportées à la version 1.6.0_19 (6u19).

Pour les clients Windows qui prennent en charge la liaison de canal qui ne parviennent pas à être authentifiés par des serveurs non Windows NTLM qui ne gèrent pas correctement la cbt, définissez la valeur d’entrée de Registre sur 0x01. Cela permet de configurer NTLM pour qu’il n’émette pas de jetons CBT pour les applications non corrigées.

Pour les serveurs non Windows NTLM ou les serveurs proxy qui nécessitent LMv2, définissez sur la valeur d’entrée de Registre 0x01. Cette opération configure NTLM pour fournir des réponses LMv2.

Pour le scénario dans lequel la différence de temps est trop grande :

  1. Corrigez l’horloge du client pour refléter l’heure sur le contrôleur de domaine ou le serveur de groupe de travail.
  2. Si cela ne résout pas le problème, définissez la valeur d’entrée de Registre sur 0x01. Cela permet de configurer NTLM pour fournir des réponses LMv2 qui ne sont pas soumises à une asymétrie temporelle.

Qu’est-ce que CBT (Channel Binding Token) ?

Le jeton de liaison de canal (CBT) fait partie de la protection étendue pour l’authentification. CBT est un mécanisme permettant de lier un canal sécurisé TLS externe à l’authentification du canal interne, telle que Kerberos ou NTLM.

CBT est une propriété du canal sécurisé externe utilisé pour lier l’authentification au canal.

La protection étendue est effectuée par le client qui communique le SPN et le CBT au serveur de manière inviolable. Le serveur valide les informations de protection étendue conformément à sa stratégie et rejette les tentatives d’authentification pour lesquelles il ne croit pas avoir été la cible prévue. De cette façon, les deux canaux deviennent liés par chiffrement.

La protection étendue est désormais prise en charge dans Windows XP, Windows Vista, Windows Server 2003 et Windows Server 2008.

Clause d’exclusion de responsabilité

Les articles de publication rapide fournissent des informations directement au sein de l’organisation de support Microsoft. Les informations contenues dans les présentes sont créées en réponse à des sujets émergents ou uniques, ou sont destinées à compléter d’autres informations de la base de connaissances.

Microsoft et/ou ses fournisseurs ne font aucune déclaration ou garantie quant à la pertinence, à la fiabilité ou à l’exactitude des informations contenues dans les documents et les graphiques associés publiés sur ce site Web (les « supports ») à quelque fin que ce soit. Les documents peuvent contenir des inexactitudes techniques ou des erreurs typographiques et peuvent être révisés à tout moment sans préavis.

Dans la mesure maximale autorisée par la loi applicable, Microsoft et/ou ses fournisseurs rejettent et excluent toutes les représentations, garanties et conditions qu’elles soient expresses, implicites ou légales, y compris, mais sans s’y limiter, les représentations, les garanties ou conditions de titre, l’absence de contrefaçon, la condition satisfaisante ou la qualité, la qualité, la qualité marchande et l’adéquation à un usage particulier, en ce qui concerne les matériaux.