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 de la façon dont les jetons de liaison de canal sont gérés.

Numéro de 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 serveur de contrôleur de domaine ou 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 de service (SPN) utilisé. En outre, 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 défaillances où les 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 défaillances où les serveurs ou serveurs proxy non-Windows NTLM nécessitent LMv2, vérifiez auprès du fournisseur une version qui prend en charge NTLMv2.

Solution de contournement

Important

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, vérifiez que vous suivez ces étapes attentivement. Pour une protection supplémentaire, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre si un problème se produit. Pour plus d’informations sur la sauvegarde et la restauration du registre, voir : Procédure de sauvegarde, de modification et de restauration du 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 le CBT :

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

Note

Il existe un problème connu avec Sun Java qui a été résolu pour prendre en charge l’option que l’accepteur peut ignorer les liaisons de canal fournies par l’initiateur, en retournant la réussite même si l’initiateur a transmis 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 un.

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 le cbT, définissez la valeur d’entrée de Registre sur 0x01. Cela configure NTLM pour ne pas émettre de jetons CBT pour les applications non corrigés.

Pour les serveurs non Windows NTLM ou les serveurs proxy qui nécessitent LMv2, définissez la valeur d’entrée du Registre sur 0x01. Cela 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 configure NTLM pour fournir des réponses LMv2 qui ne sont pas soumises à une asymétrie temporelle.

Qu’est-ce que CBT (jeton de liaison de canal) ?

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 de 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 falsifiée. Le serveur valide les informations de protection étendues conformément à sa stratégie et rejette les tentatives d’authentification pour lesquelles il ne croit pas qu’elle a été la cible prévue. Les deux canaux sont ainsi 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.

Exclusion de responsabilité

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

Microsoft et/ou ses fournisseurs ne font aucune représentation ni garantie concernant la pertinence, la fiabilité ou l’exactitude des informations contenues dans les documents et les graphiques connexes publiés sur ce site web (les « documents ») à des fins quelconques. Les documents peuvent inclure 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 excluent toutes les représentations, garanties et conditions expresses, implicites ou légales, y compris, mais non limitées aux représentations, garanties ou conditions de titre, non violation, condition satisfaisante ou qualité, qualité et adéquation à un usage particulier, en ce qui concerne les matériaux.