Des problèmes de client, de service et de programme peuvent se produire si vous modifiez les paramètres de sécurité et les attributions de droits utilisateur

Windows XP

Pour mieux connaître les paramètres de sécurité mal configurés, utilisez l’outil Éditeur d’objets stratégie de groupe pour modifier les paramètres de sécurité. Lorsque vous utilisez stratégie de groupe’Éditeur d’objets, les attributions de droits utilisateur sont améliorées sur les systèmes d’exploitation suivants :

• Windows XP Professional Service Pack 2 (SP2)

• Windows Server 2003 Service Pack 1 (SP1)

La fonctionnalité améliorée est une boîte de dialogue qui contient un lien vers cet article. La boîte de dialogue s’affiche lorsque vous modifiez un paramètre de sécurité ou une attribution de droits d’utilisateur à un paramètre qui offre moins de compatibilité et est plus restrictif. Si vous modifiez directement le même paramètre de sécurité ou la même attribution de droits utilisateur à l’aide du Registre ou à l’aide de modèles de sécurité, l’effet est le même que la modification du paramètre dans stratégie de groupe’Éditeur d’objets. Toutefois, la boîte de dialogue qui contient le lien vers cet article n’apparaît pas.

Cet article contient des exemples de clients, de programmes et d’opérations qui sont affectés par des paramètres de sécurité spécifiques ou des attributions de droits utilisateur. Toutefois, les exemples ne font pas autorité pour tous les systèmes d’exploitation Microsoft, pour tous les systèmes d’exploitation tiers ou pour toutes les versions de programme affectées. Les paramètres de sécurité et les attributions de droits d’utilisateur ne sont pas tous inclus dans cet article.

Nous vous recommandons de valider la compatibilité de toutes les modifications de configuration liées à la sécurité dans une forêt de tests avant de les introduire dans un environnement de production. La forêt de test doit mettre en miroir la forêt de production des manières suivantes :

• Versions des systèmes d’exploitation client et serveur, programmes clients et serveurs, versions de Service Pack, correctifs logiciels, modifications de schéma, groupes de sécurité, appartenances aux groupes, autorisations sur les objets du système de fichiers, dossiers partagés, Registre, service d’annuaire Active Directory, paramètres locaux et stratégie de groupe, et type et emplacement du nombre d’objets

• Tâches administratives exécutées, outils d’administration utilisés et systèmes d’exploitation utilisés pour effectuer des tâches administratives

• Opérations effectuées, telles que les suivantes :

  • Authentification par connexion de l’ordinateur et de l’utilisateur

  • Réinitialisations de mot de passe par les utilisateurs, les ordinateurs et les administrateurs

  • Navigation

  • Définition des autorisations pour le système de fichiers, les dossiers partagés, le Registre et les ressources Active Directory à l’aide de l’éditeur ACL dans tous les systèmes d’exploitation clients dans tous les domaines de compte ou de ressource de tous les systèmes d’exploitation clients de tous les domaines de compte ou de ressource

  • Impression à partir de comptes administratifs et non-administrateurs

Windows Server 2003 SP1

Droits de l’utilisateur

La liste suivante décrit un droit de l’utilisateur, identifie les paramètres de configuration susceptibles de provoquer des problèmes, explique pourquoi vous devez appliquer le droit de l’utilisateur et pourquoi vous pouvez supprimer le droit de l’utilisateur, et fournit des exemples de problèmes de compatibilité qui peuvent se produire lorsque le droit de l’utilisateur est configuré.

1. Accéder à cet ordinateur à partir du réseau

   1. Fond
      
      La possibilité d’interagir avec des ordinateurs Windows distants nécessite l’accès à cet ordinateur à partir du droit de l’utilisateur réseau. Voici quelques exemples d’opérations réseau :

      • Réplication d’Active Directory entre des contrôleurs de domaine dans un domaine ou une forêt commun

      • Demandes d’authentification adressées aux contrôleurs de domaine à partir d’utilisateurs et d’ordinateurs

      • Accès à des dossiers partagés, des imprimantes et d’autres services système situés sur des ordinateurs distants sur le réseau

      
      
      Les utilisateurs, les ordinateurs et les comptes de service obtiennent ou perdent l’accès à cet ordinateur à partir du droit de l’utilisateur réseau en étant explicitement ou implicitement ajoutés ou supprimés d’un groupe de sécurité auquel ce droit d’utilisateur a été accordé. Par exemple, un compte d’utilisateur ou un compte d’ordinateur peut être ajouté explicitement à un groupe de sécurité personnalisé ou à un groupe de sécurité intégré par un administrateur, ou être implicitement ajouté par le système d’exploitation à un groupe de sécurité calculé tel que les utilisateurs de domaine, les utilisateurs authentifiés ou les contrôleurs de domaine d’entreprise.
      
      Par défaut, les comptes d’utilisateur et les comptes d’ordinateur se voient accorder l’accès à cet ordinateur à partir du droit de l’utilisateur réseau lorsque des groupes calculés tels que Tout le monde ou, de préférence, Utilisateurs authentifiés et, pour les contrôleurs de domaine, le groupe Contrôleurs de domaine d’entreprise, sont définis dans les contrôleurs de domaine par défaut stratégie de groupe Object (GPO).

   2. Configurations risquées
      
      Voici les paramètres de configuration dangereux :

      • Suppression du groupe de sécurité Contrôleurs de domaine d’entreprise de ce droit d’utilisateur

      • Suppression du groupe Utilisateurs authentifiés ou d’un groupe explicite qui permet aux utilisateurs, ordinateurs et comptes de service de se connecter aux ordinateurs via le réseau

      • Suppression de tous les utilisateurs et ordinateurs de ce droit d’utilisateur

   3. Raisons d’accorder à cet utilisateur le droit

      • L’octroi de l’accès à cet ordinateur à partir du droit de l’utilisateur réseau au groupe Contrôleurs de domaine d’entreprise répond aux exigences d’authentification que la réplication Active Directory doit avoir pour que la réplication se produise entre les contrôleurs de domaine dans la même forêt.

      • Ce droit d’utilisateur permet aux utilisateurs et aux ordinateurs d’accéder aux fichiers partagés, aux imprimantes et aux services système, y compris Active Directory.

      • Ce droit d’utilisateur est requis pour que les utilisateurs accèdent au courrier à l’aide des premières versions de Microsoft Outlook Web Access (OWA).

   4. Raisons de supprimer ce droit d’utilisateur

      • Les utilisateurs qui peuvent connecter leurs ordinateurs au réseau peuvent accéder aux ressources sur les ordinateurs distants pour lesquels ils disposent d’autorisations. Par exemple, ce droit d’utilisateur est requis pour qu’un utilisateur se connecte à des imprimantes partagées et à des dossiers. Si ce droit d’utilisateur est accordé au groupe Tout le monde et si certains dossiers partagés ont des autorisations de partage et de système de fichiers NTFS configurées pour que le même groupe dispose d’un accès en lecture, n’importe qui peut afficher les fichiers dans ces dossiers partagés. Toutefois, il s’agit d’une situation peu probable pour les nouvelles installations de Windows Server 2003, car le partage par défaut et les autorisations NTFS dans Windows Server 2003 n’incluent pas le groupe Tout le monde. Pour les systèmes mis à niveau à partir de Microsoft Windows NT 4.0 ou Windows 2000, cette vulnérabilité peut présenter un niveau de risque plus élevé, car le partage par défaut et les autorisations de système de fichiers pour ces systèmes d’exploitation ne sont pas aussi restrictifs que les autorisations par défaut dans Windows Server 2003.

      • Il n’existe aucune raison valide de supprimer le groupe Contrôleurs de domaine d’entreprise de ce droit d’utilisateur.

      • Le groupe Tout le monde est généralement supprimé en faveur du groupe Utilisateurs authentifiés. Si le groupe Tout le monde est supprimé, ce droit doit être accordé au groupe Utilisateurs authentifiés.

      • Les domaines Windows NT 4.0 mis à niveau vers Windows 2000 n’accordent pas explicitement l’accès à cet ordinateur à partir du droit de l’utilisateur réseau au groupe Tout le monde, au groupe Utilisateurs authentifiés ou au groupe Contrôleurs de domaine d’entreprise. Par conséquent, lorsque vous supprimez le groupe Tout le monde de la stratégie de domaine Windows NT 4.0, la réplication Active Directory échoue avec un message d’erreur « Accès refusé » après la mise à niveau vers Windows 2000. Winnt32.exe dans Windows Server 2003 évite cette configuration incorrecte en accordant au groupe Contrôleurs de domaine d’entreprise ce droit d’utilisateur lorsque vous mettez à niveau les contrôleurs de domaine principaux (PDCs) Windows NT 4.0. Accordez au groupe Contrôleurs de domaine d’entreprise ce droit d’utilisateur s’il n’est pas présent dans l’éditeur d’objets stratégie de groupe.

   5. Exemples de problèmes de compatibilité

      • Windows 2000 et Windows Server 2003 : la réplication des partitions suivantes échoue avec des erreurs « Accès refusé », comme indiqué par les outils de surveillance tels que REPLMON et REPADMIN, ou des événements de réplication dans le journal des événements.

        • Partition de schéma Active Directory

        • Partition de configuration

        • Partition de domaine

        • Partition de catalogue global

        • Partition d’application

      • Tous les systèmes d’exploitation réseau Microsoft : l’authentification du compte d’utilisateur à partir d’ordinateurs clients réseau distants échoue, sauf si l’utilisateur ou un groupe de sécurité dont l’utilisateur est membre a reçu ce droit d’utilisateur.

      • Tous les systèmes d’exploitation réseau Microsoft : l’authentification du compte à partir de clients réseau distants échoue, sauf si le compte ou un groupe de sécurité dont le compte est membre a reçu ce droit d’utilisateur. Ce scénario s’applique aux comptes d’utilisateur, aux comptes d’ordinateur et aux comptes de service.

      • Tous les systèmes d’exploitation réseau Microsoft : la suppression de tous les comptes de ce droit utilisateur empêche tout compte de se connecter au domaine ou d’accéder aux ressources réseau. Si des groupes calculés tels que les contrôleurs de domaine d’entreprise, tout le monde ou les utilisateurs authentifiés sont supprimés, vous devez explicitement accorder à cet utilisateur le droit à des comptes ou à des groupes de sécurité dont le compte est membre pour accéder aux ordinateurs distants sur le réseau. Ce scénario s’applique à tous les comptes d’utilisateur, à tous les comptes d’ordinateur et à tous les comptes de service.

      • Tous les systèmes d’exploitation réseau Microsoft : le compte d’administrateur local utilise un mot de passe « vide ». La connectivité réseau avec des mots de passe vides n’est pas autorisée pour les comptes d’administrateur dans un environnement de domaine. Avec cette configuration, vous pouvez vous attendre à recevoir un message d’erreur « Accès refusé ».

