L’approbation entre un domaine Windows NT et un domaine Active Directory ne peut pas être établie ou ne fonctionne pas comme prévu

Cet article décrit les problèmes de configuration d’approbation entre un domaine Windows NT 4.0 et un domaine basé sur Active Directory.

Produits concernés : Windows 10 - toutes les éditions, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 889030

Symptômes

Si vous essayez de configurer une approbation entre un domaine Microsoft Windows NT 4.0 et un domaine basé sur Active Directory, vous pouvez rencontrer l’un des symptômes suivants :

• L’approbation n’est pas établie.
• L’approbation est établie, mais elle ne fonctionne pas comme prévu.

En outre, vous pouvez recevoir l’un des messages d’erreur suivants :

L’erreur suivante s’est produite lors de la tentative de jointure du domaine « Domain_Name » : le compte n’est pas autorisé à se connecter à partir de cette station.

L’accès est refusé.

Aucun contrôleur de domaine n’a pu être contacté.

Échec de connexion : nom d’utilisateur inconnu ou mot de passe incorrect.

Lorsque vous utilisez le sélecteur d’objets dans Utilisateurs et ordinateurs Active Directory pour ajouter des utilisateurs du domaine NT 4.0 au domaine Active Directory, le message d’erreur suivant peut s’afficher :

Aucun élément ne correspond à la recherche actuelle. Vérifiez vos paramètres de recherche, puis réessayez.

Cause

Ce problème se produit en raison d’un problème de configuration dans l’un des domaines suivants :

• Résolution de noms
• Paramètres de sécurité
• Droits de l’utilisateur
• Appartenance à un groupe pour Microsoft Windows 2000 ou Microsoft Windows Server 2003

Pour identifier correctement la cause du problème, vous devez résoudre les problèmes de configuration de l’approbation.

Résolution

Si vous recevez le message d’erreur « Aucun élément ne correspond à la recherche actuelle » lorsque vous utilisez le sélecteur d’objets dans Utilisateurs et ordinateurs Active Directory, assurez-vous que les contrôleurs de domaine dans le domaine NT 4.0 incluent tout le monde dans le droit Accéder à cet ordinateur à partir du réseau utilisateur. Dans ce scénario, le sélecteur d’objets tente de se connecter anonymement au sein de l’approbation. Pour vérifier ces paramètres, suivez les étapes de la section « Méthode 3 : Vérifier les droits de l’utilisateur ».

Pour résoudre les problèmes de configuration d’approbation entre un domaine Windows NT 4.0 et Active Directory, vous devez vérifier la configuration correcte des zones suivantes :

• Résolution de noms
• Paramètres de sécurité
• Droits de l’utilisateur
• Appartenance à un groupe pour Microsoft Windows 2000 ou Microsoft Windows Server 2003

Pour ce faire, utilisez les méthodes suivantes.

Méthode 1 : Vérifier la configuration correcte de la résolution de noms

Étape 1 : Créer un fichier LMHOSTS

Créez un fichier LMHOSTS sur les contrôleurs de domaine principaux pour fournir une fonctionnalité de résolution de noms inter-domaines. Le fichier LMHOSTS est un fichier texte que vous pouvez modifier avec n’importe quel éditeur de texte, tel que le Bloc-notes. Le fichier LMHOSTS sur chaque contrôleur de domaine doit contenir l’adresse TCP/IP, le nom de domaine et l’entrée \0x1b de l’autre contrôleur de domaine.

Après avoir créé le fichier LMHOSTS, procédez comme suit :

1. Modifiez le fichier afin qu’il contienne du texte similaire au texte suivant :

   1.1.1.1 <NT_4_PDC_Name> #DOM :<NT_4_Domain_Name>#PRE
   1.1.1.1 « <NT_4_Domain> \0x1b"#PRE
   2.2.2.2 <Windows_2000_PDC_Name> #DOM :<Windows_2000_Domain_Name>#PRE
   2.2.2.2 «< 2000_Domain> \0x1b » #PRE

   Remarque

   Il doit y avoir un total de 20 caractères et espaces entre les guillemets ( » « ) pour l’entrée \0x1b. Ajoutez des espaces après le nom de domaine afin qu’il utilise 15 caractères. Le 16e caractère est la barre oblique inverse suivie de la valeur « 0x1b », ce qui fait un total de 20 caractères.

