Échec de l’authentification à partir de serveurs NTLM ou Kerberos non Windows
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 des handles.
Produits concernés : Windows 7 Service Pack 1, Windows Server 2012 R2
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 autre que Windows.
- Échecs d’authentification NTLM à partir de serveurs proxy.
- Échecs d’authentification NTLM à partir de serveurs NTLM non Windows.
- É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é. 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
En cas d’échecs où des serveurs NTLM ou Kerberos non Windows échouent lors de la réception de CBT, contactez le fournisseur pour obtenir une version qui gère correctement CBT.
Pour les échecs où des serveurs NTLM ou proxy non Windows nécessitent LMv2, contactez le fournisseur pour obtenir 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 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 :
- Définissez la valeur d’entrée du Registre sur 0x01. Cela configure Kerberos pour qu’il n’émette pas de jetons CBT pour les applications non configurées.
- Si cela ne résout pas le problème, définissez la valeur d’entrée du Registre sur 0x03. Cela configure Kerberos pour qu’il n’émette jamais de jetons CBT.
Remarque
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 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 à RFC 4121. Pour plus d’informations, consultez ignorer la liaison de canal entrant si l’accepteur n’en définit pas une.
Nous vous recommandons d’installer la mise à jour suivante à partir du site Java Sun et de réactiver la protection étendue : modifications apportées à 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 NTLM non Windows qui ne gèrent pas correctement le CBT, définissez la valeur d’entrée de Registre sur 0x01. Cela configure NTLM pour qu’il n’émette pas de jetons CBT pour les applications non configurées.
Pour les serveurs NTLM non Windows 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 l’intervalle de temps est trop grand :
- Corrigez l’horloge du client pour refléter l’heure sur le contrôleur de domaine ou le serveur de groupe de travail.
- Si cela ne résout pas le problème, définissez la valeur d’entrée du 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 (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 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 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 à partir de l’organisation de support Microsoft. Les informations contenues ici 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 ou garantie sur l’adéquation, la fiabilité ou l’exactitude des informations contenues dans les documents et graphiques connexes publiés sur ce site web (les « documents ») à quelque fin que ce soit. Les matériaux 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 démentent 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 les conditions de titre, de non-violation, de condition ou de qualité satisfaisante, de qualité, de qualité marchande et d’adéquation à une fin particulière, en ce qui concerne les documents.
Commentaires
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Envoyer et afficher des commentaires pour