2. Autoriser l’ouverture de session localement

   1. Fond
      
      Les utilisateurs qui tentent de se connecter à la console d’un ordinateur Windows (à l’aide du raccourci clavier Ctrl+Alt+DELETE) et les comptes qui tentent de démarrer un service doivent disposer de privilèges d’ouverture de session locaux sur l’ordinateur d’hébergement. Les administrateurs qui se connectent aux consoles des ordinateurs membres, ou les contrôleurs de domaine dans l’ensemble de l’entreprise et les utilisateurs de domaine qui se connectent aux ordinateurs membres pour accéder à leurs ordinateurs de bureau à l’aide de comptes non privilégiés sont des exemples d’opérations d’ouverture de session locales. Les utilisateurs qui utilisent une connexion Bureau à distance ou Terminal Services doivent disposer du droit d’autorisation d’ouverture de session localement sur les ordinateurs de destination qui exécutent Windows 2000 ou Windows XP, car ces modes d’ouverture de session sont considérés comme locaux sur l’ordinateur d’hébergement. Les utilisateurs qui se connectent à un serveur sur lequel Terminal Server est activé et qui n’ont pas ce droit d’utilisateur peuvent toujours démarrer une session interactive à distance dans les domaines Windows Server 2003 s’ils disposent du droit d’ouverture de session Autoriser via Terminal Services.

   2. Configurations risquées
      
      Voici les paramètres de configuration dangereux :

      • Suppression des groupes de sécurité administratifs, notamment les opérateurs de compte, les opérateurs de sauvegarde, les opérateurs d’impression ou les opérateurs de serveur, et le groupe Administrateurs intégré de la stratégie du contrôleur de domaine par défaut.

      • Suppression des comptes de service utilisés par les composants et les programmes sur les ordinateurs membres et sur les contrôleurs de domaine dans le domaine de la stratégie du contrôleur de domaine par défaut.

      • Suppression d’utilisateurs ou de groupes de sécurité qui se connectent à la console des ordinateurs membres du domaine.

      • Suppression des comptes de service définis dans la base de données SAM (Security Accounts Manager) locale des ordinateurs membres ou des ordinateurs de groupe de travail.

      • Suppression des comptes d’administration non intégrés qui s’authentifient sur Terminal Services qui s’exécute sur un contrôleur de domaine.

      • Ajout explicite ou implicite de tous les comptes d’utilisateur dans le domaine par le biais du groupe Tout le monde au droit d’ouverture de session Refuser localement. Cette configuration empêche les utilisateurs de se connecter à n’importe quel ordinateur membre ou à n’importe quel contrôleur de domaine dans le domaine.

   3. Raisons d’accorder à cet utilisateur le droit

      • Les utilisateurs doivent disposer du droit d’autoriser l’utilisateur local à accéder à la console ou au bureau d’un ordinateur de groupe de travail, d’un ordinateur membre ou d’un contrôleur de domaine.

      • Les utilisateurs doivent avoir le droit de se connecter via une session Terminal Services qui s’exécute sur un ordinateur membre ou un contrôleur de domaine Windows 2000.

   4. Raisons de supprimer ce droit d’utilisateur

      • Si vous ne restreignez pas l’accès de la console aux comptes d’utilisateurs légitimes, les utilisateurs non autorisés peuvent télécharger et exécuter du code malveillant pour modifier leurs droits d’utilisateur.

      • La suppression du droit d’utilisateur autoriser l’ouverture d’une session locale empêche les connexions non autorisées sur les consoles des ordinateurs, tels que les contrôleurs de domaine ou les serveurs d’applications.

      • La suppression de ce droit d’ouverture de session empêche les comptes hors domaine de se connecter à la console des ordinateurs membres du domaine.

   5. Exemples de problèmes de compatibilité

      • Serveurs de terminal Windows 2000 : le droit d’utilisateur autoriser l’ouverture de session locale est requis pour que les utilisateurs se connectent aux serveurs de terminal Windows 2000.

      • Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 : les comptes d’utilisateur doivent avoir le droit d’ouvrir une session sur la console des ordinateurs exécutant Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003.

      • Windows NT 4.0 et versions ultérieures : sur les ordinateurs qui exécutent Windows NT 4.0 et versions ultérieures, si vous ajoutez le droit d’utilisateur autoriser l’ouverture de session locale, mais que vous accordez implicitement ou explicitement également le droit d’ouverture de session refuser localement, les comptes ne pourront pas se connecter à la console des contrôleurs de domaine.

3. Contourner la vérification de la traversée

   1. Fond
      
      La vérification du contournement permet à l’utilisateur de parcourir les dossiers du système de fichiers NTFS ou du Registre sans vérifier l’autorisation d’accès spécial Traverse Folder. Le contournement de la vérification du droit de l’utilisateur ne permet pas à l’utilisateur de répertorier le contenu d’un dossier. Il permet à l’utilisateur de parcourir uniquement ses dossiers.

   2. Configurations risquées
      
      Voici les paramètres de configuration dangereux :

      • Suppression de comptes non administratifs qui se connectent à des ordinateurs Terminal Services windows 2000 ou à des ordinateurs Terminal Services basés sur Windows Server 2003 qui ne disposent pas des autorisations nécessaires pour accéder aux fichiers et dossiers dans le système de fichiers.

      • Suppression du groupe Tout le monde de la liste des principaux de sécurité qui ont ce droit d’utilisateur par défaut. Les systèmes d’exploitation Windows, ainsi que de nombreux programmes, sont conçus avec l’espoir que toute personne pouvant accéder légitimement à l’ordinateur disposera du droit d’utilisateur de vérification de contournement. Par conséquent, la suppression du groupe Tout le monde de la liste des principaux de sécurité qui ont ce droit d’utilisateur par défaut peut entraîner une instabilité du système d’exploitation ou un échec du programme. Il est préférable de laisser ce paramètre à sa valeur par défaut.

   3. Raisons d’accorder à cet utilisateur le droit
      
      Le paramètre par défaut pour le droit d’utilisateur de vérification de la traversée de contournement est de permettre à quiconque de contourner la vérification de la traversée. Pour les administrateurs système Windows expérimentés, il s’agit du comportement attendu et ils configurent les listes de contrôle d’accès du système de fichiers (SACL) en conséquence. Le seul scénario où la configuration par défaut peut entraîner une mésaventures est si l’administrateur qui configure les autorisations ne comprend pas le comportement et s’attend à ce que les utilisateurs qui ne peuvent pas accéder à un dossier parent ne puissent pas accéder au contenu des dossiers enfants.

   4. Raisons de supprimer ce droit
      
      d’utilisateur Pour essayer d’empêcher l’accès aux fichiers ou aux dossiers dans le système de fichiers, les organisations qui sont très préoccupées par la sécurité peuvent être tentées de supprimer le groupe Tout le monde, ou même le groupe Utilisateurs, de la liste des groupes qui ont le droit de vérification de la traversée de contournement.

   5. Exemples de problèmes de compatibilité

      • Windows 2000, Windows Server 2003 : si le droit d’utilisateur de vérification de la traversée de contournement est supprimé ou mal configuré sur les ordinateurs exécutant Windows 2000 ou Windows Server 2003, stratégie de groupe paramètres du dossier SYVOL ne sont pas répliqués entre les contrôleurs de domaine du domaine.

      • Windows 2000, Windows XP Professionnel, Windows Server 2003 : les ordinateurs qui exécutent Windows 2000, Windows XP Professionnel ou Windows Server 2003 consignent les événements 1000 et 1202 et ne peuvent pas appliquer la stratégie d’ordinateur et la stratégie utilisateur lorsque les autorisations requises du système de fichiers sont supprimées de l’arborescence SYSVOL si le contournement de la vérification du droit utilisateur est supprimé ou mal configuré.
        
         

      • Windows 2000, Windows Server 2003 : Sur les ordinateurs exécutant Windows 2000 ou Windows Server 2003, l’onglet Quota dans l’Explorateur Windows disparaît lorsque vous affichez des propriétés sur un volume.

      • Windows 2000 : Les non-administrateurs qui se connectent à un serveur terminal Windows 2000 peuvent recevoir le message d’erreur suivant :

        Userinit.exe erreur d’application. L’application n’a pas pu s’initialiser correctement 0xc0000142 cliquez sur OK pour terminer l’application.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003 : les utilisateurs dont les ordinateurs exécutent Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 peuvent ne pas être en mesure d’accéder à des dossiers ou fichiers partagés sur des dossiers partagés, et ils peuvent recevoir des messages d’erreur « Accès refusé » s’ils ne reçoivent pas le droit de vérification de la traversée de contournement.
        
        
         

      • Windows NT 4.0 : sur les ordinateurs Windows NT 4.0, la suppression du droit d’utilisateur de vérification de la traversée de contournement entraîne la suppression d’une copie de fichier. Si vous supprimez ce droit d’utilisateur, lorsqu’un fichier est copié à partir d’un client Windows ou d’un client Macintosh vers un contrôleur de domaine Windows NT 4.0 exécutant Services pour Macintosh, le flux de fichier de destination est perdu et le fichier apparaît sous forme de fichier texte uniquement.

      • Microsoft Windows 95, Microsoft Windows 98 : sur un ordinateur client exécutant Windows 95 ou Windows 98, la commande net use * /home échoue avec un message d’erreur « Accès refusé » si le groupe Utilisateurs authentifiés ne dispose pas du droit de vérification de la traversée de contournement.

      • Outlook Web Access : les non-administrateurs ne pourront pas se connecter à Microsoft Outlook Web Access, et ils recevront un message d’erreur « Accès refusé » s’ils ne reçoivent pas le droit d’utilisateur de vérification de contournement.

Paramètres de sécurité

La liste suivante identifie un paramètre de sécurité, et la liste imbriqué fournit une description du paramètre de sécurité, identifie les paramètres de configuration susceptibles de provoquer des problèmes, explique pourquoi vous devez appliquer le paramètre de sécurité, puis décrit les raisons pour lesquelles vous pouvez vouloir supprimer le paramètre de sécurité. La liste imbriqué fournit ensuite un nom symbolique pour le paramètre de sécurité et le chemin d’accès au Registre du paramètre de sécurité. Enfin, des exemples de problèmes de compatibilité peuvent se produire lorsque le paramètre de sécurité est configuré.