2. Lorsque vous avez terminé les modifications apportées au fichier LMHOSTS, enregistrez le fichier dans le dossier %SystemRoot% \System32\Drivers\Etc sur les contrôleurs de domaine. Pour plus d’informations sur le fichier LMHOSTS, consultez l’exemple de fichier Lmhosts.sam qui se trouve dans le dossier %SystemRoot% \System32\Drivers\Etc.

Étape 2 : Charger le fichier LMHOSTS dans le cache

1. Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.

2. À l’invite de commandes, tapez NBTSTAT -R, puis appuyez sur Entrée. Cette commande charge le fichier LMHOSTS dans le cache.

3. À l’invite de commandes, tapez NBTSTAT -c, puis appuyez sur Entrée. Cette commande affiche le cache. Si le fichier est écrit correctement, le cache est similaire à ce qui suit :

   NT4PDCName <03> UNIQUE 1.1.1.1 -1
   NT4PDCName <00> UNIQUE 1.1.1.1 -1
   NT4PDCName <20> UNIQUE 1.1.1.1 -1
   NT4DomainName <1C> GROUP 1.1.1.1 -1
   NT4DomainName <1B> UNIQUE 1.1.1.1 -1
   W2KPDCName <03> UNIQUE 2.2.2.2 -1
   W2KPDCName <00> UNIQUE 2.2.2.2 -1
   W2KPDCName <20> UNIQUE 2.2.2.2 -1
   W2KDomainName <1C> GROUP 2.2.2.2 -1
   W2KDomainName <1B> UNIQUE 2.2.2.2 -1

   Si le fichier ne remplit pas correctement le cache, passez à l’étape suivante.

Étape 3 : Vérifier que la recherche LMHOSTS est activée sur l’ordinateur Windows NT 4.0

Si le fichier ne remplit pas correctement le cache, assurez-vous que la recherche LMHOSTS est activée sur l’ordinateur Windows NT 4.0. Pour cela, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Paramètres, puis cliquez sur Panneau de configuration.
2. Double-cliquez sur Réseaux, cliquez sur l’onglet Protocoles , puis double-cliquez sur Protocole TCP/IP.
3. Cliquez sur l’onglet Adresse WINS, puis sélectionnez la zone Activer la recherche LMHOSTS case activée.
4. Redémarrez l'ordinateur.
5. Répétez les étapes de la section « Charger le fichier LMHOSTS dans le cache ».
6. Si le fichier ne remplit pas correctement le cache, assurez-vous que le fichier LMHOSTS se trouve dans le dossier %SystemRoot%\System32\Drivers\Etc et que le fichier est correctement mis en forme.

Par exemple, le fichier doit être mis en forme de la même façon que l’exemple de mise en forme suivant :

1.1.1.1 NT4PDCName #DOM :NT4DomainName#PRE
1.1.1.1 « NT4DomainName \0x1b » #PRE
2.2.2.2 W2KPDCName #DOM :W2KDomainName#PRE
2.2.2.2 « W2KDomainName \0x1b » #PRE

Étape 4 : Utiliser la commande Ping pour tester la connectivité

Lorsque le fichier remplit correctement le cache sur chaque serveur, utilisez la Ping commande sur chaque serveur pour tester la connectivité entre les serveurs. Pour cela, procédez comme suit :

1. Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.

2. À l’invite de commandes, tapez Ping <Name_Of_Domain_Controller_You_Want_To_Connect_To>, puis appuyez sur Entrée. Si la Ping commande ne fonctionne pas, assurez-vous que les adresses IP correctes sont répertoriées dans le fichier LMHOSTS.

3. À l’invite de commandes, tapez net view <Name_Of_Domain_Controller_You_Want_To_Connect_To>, puis appuyez sur Entrée. Le message d’erreur suivant doit s’afficher :

   L’erreur système 5 s’est produite. Accès refusé

   Si la commande net view retourne le message d’erreur suivant ou tout autre message d’erreur associé, assurez-vous que les adresses IP correctes sont répertoriées dans le fichier LMHOSTS :

   L’erreur système 53 s’est produite. Le chemin réseau n’a pas été trouvé.

Vous pouvez également configurer wins (Windows Internet Name Service) pour activer la fonctionnalité de résolution de noms sans utiliser de fichier LMHOSTS.

Méthode 2 : Afficher les paramètres de sécurité