1. Audit : Arrêtez immédiatement le système si vous ne parvenez pas à consigner les audits de sécurité

   1. Arrière-plan

      • L’audit : arrêter le système immédiatement si vous ne parvenez pas à consigner le paramètre audits de sécurité détermine si le système s’arrête si vous ne pouvez pas journaliser les événements de sécurité. Ce paramètre est requis pour l’évaluation C2 du programme DSTC (Trusted Computer Security Evaluation Criteria) et pour les critères communs pour l’évaluation de la sécurité des technologies de l’information afin d’empêcher les événements vérifiables si le système d’audit ne peut pas consigner ces événements. Si le système d’audit échoue, le système est arrêté et un message d’erreur Arrêter s’affiche.

      • Si l’ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, les preuves critiques ou les informations de dépannage importantes peuvent ne pas être disponibles pour examen après un incident de sécurité.

   2. Configuration
      
      risquée Voici un paramètre de configuration dangereux : Le système Audit : Arrêter immédiatement si vous ne parvenez pas à consigner le paramètre audits de sécurité est activé et la taille du journal des événements de sécurité est limitée par l’option Ne pas remplacer les événements (effacer le journal manuellement), l’option Événements de remplacement en fonction des besoins ou l’option Événements de remplacement antérieurs à plusieurs jours dans observateur d'événements. Consultez la section « Exemples de problèmes de compatibilité » pour plus d’informations sur les risques spécifiques pour les ordinateurs qui exécutent la version d’origine de Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 ou Windows 2000 SP3.

   3. Raisons d’activer ce paramètre
      
      Si l’ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, les preuves critiques ou les informations de dépannage importantes peuvent ne pas être disponibles pour examen après un incident de sécurité.

   4. Raisons de désactiver ce paramètre

      • L’activation de l’audit : arrêter immédiatement le système si vous ne parvenez pas à consigner le paramètre audits de sécurité arrête le système si un audit de sécurité ne peut pas être journalisé pour une raison quelconque. En règle générale, un événement ne peut pas être journalisé lorsque le journal d’audit de sécurité est plein et que sa méthode de rétention spécifiée est l’option Ne pas remplacer les événements (effacer le journal manuellement) ou l’option Événements de remplacement antérieurs à nombre de jours.

      • La charge administrative liée à l’activation du système Audit : Arrêter immédiatement si vous ne parvenez pas à consigner le paramètre audits de sécurité peut être très élevée, en particulier si vous activez également l’option Ne pas remplacer les événements (effacer le journal manuellement) pour le journal de sécurité. Ce paramètre fournit la responsabilité individuelle des actions de l’opérateur. Par exemple, un administrateur peut réinitialiser les autorisations sur tous les utilisateurs, ordinateurs et groupes d’une unité d’organisation où l’audit a été activé à l’aide du compte administrateur intégré ou d’un autre compte partagé, puis refuser de réinitialiser ces autorisations. Toutefois, l’activation du paramètre réduit la robustesse du système, car un serveur peut être forcé de s’arrêter en l’écrasant avec des événements d’ouverture de session et avec d’autres événements de sécurité écrits dans le journal de sécurité. En outre, étant donné que l’arrêt n’est pas approprié, des dommages irréparables au système d’exploitation, aux programmes ou aux données peuvent en résulter. Bien que NTFS garantisse que l’intégrité du système de fichiers est maintenue pendant un arrêt du système non graceful, il ne peut pas garantir que chaque fichier de données pour chaque programme sera toujours sous une forme utilisable lors du redémarrage du système.

   5. Nom symbolique :
      
      CrashOnAuditFail

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

   7. Exemples de problèmes de compatibilité

      • Windows 2000 : En raison d’un bogue, les ordinateurs qui exécutent la version d’origine publiée de Windows 2000, Windows 2000 SP1, Windows 2000 SP2 ou Windows Server SP3 peuvent arrêter la journalisation des événements avant que la taille spécifiée dans l’option Taille maximale du journal des événements de sécurité soit atteinte. Ce bogue est résolu dans Windows 2000 Service Pack 4 (SP4). Assurez-vous que Windows 2000 Service Pack 4 est installé sur vos contrôleurs de domaine Windows 2000 avant d’envisager d’activer ce paramètre.
        
         

      • Windows 2000, Windows Server 2003 : Les ordinateurs qui exécutent Windows 2000 ou Windows Server 2003 peuvent cesser de répondre, puis redémarrer spontanément si l’audit : Arrêter le système immédiatement si le paramètre d’audit de sécurité est activé, que le journal de sécurité est plein et qu’une entrée de journal des événements existante ne peut pas être remplacée. Lorsque l’ordinateur redémarre, le message d’erreur Arrêter suivant s’affiche :

        STOP : C0000244 {Audit Failed}
        Échec d’une tentative de génération d’un audit de sécurité.

        Pour récupérer, un administrateur doit ouvrir une session, archiver le journal de sécurité (facultatif), effacer le journal de sécurité, puis réinitialiser cette option (facultative et en fonction des besoins).

      • Microsoft Network Client pour MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003 : les non-administrateurs qui tentent de se connecter à un domaine recevront le message d’erreur suivant :

        Votre compte est configuré pour vous empêcher d’utiliser cet ordinateur. Veuillez essayer un autre ordinateur.

      • Windows 2000 : Sur les ordinateurs Windows 2000, les non-administrateurs ne pourront pas se connecter aux serveurs d’accès à distance et recevront un message d’erreur similaire à ce qui suit :

        Utilisateur inconnu ou mot de passe incorrect

      • Windows 2000 : Sur les contrôleurs de domaine Windows 2000, le service de messagerie intersite (Ismserv.exe) s’arrête et ne peut pas être redémarré. DCDIAG signale l’erreur en tant que « serveur ISMserv des services de test ayant échoué », et l’ID d’événement 1083 est inscrit dans le journal des événements.

      • Windows 2000 : Sur les contrôleurs de domaine Windows 2000, la réplication Active Directory échoue et un message « Accès refusé » s’affiche si le journal des événements de sécurité est plein.

      • Microsoft Exchange 2000 : Les serveurs qui exécutent Exchange 2000 ne pourront pas monter la base de données du magasin d’informations et l’événement 2102 sera inscrit dans le journal des événements.

      • Outlook, Outlook Web Access : les non-administrateurs ne pourront pas accéder à leur courrier électronique via Microsoft Outlook ou Microsoft Outlook Web Access, et ils recevront une erreur 503.

2. Contrôleur de domaine : exigences de signature de serveur LDAP

   1. Fond
      
      Le paramètre de sécurité des exigences de signature du serveur LDAP pour le contrôleur de domaine : détermine si le serveur LDAP (Lightweight Directory Access Protocol) exige que les clients LDAP négocient la signature des données. Les valeurs possibles pour ce paramètre de stratégie sont les suivantes :

      • Aucun : la signature de données n’est pas nécessaire pour établir une liaison avec le serveur. Si le client demande la signature des données, le serveur la prend en charge.

      • Exiger la signature : l’option de signature de données LDAP doit être négociée, sauf si TLS/SSL (Transport Layer Security/Secure Socket Layer) est utilisé.

      • non défini : ce paramètre n’est pas activé ou désactivé.

   2. Configurations risquées
      
      Voici les paramètres de configuration dangereux :

      • Activation de la signature Obligatoire dans les environnements où les clients ne prennent pas en charge la signature LDAP ou où la signature LDAP côté client n’est pas activée sur le client

      • Application du modèle de sécurité Windows 2000 ou Windows Server 2003 Hisecdc.inf dans les environnements où les clients ne prennent pas en charge la signature LDAP ou où la signature LDAP côté client n’est pas activée

      • Application du modèle de sécurité Windows 2000 ou Windows Server 2003 Hisecws.inf dans les environnements où les clients ne prennent pas en charge la signature LDAP ou où la signature LDAP côté client n’est pas activée

   3. Raisons d’activer ce paramètre
      
      Le trafic réseau non signé est vulnérable aux attaques de l’intercepteur, où un intrus capture les paquets entre le client et le serveur, modifie les paquets, puis les transfère au serveur. Lorsque ce comportement se produit sur un serveur LDAP, un attaquant peut amener un serveur à prendre des décisions basées sur de fausses requêtes du client LDAP. Vous pouvez réduire ce risque dans un réseau d’entreprise en implémentant des mesures de sécurité physiques fortes pour protéger l’infrastructure réseau. Le mode d’en-tête d’authentification IPSec (Internet Protocol Security) peut aider à empêcher les attaques de l’intercepteur. Le mode d’en-tête d’authentification effectue une authentification mutuelle et l’intégrité des paquets pour le trafic IP.

   4. Raisons de désactiver ce paramètre

      • Les clients qui ne prennent pas en charge la signature LDAP ne pourront pas effectuer de requêtes LDAP sur les contrôleurs de domaine et sur les catalogues globaux si l’authentification NTLM est négociée et si les service packs corrects ne sont pas installés sur les contrôleurs de domaine Windows 2000.

      • Les traces réseau du trafic LDAP entre les clients et les serveurs seront chiffrées. Il est donc difficile d’examiner les conversations LDAP.

      • Les serveurs Windows 2000 doivent avoir Windows 2000 Service Pack 3 (SP3) ou installés lorsqu’ils sont administrés avec des programmes qui prennent en charge la signature LDAP qui sont exécutés à partir d’ordinateurs clients exécutant Windows 2000 SP4, Windows XP ou Windows Server 2003.  

   5. Nom symbolique :
      
      LDAPServerIntegrity

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

   7. Exemples de problèmes de compatibilité

      • Les liaisons simples échouent et vous recevez le message d’erreur suivant :

        Ldap_simple_bind_s() a échoué : Authentification forte requise.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003 : Sur les clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003, certains outils d’administration Active Directory ne fonctionnent pas correctement sur les contrôleurs de domaine qui exécutent des versions de Windows 2000 antérieures à SP3 lorsque l’authentification NTLM est négociée.
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003 : Sur les clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003, certains outils d’administration Active Directory qui ciblent les contrôleurs de domaine qui exécutent des versions de Windows 2000 antérieures à SP3 ne fonctionnent pas correctement s’ils utilisent des adresses IP (par exemple, « dsa.msc /server=x.x.x.x » où
        x.x.x.x.x est une adresse IP).
        
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003 : Sur les clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003, certains outils d’administration Active Directory qui ciblent les contrôleurs de domaine qui exécutent des versions de Windows 2000 antérieures à SP3 ne fonctionnent pas correctement.
        
         

3. Membre de domaine : exiger une clé de session forte (Windows 2000 ou version ultérieure)

   1. Arrière-plan

      • Le membre de domaine : exiger un paramètre de clé de session fort (Windows 2000 ou version ultérieure) détermine si un canal sécurisé peut être établi avec un contrôleur de domaine qui ne peut pas chiffrer le trafic de canal sécurisé avec une clé de session forte et 128 bits. L’activation de ce paramètre empêche l’établissement d’un canal sécurisé avec un contrôleur de domaine qui ne peut pas chiffrer les données de canal sécurisées avec une clé forte. La désactivation de ce paramètre autorise les clés de session 64 bits.

      • Avant de pouvoir activer ce paramètre sur une station de travail membre ou sur un serveur, tous les contrôleurs de domaine du domaine auquel appartient le membre doivent être en mesure de chiffrer les données de canal sécurisées avec une clé forte de 128 bits. Cela signifie que tous ces contrôleurs de domaine doivent exécuter Windows 2000 ou version ultérieure.

   2. Configuration
      
      risquée Activation du membre de domaine : exiger un paramètre de clé de session fort (Windows 2000 ou version ultérieure) est un paramètre de configuration dangereux.

   3. Raisons d’activer ce paramètre

      • Les clés de session utilisées pour établir des communications de canal sécurisées entre les ordinateurs membres et les contrôleurs de domaine sont beaucoup plus puissantes dans Windows 2000 que dans les versions antérieures des systèmes d’exploitation Microsoft.

      • Quand c’est possible, il est judicieux de tirer parti de ces clés de session plus puissantes pour protéger les communications de canal sécurisées contre les écoutes clandestines et les attaques réseau de détournement de session. L’écoute clandestine est une forme d’attaque malveillante où les données réseau sont lues ou modifiées en transit. Les données peuvent être modifiées pour masquer ou modifier l’expéditeur, ou pour les rediriger.

      Important Un ordinateur exécutant Windows Server 2008 R2 ou Windows 7 prend en charge uniquement les clés fortes lorsque des canaux sécurisés sont utilisés. Cette restriction empêche une approbation entre n’importe quel domaine Windows NT 4.0 et n’importe quel domaine Windows Server 2008 R2. En outre, cette restriction bloque l’appartenance au domaine Windows NT 4.0 des ordinateurs exécutant Windows 7 ou Windows Server 2008 R2, et inversement.

   4. Raisons de désactiver ce paramètre
      
      Le domaine contient des ordinateurs membres qui exécutent des systèmes d’exploitation autres que Windows 2000, Windows XP ou Windows Server 2003.

   5. Nom symbolique :
      
      StrongKey

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

   7. Exemples de problèmes
      
      de compatibilité Windows NT 4.0 : Sur les ordinateurs Windows NT 4.0, la réinitialisation des canaux sécurisés de relations d’approbation entre les domaines Windows NT 4.0 et Windows 2000 avec NLTEST échoue. Un message d’erreur « Accès refusé » s’affiche :

      La relation d’approbation entre le domaine principal et le domaine approuvé a échoué.
      
      Windows 7 et Server 2008 R2 : pour Windows 7 et versions ultérieures et Windows Server 2008 R2 et versions ultérieures, ce paramètre n’est plus respecté et la clé forte est toujours utilisée. Pour cette raison, les approbations avec les domaines Windows NT 4.0 ne fonctionnent plus.