En règle générale, le côté Active Directory de la configuration d’approbation comporte des paramètres de sécurité qui provoquent des problèmes de connectivité. Toutefois, les paramètres de sécurité doivent être inspectés des deux côtés de l’approbation.

Étape 1 : Afficher les paramètres de sécurité sur Windows 2000 Server et Windows Server 2003

Dans Windows 2000 Server et Windows Server 2003, les paramètres de sécurité peuvent être appliqués ou configurés par stratégie de groupe, une stratégie locale ou un modèle de sécurité appliqué.

Vous devez utiliser les outils appropriés pour déterminer les valeurs actuelles des paramètres de sécurité afin d’éviter les lectures inexactes.

Pour obtenir une lecture précise des paramètres de sécurité actuels, utilisez les méthodes suivantes :

• Dans Windows 2000 Server, utilisez le composant logiciel enfichable Configuration et analyse de la sécurité.

• Dans Windows Server 2003, utilisez le composant logiciel enfichable Configuration et analyse de la sécurité ou le composant logiciel enfichable RSoP (Resultant Set of Policy).

Après avoir déterminé les paramètres actuels, vous devez identifier la stratégie qui applique les paramètres. Par exemple, vous devez déterminer le stratégie de groupe dans Active Directory ou les paramètres locaux qui définissent la stratégie de sécurité.

Dans Windows Server 2003, la stratégie qui définit les valeurs de sécurité est identifiée par l’outil RSoP. Toutefois, dans Windows 2000, vous devez afficher les stratégie de groupe et la stratégie locale pour déterminer la stratégie qui contient les paramètres de sécurité :

• Pour afficher les paramètres de stratégie de groupe, vous devez activer la sortie de journalisation pour le client de configuration de sécurité Microsoft Windows 2000 pendant stratégie de groupe traitement.

• Affichez le observateur d'événements de connexion de l’application et recherchez l’ID d’événement 1000 et l’ID d’événement 1202.

Les trois sections suivantes identifient le système d’exploitation et répertorient les paramètres de sécurité que vous devez vérifier pour le système d’exploitation dans les informations que vous avez collectées :

Windows 2000

Vérifiez que les paramètres suivants sont configurés comme indiqué.

RestrictAnonymous :

Compatibilité LM :

Signature SMB, chiffrement SMB, ou les deux :

Windows Server 2003

Vérifiez que les paramètres suivants sont configurés comme indiqué.

RestrictAnonymous et RestrictAnonymousSam :

Compatibilité LM :

Signature SMB, chiffrement SMB, ou les deux :

Une fois les paramètres correctement configurés, vous devez redémarrer votre ordinateur. Les paramètres de sécurité ne sont pas appliqués tant que l’ordinateur n’est pas redémarré.

Après le redémarrage de l’ordinateur, attendez 10 minutes pour vous assurer que toutes les stratégies de sécurité sont appliquées et que les paramètres effectifs sont configurés. Nous vous recommandons d’attendre 10 minutes, car les mises à jour de stratégie Active Directory se produisent toutes les 5 minutes sur un contrôleur de domaine, et la mise à jour peut modifier les valeurs des paramètres de sécurité. Après 10 minutes, utilisez Configuration et analyse de la sécurité ou un autre outil pour examiner les paramètres de sécurité dans Windows 2000 et Windows Server 2003.

Windows NT 4.0

Dans Windows NT 4.0, les paramètres de sécurité actuels doivent être vérifiés à l’aide de l’outil Regedt32 pour afficher le Registre. Pour cela, procédez comme suit :

1. Cliquez sur Démarrer, sur Exécuter, tapez regedt32, puis cliquez sur OK.

2. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée RestrictAnonymous :

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters

3. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée Compatibilité LM :

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

4. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée EnableSecuritySignature (serveur) :

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature

5. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée RequireSecuritySignature (serveur) :

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\RequireSecuritySignature

6. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée RequireSignOrSeal :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

7. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée SealSecureChannel :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

8. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée SignSecureChannel :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

9. Développez les sous-clés de Registre suivantes, puis affichez la valeur affectée à l’entrée RequireStrongKey :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Méthode 3 : Vérifier les droits de l’utilisateur