4. Membre de domaine : chiffrer numériquement ou signer des données de canal sécurisées (toujours)

   1. Arrière-plan

      • Activation du membre de domaine : chiffrer ou signer numériquement des données de canal sécurisé (toujours) empêche l’établissement d’un canal sécurisé avec n’importe quel contrôleur de domaine qui ne peut pas signer ou chiffrer toutes les données de canal sécurisé. Pour protéger le trafic d’authentification contre les attaques de l’intercepteur, les attaques par relecture et d’autres types d’attaques réseau, les ordinateurs Windows créent un canal de communication appelé canal sécurisé via le service Net Logon pour authentifier les comptes d’ordinateur. Les canaux sécurisés sont également utilisés lorsqu’un utilisateur d’un domaine se connecte à une ressource réseau dans un domaine distant. Cette authentification multimain, ou authentification directe, permet à un ordinateur Windows qui a joint un domaine d’accéder à la base de données du compte d’utilisateur dans son domaine et dans tous les domaines approuvés.

      • Pour activer le membre de domaine : Chiffrer numériquement ou signer le paramètre de données de canal sécurisé (toujours) sur un ordinateur membre, tous les contrôleurs de domaine du domaine auquel appartient le membre doivent être en mesure de signer ou de chiffrer toutes les données de canal sécurisées. Cela signifie que tous ces contrôleurs de domaine doivent exécuter Windows NT 4.0 avec Service Pack 6a (SP6a) ou version ultérieure.

      • L’activation du membre de domaine : chiffrer numériquement ou signer le paramètre de données de canal sécurisé (toujours) active automatiquement le membre de domaine : chiffrer numériquement ou signer le paramètre de données de canal sécurisé (lorsque cela est possible).

   2. Configuration
      
      risquée Activation du membre de domaine : Chiffrer ou signer numériquement le paramètre de données de canal sécurisé (toujours) dans les domaines où tous les contrôleurs de domaine ne peuvent pas signer ou chiffrer des données de canal sécurisées n’est pas un paramètre de configuration dangereux.

   3. Raisons d’activer ce paramètre
      
      Le trafic réseau non signé est vulnérable aux attaques de l’intercepteur, où un intrus capture les paquets entre le serveur et le client, puis les modifie avant de les transférer au client. Lorsque ce comportement se produit sur un serveur LDAP (Lightweight Directory Access Protocol), l’intrus peut amener un client à prendre des décisions basées sur de faux enregistrements du répertoire LDAP. Vous pouvez réduire le risque d’une telle attaque sur un réseau d’entreprise en implémentant des mesures de sécurité physique fortes pour protéger l’infrastructure réseau. En outre, l’implémentation du mode d’en-tête d’authentification IPSec (Internet Protocol Security) peut aider à empêcher les attaques de l’intercepteur. Ce mode effectue l’authentification mutuelle et l’intégrité des paquets pour le trafic IP.

   4. Raisons de désactiver ce paramètre

      • Les ordinateurs de domaines locaux ou externes prennent en charge les canaux sécurisés chiffrés.

      • Tous les contrôleurs de domaine du domaine n’ont pas les niveaux de révision de Service Pack appropriés pour prendre en charge les canaux sécurisés chiffrés.

   5. Nom symbolique :
      
      StrongKey

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

   7. Exemples de problèmes de compatibilité

      • Windows NT 4.0 : Les ordinateurs membres Windows 2000 ne pourront pas joindre les domaines Windows NT 4.0 et recevront le message d’erreur suivant :

        Le compte n’est pas autorisé à se connecter à partir de cette station.

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

        281648 Message d’erreur : Le compte n’est pas autorisé à se connecter à partir de cette station
         

      • Windows NT 4.0 : Les domaines Windows NT 4.0 ne seront pas en mesure d’établir une approbation de niveau inférieur avec un domaine Windows 2000 et recevront le message d’erreur suivant :

        Le compte n’est pas autorisé à se connecter à partir de cette station.

        Les approbations de bas niveau existantes peuvent également ne pas authentifier les utilisateurs à partir du domaine approuvé. Certains utilisateurs peuvent rencontrer des problèmes pour se connecter au domaine, et ils peuvent recevoir un message d’erreur indiquant que le client ne trouve pas le domaine.

      • Windows XP : les clients Windows XP joints à des domaines Windows NT 4.0 ne pourront pas authentifier les tentatives d’ouverture de session et peuvent recevoir le message d’erreur suivant, ou les événements suivants peuvent être inscrits dans le journal des événements :

        Windows ne peut pas se connecter au domaine, soit parce que le contrôleur de domaine est arrêté, soit parce qu’il n’est pas disponible ou parce que votre compte d’ordinateur est introuvable

      • Microsoft Network : Les clients Microsoft Network recevront l’un des messages d’erreur suivants :

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

        Il n’existe aucune clé de session utilisateur pour la session d’ouverture de session spécifiée.

5. Client réseau Microsoft : Signer numériquement les communications (toujours)

   1. Fond
      
      Le protocole SMB (Server Message Block) est le protocole de partage des ressources pris en charge par de nombreux systèmes d’exploitation Microsoft. Il s’agit de la base du système d’entrée/sortie de base du réseau (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie à la fois l’utilisateur et le serveur qui héberge les données. Si l’un des deux côtés échoue au processus d’authentification, la transmission des données ne se produit pas.
      
      L’activation de la signature SMB démarre pendant la négociation du protocole SMB. Les stratégies de signature SMB déterminent si l’ordinateur signe toujours numériquement les communications client.
      
      Le protocole d’authentification SMB Windows 2000 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme une attaque « man-in-the-middle ». Le protocole d’authentification SMB Windows 2000 prend également en charge l’authentification par message. L’authentification des messages permet d’éviter les attaques de messages actives. Pour vous fournir cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur vérifient chacun la signature numérique.
      
      Pour utiliser la signature SMB, vous devez activer la signature SMB ou exiger la signature SMB sur le client SMB et le serveur SMB. Si la signature SMB est activée sur un serveur, les clients qui sont également activés pour la signature SMB utilisent le protocole de signature de paquets pendant toutes les sessions suivantes. Si la signature SMB est requise sur un serveur, un client ne peut pas établir de session, sauf si le client est activé ou requis pour la signature SMB.
      
      
      L’activation de la connexion numérique dans les réseaux à haute sécurité permet d’éviter l’emprunt d’identité des clients et des serveurs. Ce type d’emprunt d’identité est appelé détournement de session. Un attaquant qui a accès au même réseau que le client ou le serveur utilise des outils de détournement de session pour interrompre, terminer ou voler une session en cours. Un attaquant peut intercepter et modifier des paquets SMB non signés, modifier le trafic, puis le transférer afin que le serveur puisse effectuer des actions indésirables. Ou bien, l’attaquant peut se présenter comme le serveur ou le client après une authentification légitime, puis obtenir un accès non autorisé aux données.
      
      Le protocole SMB utilisé pour le partage de fichiers et le partage d’impression sur les ordinateurs exécutant Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme les attaques de détournement de session et prend en charge l’authentification par message. Par conséquent, il empêche les attaques de l’intercepteur. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur vérifient ensuite la signature.
      
      Notes

      • En guise de contre-mesure alternative, vous pouvez activer les signatures numériques avec IPSec pour protéger tout le trafic réseau. Il existe des accélérateurs matériels pour le chiffrement et la signature IPSec que vous pouvez utiliser pour réduire l’impact sur les performances du processeur du serveur. Aucun de ces accélérateurs n’est disponible pour la signature SMB.
        
        Pour plus d’informations, consultez le chapitre Communications du serveur de signature numérique sur le site web Microsoft MSDN.
        
        Configurez la signature SMB via stratégie de groupe’Éditeur d’objets, car une modification apportée à une valeur de Registre local n’a aucun effet s’il existe une stratégie de domaine de substitution.

      • Dans Windows 95, Windows 98 et Windows 98 Second Edition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB de ces clients. Pour plus d’informations, consultez l’élément 10 : « Sécurité réseau : niveau d’authentification Lan Manager ».

   2. Configuration
      
      risquée Voici un paramètre de configuration dangereux : quitter le client réseau Microsoft : signer numériquement le paramètre de communications (toujours) et le client réseau Microsoft : Signer numériquement les communications (si le serveur est d’accord) défini sur « Non défini » ou désactivé. Ces paramètres permettent au redirecteur d’envoyer des mots de passe en texte brut à des serveurs SMB non-Microsoft qui ne prennent pas en charge le chiffrement de mot de passe pendant l’authentification.

   3. Raisons d’activer ce paramètre
      
      Activation du client réseau Microsoft : La signature numérique des communications (toujours) oblige les clients à signer le trafic SMB lors du contact avec des serveurs qui ne nécessitent pas de signature SMB. Cela rend les clients moins vulnérables aux attaques de détournement de session.

   4. Raisons de désactiver ce paramètre

      • Activation du client réseau Microsoft : la signature numérique des communications (toujours) empêche les clients de communiquer avec les serveurs cibles qui ne prennent pas en charge la signature SMB.

      • La configuration des ordinateurs pour ignorer toutes les communications SMB non signées empêche les programmes et systèmes d’exploitation antérieurs de se connecter.

   5. Nom symbolique :
      
      RequireSMBSignRdr

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

   7. Exemples de problèmes de compatibilité

      • Windows NT 4.0 : vous ne pourrez pas réinitialiser le canal sécurisé d’une approbation entre un domaine Windows Server 2003 et un domaine Windows NT 4.0 à l’aide de NLTEST ou NETDOM, et vous recevrez un message d’erreur « Accès refusé ».

      • Windows XP : la copie de fichiers à partir de clients Windows XP vers des serveurs Windows 2000 et vers des serveurs Windows Server 2003 peut prendre plus de temps.

      • Vous ne pourrez pas mapper un lecteur réseau à partir d’un client avec ce paramètre activé, et vous recevrez le message d’erreur suivant :

        Le compte n’est pas autorisé à se connecter à partir de cette station.

   8. Exigences de
      
      redémarrage Redémarrez l’ordinateur ou redémarrez le service station de travail. Pour ce faire, tapez les commandes suivantes à l’invite de commandes. Appuyez sur Entrée après avoir tapé chaque commande.

      station de travail
      d’arrêt net station de travail net start

6. Serveur réseau Microsoft : Signer numériquement les communications (toujours)

   1. Arrière-plan

      • Server Messenger Block (SMB) est le protocole de partage des ressources pris en charge par de nombreux systèmes d’exploitation Microsoft. Il s’agit de la base du système d’entrée/sortie de base du réseau (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie à la fois l’utilisateur et le serveur qui héberge les données. Si l’un des deux côtés échoue au processus d’authentification, la transmission des données ne se produit pas.
        
        L’activation de la signature SMB démarre pendant la négociation du protocole SMB. Les stratégies de signature SMB déterminent si l’ordinateur signe toujours numériquement les communications client.
        
        Le protocole d’authentification SMB Windows 2000 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme une attaque « man-in-the-middle ». Le protocole d’authentification SMB Windows 2000 prend également en charge l’authentification par message. L’authentification des messages permet d’éviter les attaques de messages actives. Pour vous fournir cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur vérifient chacun la signature numérique.
        
        Pour utiliser la signature SMB, vous devez activer la signature SMB ou exiger la signature SMB sur le client SMB et le serveur SMB. Si la signature SMB est activée sur un serveur, les clients qui sont également activés pour la signature SMB utilisent le protocole de signature de paquets pendant toutes les sessions suivantes. Si la signature SMB est requise sur un serveur, un client ne peut pas établir de session, sauf si le client est activé ou requis pour la signature SMB.
        
        
        L’activation de la connexion numérique dans les réseaux à haute sécurité permet d’éviter l’emprunt d’identité des clients et des serveurs. Ce type d’emprunt d’identité est appelé détournement de session. Un attaquant qui a accès au même réseau que le client ou le serveur utilise des outils de détournement de session pour interrompre, terminer ou voler une session en cours. Un attaquant peut intercepter et modifier des paquets SBM (Subnet Bandwidth Manager) non signés, modifier le trafic, puis le transférer afin que le serveur puisse effectuer des actions indésirables. Ou bien, l’attaquant peut se présenter comme le serveur ou le client après une authentification légitime, puis obtenir un accès non autorisé aux données.
        
        Le protocole SMB utilisé pour le partage de fichiers et le partage d’impression sur les ordinateurs exécutant Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme les attaques de détournement de session et prend en charge l’authentification par message. Par conséquent, il empêche les attaques de l’intercepteur. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur vérifient ensuite la signature.

      • En guise de contre-mesure alternative, vous pouvez activer les signatures numériques avec IPSec pour protéger tout le trafic réseau. Il existe des accélérateurs matériels pour le chiffrement et la signature IPSec que vous pouvez utiliser pour réduire l’impact sur les performances du processeur du serveur. Aucun de ces accélérateurs n’est disponible pour la signature SMB.

      • Dans Windows 95, Windows 98 et Windows 98 Second Edition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB de ces clients. Pour plus d’informations, consultez l’élément 10 : « Sécurité réseau : niveau d’authentification Lan Manager ».

   2. Configuration
      
      risquée Voici un paramètre de configuration dangereux : activation du serveur réseau Microsoft : signer numériquement le paramètre de communications (toujours) sur les serveurs et sur les contrôleurs de domaine accessibles par des ordinateurs Windows incompatibles et des ordinateurs clients tiers basés sur le système d’exploitation dans des domaines locaux ou externes.

   3. Raisons d’activer ce paramètre

      • Tous les ordinateurs clients qui activent ce paramètre directement via le Registre ou le paramètre stratégie de groupe prennent en charge la signature SMB. En d’autres termes, tous les ordinateurs clients pour lesquels ce paramètre est activé exécutent Windows 95 avec le client DS installé, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professionnel ou Windows Server 2003.

      • Si le serveur réseau Microsoft : Les communications de signature numérique (toujours) sont désactivées, la signature SMB est complètement désactivée. La désactivation complète de toutes les signatures SMB rend les ordinateurs plus vulnérables aux attaques de détournement de session.

   4. Raisons de désactiver ce paramètre

      • L’activation de ce paramètre peut entraîner un ralentissement de la copie des fichiers et des performances réseau sur les ordinateurs clients.

      • L’activation de ce paramètre empêche les clients qui ne peuvent pas négocier la signature SMB de communiquer avec les serveurs et les contrôleurs de domaine. Cela entraîne l’échec d’opérations telles que les jointures de domaine, l’authentification utilisateur et ordinateur ou l’accès réseau par les programmes.

   5. Nom symbolique :
      
      RequireSMBSignServer

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

   7. Exemples de problèmes de compatibilité

      • Windows 95 : Les clients Windows 95 qui n’ont pas installé le client DS (Directory Services) échouent à l’authentification par ouverture de session et reçoivent le message d’erreur suivant :

        Le mot de passe de domaine que vous avez fourni n’est pas correct ou l’accès à votre serveur d’ouverture de session a été refusé.

      • Windows NT 4.0 : Les ordinateurs clients qui exécutent des versions de Windows NT 4.0 antérieures à Service Pack 3 (SP3) échouent à l’authentification par ouverture de session et reçoivent le message d’erreur suivant :

        Le système n’a pas pu vous connecter. Assurez-vous que votre nom d’utilisateur et votre domaine sont corrects, puis tapez à nouveau votre mot de passe.

        Certains serveurs SMB non-Microsoft prennent en charge uniquement les échanges de mots de passe non chiffrés pendant l’authentification. (Ces échanges sont également appelés échanges en texte brut.) Pour Windows NT 4.0 SP3 et versions ultérieures, le redirecteur SMB n’envoie pas de mot de passe non chiffré pendant l’authentification à un serveur SMB, sauf si vous ajoutez une entrée de Registre spécifique.
        Pour activer les mots de passe non chiffrés pour le client SMB sur Windows NT 4.0 SP 3 et les systèmes plus récents, modifiez le registre comme suit : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        
        Nom de la valeur : EnablePlainTextPassword
        
        Type de données : REG_DWORD
        
        Données : 1
        
         

      • Windows Server 2003 : Par défaut, les paramètres de sécurité sur les contrôleurs de domaine qui exécutent Windows Server 2003 sont configurés pour empêcher les communications des contrôleurs de domaine d’être interceptées ou falsifiées par des utilisateurs malveillants. Pour que les utilisateurs communiquent correctement avec un contrôleur de domaine qui exécute Windows Server 2003, les ordinateurs clients doivent utiliser à la fois la signature SMB et le chiffrement ou la signature du trafic de canal sécurisé. Par défaut, les clients qui exécutent Windows NT 4.0 avec Service Pack 2 (SP2) ou version antérieure installée et les clients qui exécutent Windows 95 n’ont pas activé la signature de paquets SMB. Par conséquent, ces clients peuvent ne pas être en mesure de s’authentifier auprès d’un contrôleur de domaine Windows Server 2003.

      • Paramètres de stratégie Windows 2000 et Windows Server 2003 : en fonction de vos besoins d’installation et de votre configuration spécifiques, nous vous recommandons de définir les paramètres de stratégie suivants à l’entité la plus basse de l’étendue nécessaire dans la hiérarchie de composant logiciel enfichable Microsoft Management Console stratégie de groupe Editor :

        • Configuration de l’ordinateur\paramètres Sécurité Windows\Options de sécurité

        • Envoyer un mot de passe non chiffré pour se connecter à des serveurs SMB tiers (ce paramètre concerne Windows 2000)

        • Client réseau Microsoft : envoyer un mot de passe non chiffré à des serveurs SMB tiers (ce paramètre concerne Windows Server 2003)

        
        Remarque Dans certains serveurs CIFS tiers, comme les versions antérieures de Samba, vous ne pouvez pas utiliser de mots de passe chiffrés.

      • Les clients suivants ne sont pas compatibles avec le serveur réseau Microsoft : paramètre de communication de signature numérique (toujours) :

        • Apple Computer, Inc., clients Mac OS X

        • Clients réseau Microsoft MS-DOS (par exemple, Microsoft LAN Manager)

        • Clients Microsoft Windows for Workgroups

        • Clients Microsoft Windows 95 sans le client DS installé

        • Ordinateurs Microsoft Windows NT 4.0 sans SP3 ou version ultérieure installé

        • Clients CIFS Novell Netware 6

        • Clients SAMBA SMB qui ne prennent pas en charge la signature SMB

   8. Exigences de
      
      redémarrage Redémarrez l’ordinateur ou redémarrez le service Serveur. Pour ce faire, tapez les commandes suivantes à l’invite de commandes. Appuyez sur Entrée après avoir tapé chaque commande.

      net stop server
      serveur de démarrage net

7. Accès réseau : Autoriser la traduction anonyme de SID/Name

   1. Fond
      
      L’accès réseau : autoriser le paramètre de sécurité de traduction sid/nom anonyme détermine si un utilisateur anonyme peut demander des attributs SID (Security Identification Number) pour un autre utilisateur.

   2. Configuration
      
      risquée Activation de l’accès réseau : autoriser le paramètre de traduction sid/nom anonyme est un paramètre de configuration dangereux.

   3. Raisons d’activer ce paramètre
      
      Si l’accès réseau : autoriser le paramètre de traduction sid/nom anonyme est désactivé, les systèmes d’exploitation ou applications antérieurs peuvent ne pas être en mesure de communiquer avec les domaines Windows Server 2003. Par exemple, les systèmes d’exploitation, services ou applications suivants peuvent ne pas fonctionner :

      • Serveurs du service d’accès à distance windows NT 4.0

      • Microsoft SQL Server qui s’exécutent sur des ordinateurs Windows NT 3.x ou windows NT 4.0

      • Service d’accès à distance qui s’exécute sur des ordinateurs Windows 2000 situés dans des domaines Windows NT 3.x ou Windows NT 4.0

      • SQL Server qui s’exécute sur des ordinateurs Windows 2000 situés dans des domaines Windows NT 3.x ou dans des domaines Windows NT 4.0

      • Utilisateurs du domaine de ressources Windows NT 4.0 qui souhaitent accorder des autorisations d’accès aux fichiers, dossiers partagés et objets de Registre aux comptes d’utilisateur à partir de domaines de compte qui contiennent des contrôleurs de domaine Windows Server 2003

   4. Raisons de désactiver ce paramètre
      
      Si ce paramètre est activé, un utilisateur malveillant peut utiliser le SID Administrateurs connu pour obtenir le nom réel du compte Administrateur intégré, même si le compte a été renommé. Cette personne peut ensuite utiliser le nom du compte pour lancer une attaque de devinettes de mot de passe.

   5. Nom symbolique : N/A

   6. Chemin du Registre : Aucun. Le chemin d’accès est spécifié dans le code de l’interface utilisateur.

   7. Exemples de problèmes
      
      de compatibilité Windows NT 4.0 : Les ordinateurs dans les domaines de ressources Windows NT 4.0 affichent le message d’erreur « Compte inconnu » dans l’éditeur ACL si les ressources, y compris les dossiers partagés, les fichiers partagés et les objets de Registre, sont sécurisées avec des principaux de sécurité qui résident dans des domaines de compte qui contiennent des contrôleurs de domaine Windows Server 2003.

8. Accès réseau : n’autorisez pas l’énumération anonyme des comptes SAM

   1. Arrière-plan

      • Accès réseau : n’autorisez pas l’énumération anonyme du paramètre de comptes SAM pour déterminer quelles autorisations supplémentaires seront accordées pour les connexions anonymes à l’ordinateur. Windows permet aux utilisateurs anonymes d’effectuer certaines activités, telles que l’énumération des noms des comptes SAM (Workstation and Server Security Accounts Manager) et des partages réseau. Par exemple, un administrateur peut l’utiliser pour accorder l’accès aux utilisateurs d’un domaine approuvé qui ne maintient pas une confiance réciproque. Une fois qu’une session est effectuée, un utilisateur anonyme peut avoir le même accès que celui accordé au groupe Tout le monde en fonction du paramètre dans l’accès réseau : autoriser tout le monde à s’appliquer au paramètre utilisateurs anonymes ou à la liste de contrôle d’accès discrétionnaire (DACL) de l’objet.
        
        En règle générale, les connexions anonymes sont demandées par les versions antérieures des clients (clients de bas niveau) lors de la configuration de session SMB. Dans ces cas, une trace réseau montre que l’ID de processus SMB (PID) est le redirecteur client tel que 0xFEFF dans Windows 2000 ou 0xCAFE dans Windows NT. RPC peut également essayer d’établir des connexions anonymes.

      • Important Ce paramètre n’a aucun impact sur les contrôleurs de domaine. Sur les contrôleurs de domaine, ce comportement est contrôlé par la présence de « NT AUTHORITY\ANONYMOUS LOGON » dans « Accès compatible pré-Windows 2000 ».

      • Dans Windows 2000, un paramètre similaire appelé Restrictions supplémentaires pour les connexions anonymes gère la valeur de Registre RestrictAnonymous . L’emplacement de cette valeur est le suivant :

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

   2. Configurations risquées
      
      Activation de l’accès réseau : Ne pas autoriser l’énumération anonyme du paramètre de comptes SAM est un paramètre de configuration dangereux du point de vue de la compatibilité. La désactivation est un paramètre de configuration dangereux du point de vue de la sécurité.

   3. Raisons d’activer ce paramètre
      
      Un utilisateur non autorisé peut répertorier anonymement les noms de comptes, puis utiliser les informations pour essayer de deviner les mots de passe ou pour effectuer des attaques d’ingénierie sociale. L’ingénierie sociale est un jargon qui consiste à inciter les gens à révéler leurs mots de passe ou une certaine forme d’informations de sécurité.

   4. Raisons de désactiver ce paramètre
      
      Si ce paramètre est activé, il est impossible d’établir des approbations avec des domaines Windows NT 4.0. Ce paramètre entraîne également des problèmes avec les clients de bas niveau (tels que les clients Windows NT 3.51 et les clients Windows 95) qui tentent d’utiliser des ressources sur le serveur.

   5. Nom symbolique :
      
      
      RestrictAnonymousSAM

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

   7. Exemples de problèmes de compatibilité

   • La découverte du réseau SMS ne pourra pas obtenir d’informations sur le système d’exploitation et écrit « Inconnu » dans la propriété OperatingSystemNameandVersion.

   • Windows 95, Windows 98 : Les clients Windows 95 et Windows 98 ne pourront pas modifier leurs mots de passe.

   • Windows NT 4.0 : les ordinateurs membres Windows NT 4.0 ne pourront pas être authentifiés.

   • Windows 95, Windows 98 : Les ordinateurs Windows 95 et Windows 98 ne pourront pas être authentifiés par les contrôleurs de domaine Microsoft.

   • Windows 95, Windows 98 : les utilisateurs sur les ordinateurs Windows 95 et Windows 98 ne pourront pas modifier les mots de passe de leurs comptes d’utilisateur.

9. Accès réseau : n’autorisez pas l’énumération anonyme des comptes et partages SAM

   1. Arrière-plan

      • L’accès réseau : n’autorisez pas l’énumération anonyme des comptes et partages SAM (également appelé RestrictAnonymous) détermine si l’énumération anonyme des comptes et partages sam (Security Accounts Manager) est autorisée. Windows permet aux utilisateurs anonymes d’effectuer certaines activités, telles que l’énumération des noms de comptes de domaine (utilisateurs, ordinateurs et groupes) et des partages réseau. Cela est pratique, par exemple, lorsqu’un administrateur souhaite accorder l’accès aux utilisateurs d’un domaine approuvé qui ne maintient pas une confiance réciproque. Si vous ne souhaitez pas autoriser l’énumération anonyme des comptes SAM et des partages, activez ce paramètre.

      • Dans Windows 2000, un paramètre similaire appelé Restrictions supplémentaires pour les connexions anonymes gère la valeur de Registre RestrictAnonymous . L’emplacement de cette valeur est le suivant :

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Configuration
      
      risquée Activation de l’accès réseau : ne pas autoriser l’énumération anonyme des comptes SAM et des paramètres de partages est un paramètre de configuration dangereux.

   3. Raisons d’activer ce paramètre

      • Activation de l’accès réseau : n’autorisez pas l’énumération anonyme des comptes sam et des paramètres de partages pour empêcher l’énumération des comptes et partages SAM par les utilisateurs et les ordinateurs qui utilisent des comptes anonymes.

   4. Raisons de désactiver ce paramètre

      • Si ce paramètre est activé, un utilisateur non autorisé peut répertorier anonymement les noms de compte, puis utiliser les informations pour essayer de deviner les mots de passe ou d’effectuer des attaques d’ingénierie sociale. L’ingénierie sociale est un jargon qui consiste à inciter les gens à révéler leur mot de passe ou une forme quelconque d’informations de sécurité.

      • Si ce paramètre est activé, il sera impossible d’établir des approbations avec des domaines Windows NT 4.0. Ce paramètre entraîne également des problèmes avec les clients de bas niveau tels que les clients Windows NT 3.51 et Windows 95 qui tentent d’utiliser des ressources sur le serveur.

      • Il sera impossible d’accorder l’accès aux utilisateurs de domaines de ressources, car les administrateurs du domaine d’approbation ne pourront pas énumérer les listes de comptes dans l’autre domaine. Les utilisateurs qui accèdent aux serveurs de fichiers et d’impression de manière anonyme ne peuvent pas répertorier les ressources réseau partagées sur ces serveurs. Les utilisateurs doivent s’authentifier avant de pouvoir afficher les listes de dossiers partagés et d’imprimantes.

   5. Nom symbolique :
      
      RestrictAnonymous

   6. Chemin d’accès au Registre :

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

   7. Exemples de problèmes de compatibilité

      • Windows NT 4.0 : les utilisateurs ne pourront pas modifier leurs mots de passe à partir des stations de travail Windows NT 4.0 lorsque RestrictAnonymous est activé sur les contrôleurs de domaine dans le domaine des utilisateurs.

      • Windows NT 4.0 : L’ajout d’utilisateurs ou de groupes globaux à partir de domaines Windows 2000 approuvés à des groupes locaux Windows NT 4.0 dans Le Gestionnaire d’utilisateurs échoue et le message d’erreur suivant s’affiche :

        Aucun serveur d’ouverture de session n’est actuellement disponible pour traiter la demande d’ouverture de session.

      • Windows NT 4.0 : les ordinateurs Windows NT 4.0 ne pourront pas joindre des domaines pendant l’installation ou à l’aide de l’interface utilisateur de jonction de domaine.

      • Windows NT 4.0 : l’établissement d’une approbation de bas niveau avec les domaines de ressources Windows NT 4.0 échoue. Le message d’erreur suivant s’affiche lorsque RestrictAnonymous est activé sur le domaine approuvé :

        Impossible de trouver le contrôleur de domaine pour ce domaine.

      • Windows NT 4.0 : les utilisateurs qui se connectent aux ordinateurs Terminal Server windows NT 4.0 sont mappés au répertoire de base par défaut au lieu du répertoire de base défini dans Le Gestionnaire d’utilisateurs pour les domaines.

      • Windows NT 4.0 : les contrôleurs de domaine de sauvegarde Windows NT 4.0 ne pourront pas démarrer le service Net Logon, obtenir une liste des navigateurs de sauvegarde ou synchroniser la base de données SAM à partir de Windows 2000 ou de contrôleurs de domaine Windows Server 2003 dans le même domaine.

      • Windows 2000 : Les ordinateurs membres Windows 2000 dans les domaines Windows NT 4.0 ne pourront pas afficher les imprimantes dans des domaines externes si le paramètre Aucun accès sans autorisations explicitement anonymes est activé dans la stratégie de sécurité locale de l’ordinateur client.

      • Windows 2000 : les utilisateurs du domaine Windows 2000 ne pourront pas ajouter d’imprimantes réseau à partir d’Active Directory; toutefois, ils pourront ajouter des imprimantes après les avoir sélectionnées dans l’arborescence.

      • Windows 2000 : Sur les ordinateurs Windows 2000, L’éditeur ACL ne peut pas ajouter d’utilisateurs ou de groupes globaux à partir de domaines Windows NT 4.0 approuvés.

      • ADMT version 2 : La migration de mot de passe pour les comptes d’utilisateur qui sont migrés entre des forêts avec l’outil de migration Active Directory (ADMT) version 2 échoue.
        
        Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

        322981 Comment résoudre les problèmes de migration de mot de passe inter-forêts avec ADMTv2

      • Clients Outlook : la liste d’adresses globale apparaît vide pour les clients Microsoft Exchange Outlook.

      • SMS : La découverte réseau de Microsoft Systems Management Server (SMS) ne pourra pas obtenir les informations du système d’exploitation. Par conséquent, il écrit « Unknown » dans la propriété OperatingSystemNameandVersion de la propriété SMS DDR de l’enregistrement de données de découverte (DDR).

      • SMS : lorsque vous utilisez l’Assistant Utilisateur administrateur SMS pour rechercher des utilisateurs et des groupes, aucun utilisateur ou groupe n’est répertorié. En outre, les clients avancés ne peuvent pas communiquer avec le point de gestion. Un accès anonyme est requis sur le point de gestion.

      • SMS : lorsque vous utilisez la fonctionnalité de découverte de réseau dans SMS 2.0 et dans l’installation du client distant avec l’option de découverte réseau topologie, client et client activée, les ordinateurs peuvent être découverts, mais pas installés.

10. Sécurité réseau : niveau d’authentification Lan Manager

    1. Fond
       
       L’authentification LAN Manager (LM) est le protocole utilisé pour authentifier les clients Windows pour les opérations réseau, notamment les jointures de domaine, l’accès aux ressources réseau et l’authentification utilisateur ou ordinateur. Le niveau d’authentification LM détermine le protocole d’authentification challenge/réponse qui est négocié entre le client et les ordinateurs serveur. Plus précisément, le niveau d’authentification LM détermine les protocoles d’authentification que le client tentera de négocier ou que le serveur acceptera. La valeur définie pour LmCompatibilityLevel détermine le protocole d’authentification de défi/réponse utilisé pour les logons réseau. Cette valeur affecte le niveau de protocole d’authentification utilisé par les clients, le niveau de sécurité de session négocié et le niveau d’authentification accepté par les serveurs.
       
       Les paramètres possibles sont les suivants.

       Valeur	Paramètre	Description
       0	Envoyer des réponses LM & NTLM	Les clients utilisent l’authentification LM et NTLM et n’utilisent jamais la sécurité de session NTLMv2. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
       1	Envoyer LM & NTLM - utiliser la sécurité de session NTLMv2 si elle est négociée	Les clients utilisent l’authentification LM et NTLM, et la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
       2	Envoyer une réponse NTLM uniquement	Les clients utilisent l’authentification NTLM uniquement et la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
       3	Envoyer la réponse NTLMv2 uniquement	Les clients utilisent l’authentification NTLMv2 uniquement et la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
       4	Envoyer la réponse NTLMv2 uniquement/refuser LM	Les clients utilisent l’authentification NTLMv2 uniquement et la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent LM et acceptent uniquement l’authentification NTLM et NTLMv2.
       5	Envoyer la réponse NTLMv2 uniquement/refuser LM & NTLM	Les clients utilisent l’authentification NTLMv2 uniquement et la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent LM et NTLM et acceptent uniquement l’authentification NTLMv2.

       Remarque Dans Windows 95, Windows 98 et Windows 98 Second Edition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB de ces clients.
       
       Vérifiez le niveau d’authentification LM : vous devez modifier la stratégie sur le serveur pour autoriser NTLM ou configurer l’ordinateur client pour prendre en charge NTLMv2.
       
       Si la stratégie est définie sur (5) Envoyer la réponse NTLMv2 uniquement\refuser LM & NTLM sur l’ordinateur cible auquel vous souhaitez vous connecter, vous devez soit abaisser le paramètre sur cet ordinateur, soit définir la sécurité sur le même paramètre que celui de l’ordinateur source à partir duquel vous vous connectez.
       
       Recherchez l’emplacement approprié où vous pouvez modifier le niveau d’authentification du gestionnaire LAN pour définir le client et le serveur sur le même niveau. Une fois que vous avez trouvé la stratégie qui définit le niveau d’authentification du gestionnaire LAN, si vous souhaitez vous connecter aux ordinateurs qui exécutent des versions antérieures de Windows, réduisez la valeur à au moins (1) Envoyer LM & NTLM : utilisez la sécurité de session NTLM version 2 si elle est négociée. Un effet des paramètres incompatibles est que si le serveur requiert NTLMv2 (valeur 5), mais que le client est configuré pour utiliser LM et NTLMv1 uniquement (valeur 0), l’utilisateur qui tente l’authentification rencontre un échec d’ouverture de session qui a un mot de passe incorrect et qui incrémente le nombre de mots de passe incorrects. Si le verrouillage de compte est configuré, l’utilisateur peut éventuellement être verrouillé.
       
       Par exemple, vous devrez peut-être examiner le contrôleur de domaine ou examiner les stratégies du contrôleur de domaine.
       
       Rechercher sur le contrôleur
       
       de domaine Notez que vous devrez peut-être répéter la procédure suivante sur tous les contrôleurs de domaine.

       1. Cliquez sur Démarrer, pointez sur Programmes, puis cliquez sur Outils d’administration.

       2. Sous Paramètres de sécurité locaux, développez stratégies locales.

       3. Cliquez sur Options de sécurité.

       4. Double-cliquez sur Sécurité réseau : niveau d’authentification du gestionnaire LAN, puis cliquez sur une valeur dans la liste.

       
       Si le paramètre effectif et le paramètre local sont identiques, la stratégie a été modifiée à ce niveau. Si les paramètres sont différents, vous devez vérifier la stratégie du contrôleur de domaine pour déterminer si le paramètre de niveau d’authentification Network Security: LAN Manager y est défini. S’il n’y est pas défini, examinez les stratégies du contrôleur de domaine.
       
       Examiner les stratégies du contrôleur de domaine

       1. Cliquez sur Démarrer, pointez sur Programmes, puis cliquez sur Outils d’administration.

       2. Dans la stratégie de sécurité du contrôleur de domaine , développez Paramètres de sécurité, puis développez Stratégies locales.

       3. Cliquez sur Options de sécurité.

       4. Double-cliquez sur Sécurité réseau : niveau d’authentification du gestionnaire LAN, puis cliquez sur une valeur dans la liste.

       
       Note

       • Vous devrez peut-être également vérifier les stratégies liées au niveau du site, du domaine ou de l’unité d’organisation (UO) pour déterminer où vous devez configurer le niveau d’authentification du gestionnaire LAN.

       • Si vous implémentez un paramètre stratégie de groupe comme stratégie de domaine par défaut, la stratégie est appliquée à tous les ordinateurs du domaine.

       • Si vous implémentez un paramètre stratégie de groupe en tant que stratégie du contrôleur de domaine par défaut, la stratégie s’applique uniquement aux serveurs de l’unité d’organisation du contrôleur de domaine.

       • Il est judicieux de définir le niveau d’authentification du gestionnaire LAN dans l’entité la plus basse de l’étendue nécessaire dans la hiérarchie des applications de stratégie.

       Windows Server 2003 a un nouveau paramètre par défaut pour utiliser NTLMv2 uniquement. Par défaut, les contrôleurs de domaine Windows Server 2003 et Windows 2000 Server SP3 ont activé la stratégie « Serveur réseau Microsoft : Signer numériquement les communications (toujours) ». Ce paramètre nécessite que le serveur SMB effectue la signature de paquets SMB. Des modifications ont été apportées à Windows Server 2003, car les contrôleurs de domaine, les serveurs de fichiers, les serveurs d’infrastructure réseau et les serveurs Web d’une organisation nécessitent des paramètres différents pour optimiser leur sécurité.
       
       Si vous souhaitez implémenter l’authentification NTLMv2 dans votre réseau, vous devez vous assurer que tous les ordinateurs du domaine sont définis pour utiliser ce niveau d’authentification. Si vous appliquez des extensions clientEs Active Directory pour Windows 95 ou Windows 98 et Windows NT 4.0, les extensions clientes utilisent les fonctionnalités d’authentification améliorées disponibles dans NTLMv2. Étant donné que les ordinateurs clients qui exécutent l’un des systèmes d’exploitation suivants ne sont pas affectés par Windows 2000 stratégie de groupe Objects, vous devrez peut-être configurer manuellement ces clients :

       • Microsoft Windows NT 4.0

       • Microsoft Windows Millennium Edition

       • Microsoft Windows 98

       • Microsoft Windows 95

       Remarque Si vous activez la sécurité réseau : ne stockez pas la valeur de hachage du gestionnaire LAN sur la stratégie de modification de mot de passe suivante ou définissez la clé de Registre NoLMHash , les clients Windows 95 et Windows 98 qui n’ont pas installé le client Directory Services ne peuvent pas se connecter au domaine après une modification de mot de passe.
       
       De nombreux serveurs CIFS tiers, tels que Novell Netware 6, ne connaissent pas NTLMv2 et utilisent uniquement NTLM. Par conséquent, les niveaux supérieurs à 2 n’autorisent pas la connectivité. Il existe également des clients SMB tiers qui n’utilisent pas la sécurité de session étendue. Dans ces cas, le LmCompatiblityLevel du serveur de ressources n’est pas pris en compte. Le serveur compresse ensuite cette demande héritée et l’envoie au contrôleur de domaine utilisateur. Les paramètres du contrôleur de domaine déterminent ensuite les hachages utilisés pour vérifier la demande et s’ils répondent aux exigences de sécurité du contrôleur de domaine.
       
        

       299656 Comment empêcher Windows de stocker un hachage de votre mot de passe dans Active Directory et les bases de données SAM locales
        

       2701704L’événement d’audit affiche le package d’authentification en tant que NTLMv1 au lieu de NTLMv2 Pour plus d’informations sur les niveaux d’authentification LM, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

       239869 Comment activer l’authentification NTLM 2
        

    2. Configurations risquées
       
       Voici les paramètres de configuration dangereux :

       • Paramètres nontrictifs qui envoient des mots de passe en texte clair et qui refusent la négociation NTLMv2

       • Paramètres restrictifs qui empêchent les clients incompatibles ou les contrôleurs de domaine de négocier un protocole d’authentification commun

       • Exiger l’authentification NTLMv2 sur les ordinateurs membres et les contrôleurs de domaine qui exécutent des versions de Windows NT 4.0 antérieures à Service Pack 4 (SP4)

       • Exiger l’authentification NTLMv2 sur les clients Windows 95 ou sur les clients Windows 98 qui n’ont pas installé le client des services d’annuaire Windows.

       • Si vous cliquez pour sélectionner la case à cocher Exiger la sécurité de session NTLMv2 dans le composant logiciel enfichable Microsoft Management Console stratégie de groupe Editor sur un ordinateur Windows Server 2003 ou Windows 2000 Service Pack 3, et que vous réduisez le niveau d’authentification du gestionnaire LAN à 0, les deux paramètres sont en conflit et vous pouvez recevoir le message d’erreur suivant dans le fichier Secpol.msc ou le fichier GPEdit.msc :

         Windows ne peut pas ouvrir la base de données de stratégie locale. Une erreur inconnue s’est produite lors de la tentative d’ouverture de la base de données.

         Pour plus d’informations sur l’outil de configuration et d’analyse de la sécurité, consultez les fichiers d’aide windows 2000 ou Windows Server 2003.

    3. Raisons de modifier ce paramètre

       • Vous souhaitez augmenter le protocole d’authentification commun le plus bas pris en charge par les clients et les contrôleurs de domaine de votre organisation.

       • Lorsque l’authentification sécurisée est une exigence métier, vous souhaitez interdire la négociation des protocoles LM et NTLM.

    4. Raisons de désactiver ce paramètre
       
       Les exigences d’authentification client ou serveur, ou les deux, ont été augmentées au point où l’authentification sur un protocole commun ne peut pas se produire.

    5. Nom symbolique :
       
       LmCompatibilityLevel

    6. Chemin d’accès au Registre :

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Exemples de problèmes de compatibilité

       • Windows Server 2003 : Par défaut, le paramètre de réponses NTLMv2 Send NTLM de Windows Server 2003 est activé. Par conséquent, Windows Server 2003 reçoit le message d’erreur « Accès refusé » après l’installation initiale lorsque vous essayez de vous connecter à un cluster Windows NT 4.0 ou à des serveurs LanManager V2.1, tels que OS/2 Lanserver. Ce problème se produit également si vous essayez de vous connecter à partir d’un client version antérieure à un serveur Windows Server 2003.

       • Vous installez le package de correctif cumulatif de sécurité Windows 2000 1 (SRP1). SRP1 force NTLM version 2 (NTLMv2). Ce package cumulatif a été publié après la publication de Windows 2000 Service Pack 2 (SP2).
          

       • Windows 7 et Windows Server 2008 R2 : de nombreux serveurs CIFS tiers, tels que les serveurs Novell Netware 6 ou Samba linux, ne connaissent pas NTLMv2 et utilisent NTLM uniquement. Par conséquent, les niveaux supérieurs à « 2 » n’autorisent pas la connectivité. Dans cette version du système d’exploitation, la valeur par défaut de LmCompatibilityLevel a été remplacée par « 3 ». Par conséquent, lorsque vous mettez à niveau Windows, ces filtreurs tiers peuvent cesser de fonctionner.

       • Les clients Microsoft Outlook peuvent être invités à entrer des informations d’identification même s’ils sont déjà connectés au domaine. Lorsque les utilisateurs fournissent leurs informations d’identification, ils reçoivent le message d’erreur suivant : Windows 7 et Windows Server 2008 R2

         Les informations d’identification d’ouverture de session fournies étaient incorrectes. Assurez-vous que votre nom d’utilisateur et votre domaine sont corrects, puis tapez à nouveau votre mot de passe.

         Lorsque vous démarrez Outlook, vous pouvez être invité à entrer vos informations d’identification, même si votre paramètre sécurité réseau d’ouverture de session est défini sur Passthrough ou Authentification par mot de passe. Une fois que vous avez tapé vos informations d’identification correctes, vous pouvez recevoir le message d’erreur suivant :

         Les informations d’identification de connexion fournies étaient incorrectes.

         Une trace network monitor peut montrer que le catalogue global a émis une erreur d’appel de procédure distante (RPC) avec l’état 0x5. Un état de 0x5 signifie « Accès refusé ».

       • Windows 2000 : Une capture de moniteur réseau peut afficher les erreurs suivantes dans la session SMB (NetBIOS over TCP/IP) server message block (NetBT) :

         Erreur dos du répertoire de recherche SMB R, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Identificateur d’utilisateur non valide

       • Windows 2000 : si un domaine Windows 2000 avec NTLMv2 de niveau 2 ou ultérieur est approuvé par un domaine Windows NT 4.0, les ordinateurs membres Windows 2000 du domaine de ressources peuvent rencontrer des erreurs d’authentification.

       • Windows 2000 et Windows XP : Par défaut, Windows 2000 et Windows XP définissent l’option de stratégie de sécurité locale au niveau de l’authentification du gestionnaire LAN sur 0. Un paramètre de 0 signifie « Envoyer des réponses LM et NTLM ».
         
         Notez que les clusters Windows NT 4.0 doivent utiliser LM pour l’administration.

       • Windows 2000 : Le clustering Windows 2000 n’authentifie pas un nœud joint si les deux nœuds font partie d’un domaine Windows NT 4.0 Service Pack 6a (SP6a).

       • L’outil de verrouillage IIS (HiSecWeb) définit la valeur LMCompatibilityLevel sur 5 et la valeur RestrictAnonymous sur 2.

       • Services pour Macintosh
         
         Module d’authentification utilisateur (UAM) : Microsoft UAM (Module d’authentification utilisateur) fournit une méthode pour chiffrer les mots de passe que vous utilisez pour vous connecter aux serveurs Windows AFP (AppleTalk Filing Protocol). Le module d’authentification utilisateur (UAM) Apple fournit uniquement un chiffrement minimal ou aucun chiffrement. Par conséquent, votre mot de passe peut facilement être intercepté sur le réseau local ou sur Internet. Bien que l’UAM ne soit pas obligatoire, il fournit une authentification chiffrée aux serveurs Windows 2000 qui exécutent services pour Macintosh. Cette version inclut la prise en charge de l’authentification chiffrée 128 bits NTLMv2 et d’une version compatible macOS X 10.1.
         
         Par défaut, le serveur Windows Server 2003 Services pour Macintosh autorise uniquement l’authentification Microsoft.
          

       • Windows Server 2008, Windows Server 2003, Windows XP et Windows 2000 : si vous configurez la valeur LMCompatibilityLevel sur 0 ou 1, puis que vous configurez la valeur NoLMHash sur 1, les applications et les composants peuvent se voir refuser l’accès via NTLM. Ce problème se produit parce que l’ordinateur est configuré pour activer LM, mais pas pour utiliser des mots de passe stockés par LM.
         
         Si vous configurez la valeur NoLMHash sur 1, vous devez configurer la valeur LMCompatibilityLevel sur 2 ou une valeur supérieure.

11. Sécurité réseau : exigences de signature du client LDAP

    1. Fond
       
       Le paramètre De sécurité réseau : configuration requise pour la signature du client LDAP détermine le niveau de signature de données demandé pour le compte des clients qui émettent des demandes BIND LDAP (Lightweight Directory Access Protocol) comme suit :

       • Aucun : la requête LDAP BIND est émise avec les options spécifiées par l’appelant.

       • Négocier la signature : si le protocole SSL/TLS (Secure Sockets Layer/Transport Layer Security) n’a pas été démarré, la requête LDAP BIND est lancée avec l’option de signature de données LDAP définie en plus des options spécifiées par l’appelant. Si SSL/TLS a été démarré, la requête LDAP BIND est lancée avec les options spécifiées par l’appelant.

       • Exiger la signature : il s’agit de la même chose que la signature negotiate. Toutefois, si la réponse saslBindInProgress intermédiaire du serveur LDAP n’indique pas que la signature du trafic LDAP est requise, l’appelant est informé que la demande de commande LDAP BIND a échoué.

    2. Configuration
       
       risquée L’activation de la sécurité réseau : le paramètre de configuration requise pour la signature du client LDAP est un paramètre de configuration dangereux. Si vous définissez le serveur pour exiger des signatures LDAP, vous devez également configurer la signature LDAP sur le client. Si vous ne configurez pas le client pour utiliser des signatures LDAP, la communication avec le serveur est empêchée. Cela entraîne l’échec de l’authentification utilisateur, des paramètres stratégie de groupe, des scripts d’ouverture de session et d’autres fonctionnalités.

    3. Raisons de modifier ce paramètre
       
       Le trafic réseau non signé est vulnérable aux attaques de l’intercepteur, où un intrus capture les paquets entre le client et les serveurs, les modifie, puis les transfère au serveur. Lorsque cela se produit sur un serveur LDAP, un attaquant peut provoquer la réponse d’un serveur en fonction de requêtes fausses du client LDAP. Vous pouvez réduire ce risque dans un réseau d’entreprise en implémentant des mesures de sécurité physiques fortes pour protéger l’infrastructure réseau. En outre, vous pouvez empêcher toutes sortes d’attaques de l’intercepteur en exigeant des signatures numériques sur tous les paquets réseau au moyen d’en-têtes d’authentification IPSec.

    4. Nom symbolique :
       
       LDAPClientIntegrity

    5. Chemin d’accès au Registre :

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. Journal des événements : taille maximale du journal de sécurité

    1. Fond
       
       Journal des événements : le paramètre de sécurité de taille maximale du journal de sécurité spécifie la taille maximale du journal des événements de sécurité. Ce journal a une taille maximale de 4 Go. Pour localiser ce paramètre, développez
       Paramètres Windows, puis développez Paramètres de sécurité.

    2. Configurations risquées
       
       Voici les paramètres de configuration dangereux :

       • Restriction de la taille du journal de sécurité et de la méthode de rétention des journaux de sécurité lorsque l’option Audit : Arrêter le système immédiatement si le paramètre audits de sécurité de journalisation est activé. Pour plus d’informations, consultez la section « Audit : Arrêter le système immédiatement si vous ne parvenez pas à consigner les audits de sécurité ».

       • Restriction de la taille du journal de sécurité afin que les événements de sécurité d’intérêt soient remplacés.

    3. Raisons d’augmenter ce paramètre
       
       Les exigences métier et de sécurité peuvent vous imposer d’augmenter la taille du journal de sécurité pour gérer les détails supplémentaires du journal de sécurité ou pour conserver les journaux de sécurité pendant une période plus longue.

    4. Les raisons de réduire ce paramètre
       
       observateur d'événements les journaux sont les fichiers mappés en mémoire. La taille maximale d’un journal des événements est limitée par la quantité de mémoire physique sur l’ordinateur local et par la mémoire virtuelle disponible pour le processus de journal des événements. L’augmentation de la taille du journal au-delà de la quantité de mémoire virtuelle disponible pour observateur d'événements n’augmente pas le nombre d’entrées de journal qui sont conservées.

    5. Exemples de problèmes
       
       de compatibilité Windows 2000 : Les ordinateurs qui exécutent des versions de Windows 2000 antérieures à Service Pack 4 (SP4) peuvent arrêter la journalisation des événements dans le journal des événements avant d’atteindre la taille spécifiée dans le paramètre Taille maximale du journal dans observateur d'événements si l’option Ne pas remplacer les événements (effacer le journal manuellement) est activée.
       
       
        

13. Journal des événements : conserver le journal de sécurité

    1. Fond
       
       Le journal des événements : conserver le paramètre de sécurité du journal de sécurité détermine la méthode « wrapper » pour le journal de sécurité. Pour localiser ce paramètre, développez Paramètres Windows, puis développez Paramètres de sécurité.

    2. Configurations risquées
       
       Voici les paramètres de configuration dangereux :

       • Échec de la conservation de tous les événements de sécurité journalisés avant qu’ils ne soient remplacés

       • Configuration du paramètre Taille maximale du journal de sécurité trop petite pour que les événements de sécurité soient remplacés

       • Restriction de la taille du journal de sécurité et de la méthode de rétention pendant que le système Audit : Arrêter immédiatement si le paramètre de sécurité audits de sécurité est activé

    3. Raisons d’activer ce paramètre
       
       Activez ce paramètre uniquement si vous sélectionnez la méthode de rétention Des événements de remplacement par jours . Si vous utilisez un système de corrélation d’événements qui interroge les événements, assurez-vous que le nombre de jours est au moins trois fois la fréquence d’interrogation. Effectuez cette opération pour permettre l’échec des cycles de sondage.

14. Accès réseau : autoriser tout le monde à s’appliquer aux utilisateurs anonymes

    1. Fond
       
       Par défaut, l’accès réseau : autoriser tout le monde à s’appliquer au paramètre Utilisateurs anonymes est défini sur Non défini sur Windows Server 2003. Par défaut, Windows Server 2003 n’inclut pas le jeton d’accès anonyme dans le groupe Tout le monde.

    2. Exemple de problèmes
       
       de compatibilité La valeur suivante de

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 interrompt la création d’approbation entre Windows Server 2003 et Windows NT 4.0, lorsque le domaine Windows Server 2003 est le domaine de compte et le domaine Windows NT 4.0 est le domaine de ressources. Cela signifie que le domaine de compte est approuvé sur Windows NT 4.0 et que le domaine de ressources fait confiance côté Windows Server 2003. Ce comportement se produit parce que le processus de démarrage de l’approbation après la connexion anonyme initiale est ACL avec le jeton Tout le monde qui inclut le SID anonyme sur Windows NT 4.0.

    3. Raisons de modifier ce paramètre
       
       La valeur doit être définie sur 0x1 ou définie à l’aide d’un objet de stratégie de groupe sur l’unité d’organisation du contrôleur de domaine : Accès réseau : autoriser les autorisations Tout le monde à s’appliquer aux utilisateurs anonymes - Activé pour rendre possibles les créations d’approbation.
       
       Notez que la plupart des autres paramètres de sécurité montent en valeur au lieu de descendre à 0x0 dans leur état le plus sécurisé. Une pratique plus sécurisée consiste à modifier le Registre sur l’émulateur de contrôleur de domaine principal plutôt que sur tous les contrôleurs de domaine. Si le rôle d’émulateur du contrôleur de domaine principal est déplacé pour une raison quelconque, le Registre doit être mis à jour sur le nouveau serveur.
       
       Un redémarrage est nécessaire une fois cette valeur définie.

    4. Chemin d’accès au Registre

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. Authentification NTLMv2

    1. Sécurité de session
       
       La sécurité de session détermine les normes de sécurité minimales pour les sessions client et serveur. Il est judicieux de vérifier les paramètres de stratégie de sécurité suivants dans le composant logiciel enfichable Microsoft Management Console stratégie de groupe Editor :

       • Paramètres de l’ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité

       • Sécurité réseau : sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris les serveurs RPC sécurisés)

       • Sécurité réseau : sécurité de session minimale pour les clients basés sur NTLM SSP (y compris rpc sécurisé)

       Les options de ces paramètres sont les suivantes :

       • Exiger l’intégrité des messages

       • Exiger la confidentialité des messages

       • Exiger la sécurité de session NTLM version 2

       • Exiger un chiffrement 128 bits

       Le paramètre par défaut avant Windows 7 est Aucune exigence. À compter de Windows 7, la valeur par défaut a été remplacée par Exiger un chiffrement 128 bits pour améliorer la sécurité. Avec cette valeur par défaut, les appareils hérités qui ne prennent pas en charge le chiffrement 128 bits ne peuvent pas se connecter.
       
       Ces stratégies déterminent les normes de sécurité minimales pour une session de communication d’application à application sur un serveur pour un client.
       
       Notez que, bien que décrits comme des paramètres valides, les indicateurs qui nécessitent l’intégrité et la confidentialité des messages ne sont pas utilisés lorsque la sécurité de session NTLM est déterminée.
       
       Historiquement, Windows NT a pris en charge les deux variantes suivantes de l’authentification de défi/réponse pour les logons réseau :

       • LM challenge/response

       • NTLM version 1 challenge/response

       LM permet l’interopérabilité avec la base installée de clients et de serveurs. NTLM offre une sécurité améliorée pour les connexions entre les clients et les serveurs.
       
       Les clés de Registre correspondantes sont les suivantes :

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec »
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec »

    2. Configurations risquées
       
       Ce paramètre contrôle la façon dont les sessions réseau sécurisées à l’aide de NTLM seront gérées. Cela affecte les sessions RPC authentifiées auprès de NTLM, par exemple. Les risques suivants sont les suivants :

       • L’utilisation de méthodes d’authentification plus anciennes que NTLMv2 facilite la communication en raison des méthodes de hachage plus simples utilisées.

       • L’utilisation de clés de chiffrement inférieures à 128 bits permet aux attaquants de rompre la communication à l’aide d’attaques par force brute.

Synchronisation de l’heure

Échec de la synchronisation de l’heure. Le temps d’arrêt est de plus de 30 minutes sur un ordinateur affecté. Assurez-vous que l’horloge de l’ordinateur client est synchronisée avec l’horloge du contrôleur de domaine.

Solution de contournement pour la signature SMB

Nous vous recommandons d’installer Service Pack 6a (SP6a) sur les clients Windows NT 4.0 qui interagissent dans un domaine Windows Server 2003. Les clients Windows 98 Second Edition, windows 98 et Windows 95 doivent exécuter le client des services d’annuaire pour effectuer NTLMv2. Si windows NT 4.0 n’est pas installé sur les clients Windows NT 4.0 SP6 ou si les clients Windows 95, les clients Windows 98 et les clients Windows 98SE ne disposent pas du client Directory Services, désactivez la signature SMB dans le paramètre de stratégie du contrôleur de domaine par défaut sur l’unité d’organisation du contrôleur de domaine, puis liez cette stratégie à toutes les unités d’organisation qui hébergent les contrôleurs de domaine.

Le client des services d’annuaire pour Windows 98 Second Edition, Windows 98 et Windows 95 effectuera la signature SMB avec les serveurs Windows 2003 sous l’authentification NTLM, mais pas sous l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB de ces clients.

Bien que nous ne le recommandons pas, vous pouvez empêcher la signature SMB d’être requise sur tous les contrôleurs de domaine qui exécutent Windows Server 2003 dans un domaine. Pour configurer ce paramètre de sécurité, procédez comme suit :

1. Ouvrez la stratégie du contrôleur de domaine par défaut.

2. Ouvrez le dossier Configuration de l’ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité.

3. Recherchez, puis cliquez sur le serveur réseau Microsoft : Signer numériquement le paramètre de stratégie de communication (toujours), puis cliquez sur Désactivé.

Important Cette section, méthode ou tâche contient des étapes qui vous indiquent comment modifier le Registre. Toutefois, de graves problèmes peuvent se produire si vous modifiez le Registre de manière incorrecte. Par conséquent, veillez à suivre ces étapes avec soin. Pour une protection supplémentaire, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du Registre, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

322756 Comment sauvegarder et restaurer le Registre dans Windows. Vous pouvez également désactiver la connexion SMB sur le serveur en modifiant le registre. Pour ce faire, procédez comme suit :

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

2. Recherchez, puis cliquez sur la sous-clé suivante :
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

3. Cliquez sur l’entrée enablesecuritysignature .

4. Dans le menu Modifier , cliquez sur Modifier.

5. Dans la zone de données Valeur , tapez 0, puis cliquez sur OK.

6. Quitter l’Éditeur du Registre.

7. Redémarrez l’ordinateur ou arrêtez, puis redémarrez le service serveur. Pour ce faire, tapez les commandes suivantes à l’invite de commandes, puis appuyez sur Entrée après avoir tapé chaque commande :
   net stop server
   serveur de démarrage net

Notez que la clé correspondante sur l’ordinateur client se trouve dans la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters L’exemple suivant répertorie les numéros de code d’erreur traduits en codes d’état et en messages d’erreur détaillés mentionnés précédemment :

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

324802 Comment configurer des stratégies de groupe pour définir la sécurité des services système dans Windows Server 2003

816585 Comment appliquer des modèles de sécurité prédéfinis dans Windows Server 2003