Pour vérifier les droits d’utilisateur requis sur un ordinateur Windows 2000, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Programmes, sur Outils d’administration, puis cliquez sur Stratégie de sécurité locale.
2. Développez Stratégies locales, puis cliquez sur Attribution des droits utilisateur.
3. Dans le volet droit, double-cliquez sur Accéder à cet ordinateur à partir du réseau.
4. Cliquez pour sélectionner la zone de case activée Paramètre de stratégie locale en regard du groupe Tout le monde dans la liste Affecté à, puis cliquez sur OK.
5. Double-cliquez sur Refuser l’accès à cet ordinateur à partir du réseau.
6. Vérifiez qu’il n’existe aucun groupe principal dans la liste Affecté à , puis cliquez sur OK. Par exemple, assurez-vous que Tout le monde, Utilisateurs authentifiés et autres groupes ne sont pas répertoriés.
7. Cliquez sur OK, puis quittez Stratégie de sécurité locale.

Pour vérifier les droits d’utilisateur requis sur un ordinateur Windows Server 2003, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Stratégie de sécurité du contrôleur de domaine.

2. Développez Stratégies locales, puis cliquez sur Attribution des droits utilisateur.

3. Dans le volet droit, double-cliquez sur Accéder à cet ordinateur à partir du réseau.

4. Vérifiez que le groupe Tout le monde figure dans la liste Accéder à cet ordinateur à partir du réseau .

   Si le groupe Tout le monde n’est pas répertorié, procédez comme suit :

   1. Cliquez sur Ajouter un utilisateur ou un groupe.
   2. Dans la zone Noms d’utilisateurs et de groupes , tapez Tout le monde, puis cliquez sur OK.

5. Double-cliquez sur Refuser l’accès à cet ordinateur à partir du réseau.

6. Vérifiez qu’il n’existe aucun groupe principal dans la liste Refuser l’accès à cet ordinateur à partir du réseau , puis cliquez sur OK. Par exemple, assurez-vous que tout le monde, utilisateurs authentifiés et autres groupes ne sont pas répertoriés.

7. Cliquez sur OK, puis fermez la stratégie de sécurité du contrôleur de domaine.

Pour vérifier les droits d’utilisateur requis sur un ordinateur Windows NT Server 4.0, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Programmes, sur Outils d’administration, puis cliquez sur Gestionnaire d’utilisateurs pour les domaines.

2. Dans le menu Stratégies , cliquez sur Droits utilisateur.

3. Dans la liste Droite , cliquez sur Accéder à cet ordinateur à partir du réseau.

4. Dans la zone Accorder à , vérifiez que le groupe Tout le monde est ajouté.

   Si le groupe Tout le monde n’est pas ajouté, procédez comme suit :

   1. Cliquez sur Ajouter.
   2. Dans la liste Noms , cliquez sur Tout le monde, sur Ajouter, puis sur OK.

5. Cliquez sur OK, puis quittez le Gestionnaire d’utilisateurs.

Méthode quatre : Vérifier l’appartenance au groupe

Si une approbation est configurée entre les domaines, mais que vous ne pouvez pas ajouter de groupes d’utilisateurs principaux d’un domaine à l’autre, car la boîte de dialogue ne localise pas les autres objets de domaine, le groupe « Accès compatible pré Windows 2000 » peut ne pas avoir l’appartenance correcte.

Sur les contrôleurs de domaine Windows 2000 et les contrôleurs de domaine Windows Server 2003, assurez-vous que les appartenances de groupe requises sont configurées.

Pour ce faire sur les contrôleurs de domaine Windows 2000, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Programmes, puis sur Outils d’administration, et cliquez sur Utilisateurs et ordinateurs Active Directory.

2. Cliquez sur Intégré, puis double-cliquez sur Groupe d’accès compatible pré Windows 2000.

3. Cliquez sur l’onglet Membres , puis vérifiez que le groupe Tout le monde figure dans la liste Membres .

4. Si le groupe Tout le monde ne figure pas dans la liste Membres , procédez comme suit :

   1. Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.
   2. À l’invite de commandes, tapez net localgroup "Pre-Windows 2000 Compatible Access" everyone /add, puis appuyez sur Entrée.

Pour vous assurer que les appartenances de groupe requises sont configurées sur les contrôleurs de domaine Windows Server 2003, vous devez savoir si le paramètre de stratégie « Accès réseau : Permettre à tout le monde que les autorisations s’appliquent aux utilisateurs anonymes » est désactivé. Si vous ne le savez pas, utilisez le Rédacteur d’objet stratégie de groupe pour déterminer l’état du paramètre de stratégie « Accès réseau : Permettre à tout le monde que les autorisations s’appliquent aux utilisateurs anonymes ». Pour cela, procédez comme suit :

1. Cliquez sur Démarrer, sur Exécuter, tapez gpedit.msc, puis cliquez sur OK.

2. Développez les dossiers suivants :

   Stratégie de l’ordinateur local
   Ordinateur configuration
   Paramètres Windows
   Paramètres de sécurité
   Stratégies locales

3. Cliquez sur Options de sécurité, puis sur Accès réseau : Autoriser tout le monde à appliquer les autorisations aux utilisateurs anonymes dans le volet droit.

4. Notez si la valeur dans la colonne Paramètre de sécurité est Désactivé ou Activé.

Pour vous assurer que les appartenances de groupe requises sont configurées sur les contrôleurs de domaine Windows Server 2003, procédez comme suit :

1. Cliquez sur Démarrer, pointez sur Programmes, puis sur Outils d’administration, et cliquez sur Utilisateurs et ordinateurs Active Directory.

2. Cliquez sur Intégré, puis double-cliquez sur Groupe d’accès compatible pré Windows 2000.

3. Cliquez sur l’onglet Membres.

4. Si le paramètre de stratégie Accès réseau : Autoriser tout le monde à s’appliquer aux utilisateurs anonymes est désactivé, assurez-vous que le groupe Tout le monde, ouverture de session anonyme figure dans la liste Membres . Si le paramètre de stratégie « Accès réseau : Autoriser tout le monde à s’appliquer aux utilisateurs anonymes » est activé, assurez-vous que le groupe Tout le monde figure dans la liste Membres .

5. Si le groupe Tout le monde ne figure pas dans la liste Membres , procédez comme suit :

   1. Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.
   2. À l’invite de commandes, tapez net localgroup "Pre-Windows 2000 Compatible Access" everyone /add, puis appuyez sur Entrée.

Méthode 5 : Vérifier la connectivité via des périphériques réseau, tels que des pare-feu, des commutateurs ou des routeurs

Si vous avez reçu des messages d’erreur similaires au message d’erreur suivant et que vous avez vérifié que les fichiers LMHOST sont corrects, le problème peut être dû à un pare-feu, un routeur ou un commutateur qui a des ports bloqués entre les contrôleurs de domaine :

Aucun contrôleur de domaine n’a pu être contacté

Pour résoudre les problèmes liés aux périphériques réseau, utilisez portQry Command Line Port Scanner version 2.0 pour tester les ports entre vos contrôleurs de domaine.

Pour plus d’informations sur PortQry version 2, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

832919 Nouvelles fonctionnalités de PortQry version 2.0

Pour plus d’informations sur la façon dont les ports doivent être configurés, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

179442 Comment configurer un pare-feu pour les domaines et les approbations

Méthode six : Collecter des informations supplémentaires pour vous aider à résoudre le problème

Si les méthodes précédentes ne vous ont pas aidé à résoudre le problème, collectez les informations supplémentaires suivantes pour vous aider à résoudre la cause du problème :

• Activez la journalisation Netlogon sur les deux contrôleurs de domaine. Pour plus d’informations sur la façon d’effectuer la journalisation Netlogon, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft : 109626 Activation de la journalisation du débogage pour le service Net Logon

• Capturez une trace sur les deux contrôleurs de domaine en même temps que le problème se produit.

Plus d’informations

La liste suivante d’objets stratégie de groupe (GPO) fournit l’emplacement de l’entrée de Registre correspondante et le stratégie de groupe dans les systèmes d’exploitation applicables :

• Objet de stratégie de groupe RestrictAnonymous :

  • Emplacement du Registre Windows NT : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters
  • Emplacement du Registre Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
  • Windows 2000 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\ Options de sécurité Restrictions supplémentaires pour les connexions anonymes
  • Windows Server 2003 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité Accès réseau : N’autorisez pas l’énumération anonyme des comptes et partages SAM

• L’objet de stratégie de groupe RestrictAnonymousSAM :

  • Emplacement du Registre Windows Server 2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
  • Windows Server 2003 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité Options de sécurité Accès réseau : N’autorisez pas l’énumération anonyme des comptes et partages SAM

• L’objet de stratégie de groupe EveryoneIncludesAnonymous :

  • Emplacement du Registre Windows Server 2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
  • Windows Server 2003 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité Accès réseau : Autoriser tout le monde à appliquer les autorisations aux utilisateurs anonymes

• L’objet de stratégie de groupe de compatibilité LM :

  • Emplacement du Registre Windows NT, Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

  • Windows 2000 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité : niveau d’authentification DU GESTIONNAIRE DE RÉSEAU LOCAL

  • Windows Server 2003 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité\Sécurité du réseau : niveau d’authentification du Gestionnaire de réseau local

• Objet de stratégie de groupe EnableSecuritySignature (client) :

  • Emplacement du Registre Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters\EnableSecuritySignature
  • Windows 2000 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité \Options de sécurité : Communication cliente de signature numérique (si possible)
  • Windows Server 2003 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité\Client réseau Microsoft : communications de signature numérique (si le serveur accepte)

• Objet de stratégie de groupe RequireSecuritySignature (client) :

  • Emplacement du Registre Windows 2000 et Windows Server 2003 : HKey_Local_Machine\System\CurrentControlSet\Services\LanManWorkstation\Parameters\RequireSecuritySignature
  • Windows 2000 stratégie de groupe : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité : Communication cliente de signature numérique (toujours)
  • Windows Server 2003 : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité\Client réseau Microsoft : Communications de signature numérique (toujours)

• Objet de stratégie de groupe EnableSecuritySignature (serveur) :

  • Emplacement du Registre Windows NT : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature
  • Emplacement du Registre Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature
  • Windows 2000 stratégie de groupe : Communication du serveur de signature numérique (si possible)
  • Windows Server 2003 stratégie de groupe : Serveur réseau Microsoft : communications de signature numérique (si le client accepte)

• L’objet de stratégie de groupe RequireSecuritySignature (serveur) :

  • Emplacement du Registre Windows NT : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\RequireSecurityS ignature
  • Emplacement du Registre Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\Require SecuritySignature
  • Windows 2000 stratégie de groupe : Communication du serveur de signature numérique (toujours)
  • Windows Server 2003 stratégie de groupe : Serveur réseau Microsoft : Communications de signature numérique (toujours)

• L’objet de stratégie de groupe RequireSignOrSeal :

  • Emplacement du Registre Windows NT, Windows 2000 et Windows Server2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  • Windows 2000 stratégie de groupe : chiffrer ou signer numériquement des données de canal sécurisé (toujours)
  • Windows Server2003 stratégie de groupe : Membre de domaine : chiffrer ou signer numériquement des données de canal sécurisé (toujours)

• L’objet de stratégie de groupe SealSecureChannel :

  • Emplacement du Registre Windows NT, Windows 2000 et Windows Server2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  • Windows 2000 stratégie de groupe : Canal sécurisé : chiffrer numériquement les données de canal sécurisé (si possible)
  • Windows Server 2003 stratégie de groupe : Membre de domaine : chiffrer numériquement les données de canal sécurisé (si possible)

• L’objet de stratégie de groupe SignSecureChannel :

  • Emplacement du Registre Windows NT, Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  • Windows 2000 stratégie de groupe : Canal sécurisé : signer numériquement des données de canal sécurisées (si possible)
  • Windows Server 2003 stratégie de groupe : Membre de domaine : signer numériquement les données du canal sécurisé (si possible)

• L’objet de stratégie de groupe RequireStrongKey :

  • Emplacement du Registre Windows NT, Windows 2000 et Windows Server 2003 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  • Windows 2000 stratégie de groupe : Canal sécurisé : exiger une clé de session forte (Windows 2000 ou version ultérieure)
  • Windows Server 2003 stratégie de groupe : Membre de domaine : Exiger une clé de session forte (Windows 2000 ou version ultérieure)

Windows Server 2008

Sur un contrôleur de domaine exécutant Windows Server 2008, le comportement par défaut du paramètre de stratégie Autoriser les algorithmes de chiffrement compatibles avec Windows NT 4.0 peut entraîner un problème. Ce paramètre empêche les systèmes d’exploitation Windows et les clients tiers d’utiliser des algorithmes de chiffrement faibles pour établir des canaux de sécurité NETLOGON vers les contrôleurs de domaine Windows Server 2008.

References

Pour plus d’informations, cliquez sur les numéros d’article suivants pour afficher les articles dans la Base de connaissances Microsoft :

823659 incompatibilités de client, de service et de programme qui peuvent se produire lorsque vous modifiez les paramètres de sécurité et les attributions de droits utilisateur