Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

Client, les services et les problèmes de programmes peuvent se produire si vous modifiez les paramètres de sécurité et des attributions de droits utilisateur

Le support de Windows XP a pris fin

Microsoft a mis fin au support de Windows XP le 8 avril 2014. Cette modification a affecté vos mises à jour logicielles et options de sécurité. Découvrez les implications de ce changement à votre niveau et la marche à suivre pour rester protégé.

Le support de Windows Server 2003 a pris fin le 14 juillet 2015

Microsoft a mis fin au support de Windows Server 2003 le 14 juillet 2015. Cette modification a affecté vos mises à jour logicielles et options de sécurité. Découvrez les implications de ce changement à votre niveau et la marche à suivre pour rester protégé.

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 823659
Résumé
Les paramètres de sécurité et les attributions de droits utilisateur peuvent être modifiées dans les stratégies locales et les stratégies de groupe pour aider à renforcer la sécurité sur les contrôleurs de domaine et les ordinateurs membres. Toutefois, l'inconvénient du renforcement de sécurité est l'introduction d'incompatibilités avec les clients, services et programmes.

Cet article décrit les incompatibilités qui peuvent se produire sur les ordinateurs clients qui exécutent Windows XP ou une version antérieure de Windows, lorsque vous modifiez les paramètres de sécurité spécifiques et des attributions de droits utilisateur dans un domaine Windows Server 2003 ou un domaine Windows Server antérieur.

Pour plus d'informations sur la stratégie de groupe pour Windows 7, Windows Server 2008 R2 et Windows Server 2008, consultez les articles suivants :Remarque : Le contenu restant dans cet article est spécifique à Windows XP, Windows Server 2003 et versions antérieures de Windows.

Windows XP

Cliquez ici pour afficher des informations spécifiques à Windows XP
Pour augmenter la prise de conscience des paramètres de sécurité mal configuré, utilisez l'outil Éditeur d'objets de stratégie de groupe pour modifier les paramètres de sécurité. Lorsque vous utilisez Éditeur d'objet de stratégie de groupe, les attributions des droits d'utilisateur ont été améliorées sur les systèmes d'exploitation suivants :
  • Windows XP Professionnel 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 des droits utilisateur à un paramètre qui offre le niveau de compatibilité inférieur et qui est plus restrictif. Si vous modifiez directement la même sécurité utilisateur ou le paramètre attribution des droits à l'aide du Registre ou à l'aide de modèles de sécurité, l'effet est identique à la modification du paramètre dans l'éditeur d'objets de stratégie de groupe. Toutefois, la boîte de dialogue qui contient le lien vers cet article n'apparaît pas.

Cet article contient des exemples de clients, les programmes et les opérations qui sont affectées par les paramètres de sécurité spécifiques ou des attributions de droits utilisateur. Toutefois, les exemples ne font pas autorités pour tous les systèmes d'exploitation de Microsoft, pour tous les systèmes d'exploitation de tierce partie ou toutes les versions des programmes qui sont affectés. Pas tous les paramètres de sécurité et des attributions des droits d'utilisateur sont incluses 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 test avant de les introduire dans un environnement de production. La forêt de test doit refléter la forêt de production dans l'une des manières suivantes :
  • Les versions de système d'exploitation client et serveur, client et les programmes serveur, versions des service packs, correctifs, modifications de schéma, sécurité groupes, les appartenances aux groupes, autorisations sur les objets dans le système de fichiers partagés dossiers, le Registre, le service d'annuaire Active Directory local et de groupe Objet et les paramètres de stratégie de type et emplacement du nombre
  • Tâches administratives sont exécutées, administration outils utilisés et les systèmes d'exploitation qui servent à effectuer tâches d'administration
  • Opérations sont effectuées comme suit :
    • Authentification d'ouverture de session utilisateur et ordinateur
    • Réinitialisations de mot de passe par les utilisateurs, ordinateurs et les administrateurs
    • Navigation
    • Définition des autorisations pour le système de fichiers, de dossiers partagés, pour le Registre et pour les ressources Active Directory à l'aide de l'éditeur ACL dans tous les systèmes d'exploitation client tous les domaines de ressources à partir de tous les systèmes d'exploitation client tous les comptes ou domaines de ressources
    • Impression à partir des comptes d'administration et non administratives

Windows Server 2003 SP1

Cliquez ici pour afficher des informations spécifiques à Windows Server SP1

Avertissements dans Gpedit.msc

Pour aider les clients prenant en charge que qu'ils modifient un droit d'utilisateur ou option de sécurité qui pourrait avoir un impact négatif sur leur réseau, deux mécanismes d'avertissement ont été ajoutés à gpedit.msc. Lorsque les administrateurs modifient un droit d'utilisateur qui peut nuire à l'entreprise, il voit apparaître une nouvelle icône qui ressemble à un panneau Cédez le passage. Ils recevront également un message d'avertissement qui a un lien vers l'article 823659 de la Base de connaissances Microsoft. Le texte de ce message est comme suit :
Modification de ce paramètre peut affecter la compatibilité avec les clients, services et applications. Pour plus d'informations, consultez <user right="" or="" security="" option="" being="" modified="">(Q823659)</user>
Si vous avez été redirigé vers cet article de la Base de connaissances à partir d'un lien dans Gpedit.msc, assurez-vous de lire et de comprendre l'explication fournie et l'effet possible de modifier ce paramètre. La liste suivante décrit les droits d'utilisateur qui contiennent le texte d'avertissement :
  • Accéder à cet ordinateur à partir du réseau
  • Ouvrez une session localement
  • Outrepasser le contrôle
  • Activer les ordinateurs et les utilisateurs pour la délégation approuvée
Voici les Options de sécurité qui ont l'avertissement et un message contextuel :
  • Membre de domaine : Crypter ou signer numériquement les données des canaux sécurisés (toujours) les
  • Membre de domaine : Exiger fort (Windows 2000 ou une version ultérieure) la clé de session
  • Contrôleur de domaine : Signature de serveur LDAP
  • Serveur réseau Microsoft : communications signées numériquement (toujours)
  • Accès réseau : Permet de Sid anonyme / traduction du nom
  • Accès réseau : Ne permettent pas l'énumération anonyme des SAM comptes et partages
  • Sécurité réseau : niveau d'authentification LAN Manager
  • Audit : Arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité
  • Accès réseau : Exigences de signature de client LDAP
Plus d'informations
Les sections suivantes décrivent les incompatibilités qui peuvent se produire lorsque vous modifiez des paramètres spécifiques dans les domaines Windows NT 4.0, les domaines Windows 2000 et les domaines Windows Server 2003.

Droits d'utilisateur

Cliquez ici pour afficher des informations sur les droits d'utilisateur
La liste suivante décrit un droit d'utilisateur, identifie les paramètres de configuration qui peuvent provoquer des problèmes, explique pourquoi vous devez appliquer le droit d'utilisateur et pourquoi vous voudrez peut-être supprimer le droit d'utilisateur et fournit des exemples de problèmes de compatibilité qui peuvent se produire lorsque le droit d'utilisateur est configuré.
  1. Accéder à cet ordinateur à partir du réseau
    1. Arrière-plan

      La capacité d'interagir avec des ordinateurs Windows à distance requiert le droit d'utilisateur accéder à cet ordinateur à partir du réseau . Exemples d'opérations réseau sont les suivants :
      • Réplication d'Active Directory entre contrôleurs de domaine dans une forêt ou un domaine commun
      • Demandes d'authentification pour les contrôleurs de domaine par les utilisateurs et ordinateurs
      • Accès aux dossiers partagés, imprimantes et autres services du système qui sont trouvent sur des ordinateurs distants sur le réseau


      Les utilisateurs, ordinateurs et comptes de service de gains ou de perdre le droit d'utilisateur accéder à cet ordinateur à partir du réseau en étant explicitement ou implicitement ajoutés à partir d'un groupe de sécurité qui a été accordé ce droit d'utilisateur. 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 peut-être être ajouté implicitement par le système d'exploitation à un groupe de sécurité calculé comme utilisateurs du domaine, utilisateurs authentifiés ou contrôleurs de domaine d'entreprise.

      Par défaut, les comptes d'utilisateurs et comptes d'ordinateurs sont accordés l'utilisateur d'accéder à cet ordinateur à partir du réseau droit lorsque calculée comme tout le monde ou, mieux, le groupe utilisateurs authentifiés et, pour les contrôleurs de domaine, le groupe Enterprise Domain Controllers, sont définis dans l'objet de stratégie de groupe (GPO) les contrôleurs de domaine par défaut.
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Suppression de la sécurité Enterprise Domain Controllers groupe à partir de ce droit d'utilisateur
      • Suppression du groupe utilisateurs authentifiés ou un groupe explicite qui permet aux utilisateurs, ordinateurs et comptes de service à l'utilisateur droit de se connecter aux ordinateurs du réseau.
      • Suppression de tous les utilisateurs et ordinateurs à partir de cet utilisateur droite
    3. Raisons d'accorder ce droit d'utilisateur
      • L'octroi du droit d'utilisateur accéder à cet ordinateur à partir du réseau au groupe Enterprise Domain Controllers satisfait aux exigences d'authentification que la réplication Active Directory doit avoir pour la réplication entre contrôleurs de domaine dans la même forêt.
      • Ce droit d'utilisateur permet aux utilisateurs et ordinateurs accéder aux fichiers partagés, imprimantes et les services système, y compris Active Répertoire.
      • Ce droit d'utilisateur est requis pour les utilisateurs d'accéder à courrier à l'aide de versions antérieures de Microsoft Outlook Web Access (OWA).
    4. Raisons de supprimer ce droit d'utilisateur
      • Les utilisateurs qui peuvent se connecter leurs ordinateurs à la réseau peut accéder aux ressources sur des ordinateurs distants qu'ils disposent d'autorisations pour. Par exemple, ce droit d'utilisateur est requis pour un utilisateur à se connecter au partage imprimantes et aux dossiers. Si ce droit d'utilisateur est accordé à tout le monde groupe, les autorisations du système de fichiers et si certains dossiers partagés sont partage et NTFS configuré de sorte que le même groupe dispose d'un accès en lecture, tout le monde peut afficher les fichiers dans ces dossiers partagés. Toutefois, il s'agit d'une situation peu probable pour les frais installations de Windows Server 2003, car le partage par défaut et le NTFS autorisations dans Windows Server 2003 n'incluent pas le groupe tout le monde. Pour les systèmes qui sont mis à niveau à partir de Microsoft Windows NT 4.0 ou Windows 2000, cela vulnérabilité peut-être avoir un niveau plus élevé de risque, car le partage de la valeur par défaut et le les autorisations de système de fichiers pour ces systèmes d'exploitation ne sont pas aussi restrictives que les autorisations par défaut dans Windows Server 2003.
      • Il n'y a aucune raison valide de la suppression d'entreprise Groupe de contrôleurs de domaine à partir de ce droit d'utilisateur.
      • Le groupe tout le monde est généralement supprimé en faveur de le groupe utilisateurs authentifiés. Si le groupe tout le monde est supprimé, le Groupe utilisateurs authentifiés doit bénéficier de ce droit d'utilisateur.
      • Les domaines Windows NT 4.0 sont mis à niveau vers Windows 2000 n'accordent pas explicitement l'utilisateur d'accéder à cet ordinateur à partir du réseau vers la droite pour le groupe tout le monde, le groupe utilisateurs authentifiés ou le groupe Enterprise Domain Controllers. 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 permet d'éviter ce problème de configuration en accordant que ce droit d'utilisateur au groupe Enterprise Domain Controllers lorsque vous mettez à niveau les contrôleurs de domaine principal Windows NT 4.0 (PDC). Accordez au groupe Enterprise Domain Controllers ce droit si elle n'est pas présent dans l'éditeur d'objets de stratégie de groupe d'utilisateur.
    5. Exemples de problèmes de compatibilité
      • Windows 2000 et Windows Server 2003 : Comme signalé par les outils tels que REPLMON et REPADMIN ou la réplication des événements dans le journal des événements de contrôle la réplication des partitions suivantes échouera avec des erreurs « Accès refusé ».
        • Partition de schéma d'annuaire Active
        • Partition de configuration
        • Partition de domaine
        • Partition du catalogue global
        • Partition d'application
      • Microsoft tous les systèmes d'exploitation :Authentification de compte d'utilisateur à partir d'ordinateurs clients du réseau à distance échoue à moins que l'utilisateur ou un groupe de sécurité dont l'utilisateur est un membre a reçu ce droit d'utilisateur.
      • Microsoft tous les systèmes d'exploitation :L'authentification de compte à partir de clients réseau distants échoue sauf si le compte ou le compte est membre d'un groupe de sécurité a reçu ce droit d'utilisateur. Ce scénario s'applique aux comptes d'utilisateurs, aux comptes d'ordinateurs et aux comptes de service.
      • Microsoft tous les systèmes d'exploitation :Supprimez tous les comptes de ce droit utilisateur empêche n'importe quel compte d'ouverture de session sur le domaine ni accéder aux ressources réseau. Si calculées des groupes tels que les contrôleurs de domaine d'entreprise, tout le monde ou utilisateurs authentifiés sont supprimés, vous devez explicitement accorder ce droit d'utilisateur aux comptes ou aux groupes de sécurité dont le compte est un membre pour accéder aux ordinateurs distants sur le réseau. Ce scénario s'applique à tous les comptes d'utilisateurs, à tous les comptes d'ordinateur et à tous les comptes de service.
      • Microsoft tous les systèmes d'exploitation :Le compte administrateur local utilise un mot de passe « vide ». 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. Permettre l'ouverture d'une session locale
    1. Arrière-plan

      Les utilisateurs qui essaient d'ouvrir une session sur la console d'un ordinateur fonctionnant sous Windows (en utilisant le raccourci clavier CTRL + ALT + SUPPR) et les comptes qui tentent de démarrer un service doivent avoir des privilèges d'ouverture de session locale sur l'ordinateur hôte. Les administrateurs qui ouvrent une session les consoles des ordinateurs membres ou contrôleurs de domaine tout au long de leur entreprise et de domaine qui ouvrent une session les ordinateurs membres d'accéder à leur bureau en utilisant des comptes non privilégiés sont des exemples d'opérations d'ouverture de session locale. Les utilisateurs qui utilisent une connexion Bureau à distance ou Terminal Server doivent avoir l'utilisateur Autoriser l'ouverture d'une session locale sur les ordinateurs de destination qui exécutent Windows 2000 ou Windows XP Étant donné que ces modes d'ouverture de session sont considérés comme locaux sur l'ordinateur hôte. Utilisateurs qui ouvrent une session sur un serveur Terminal Server et qui n'est pas le cas possèdent ce droit peuvent toujours démarrer une session interactive à distance dans Windows Domaines Server 2003 s'ils ont le droit d'utilisateur Autoriser accès via Terminal Services .
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Suppression des groupes administratifs de sécurité, y compris les opérateurs de compte, opérateurs de sauvegarde, opérateurs d'impression ou opérateurs de serveur et le groupe intégré Administrateurs de stratégie du contrôleur de domaine par défaut.
      • Suppression des comptes de service utilisés par les composants et 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 groupes de sécurité qui ouvrent une session la console des ordinateurs membres du domaine.
      • Suppression des comptes de service sont définis dans la base de données Gestionnaire de comptes de sécurité (SAM) locale des ordinateurs membres ou des ordinateurs du groupe de travail.
      • Suppression non-intégré-comptes administratifs qui sont authentifient via les Services Terminal Server qui s'exécute sur un contrôleur de domaine.
      • Ajout de tous les comptes d'utilisateur explicitement dans le domaine ou implicitement par l'intermédiaire de tout le monde groupe le droit de connexion Refuser ouvrir une session localement . Cette configuration empêche les utilisateurs de se connecter une session sur n'importe quel ordinateur membre ou à n'importe quel contrôleur de domaine dans le domaine.
    3. Raisons d'accorder ce droit d'utilisateur
      • Les utilisateurs doivent disposer du droit d'utilisateur Autoriser l'ouverture d'une session locale pour accéder à la console ou le bureau d'un groupe de travail ordinateur, un ordinateur membre ou un contrôleur de domaine.
      • Les utilisateurs doivent disposer de ce droit d'utilisateur ouvrir une session sur une session de Services Terminal Server s'exécute sur un ordinateur membre Windows 2000 ou un contrôleur de domaine.
    4. Raisons de supprimer ce droit d'utilisateur
      • Échec pour restreindre l'accès à la console à légitime comptes d'utilisateurs peuvent entraîner des utilisateurs non autorisés peuvent télécharger et exécuter code malveillant à modifier leurs droits d'utilisateur.
      • Supprimer le droit d'utilisateur Autoriser l'ouverture d'une session locale empêche les connexions non autorisées sur les consoles de ordinateurs, tels que les contrôleurs de domaine ou serveurs d'applications.
      • La suppression de ce droit d'ouverture de session empêche non-membre du domaine comptes d'ouvrir une session la console des ordinateurs membres dans le domaine.
    5. Exemples de problèmes de compatibilité
      • Les serveurs Terminal Server Windows 2000 :Le droit d'utilisateur Autoriser l'ouverture d'une session localement est requis pour les utilisateurs à ouvrir une session sur Windows 2000 serveurs Terminal Server.
      • Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 :Comptes d'utilisateur doivent bénéficier de ce droit d'utilisateur ouvrir une session la console des ordinateurs qui exécutent Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003.
      • Windows NT 4.0 et versions ultérieur :Sur les ordinateurs qui exécutent Windows NT 4.0 et ultérieure, si vous ajoutez le droit d'utilisateur permettre le journal locale , mais vous implicitement ou explicitement également accordent le droit d'ouverture de session de Refuser l'ouverture de localement , les comptes seront pas en mesure d'ouvrir une session sur le console des contrôleurs de domaine.
  3. Outrepasser le contrôle
    1. Arrière-plan

      Le droit d'utilisateur Outrepasser le contrôle autorise l'utilisateur à parcourir les dossiers NTFS système de fichiers ou dans le Registre sans vérification de l'autorisation d'accès spécial de Parcourir le dossier . Le droit d'utilisateur Outrepasser le contrôle n'autorise pas l'utilisateur de répertorier le contenu d'un dossier. Il permet à l'utilisateur de parcourir ses dossiers uniquement.
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Suppression des comptes non administratifs, ouvrez une session sur des ordinateurs fonctionnant sous Windows 2000 Terminal Services ou les Services Terminal Server Windows Server 2003 qui n'ont pas les autorisations d'accès aux fichiers et dossiers du système de fichiers.
      • Supprimer le groupe tout le monde de la liste des entités de sécurité qui possèdent ce droit par défaut. Systèmes d'exploitation Windows et que de nombreux programmes sont conçus dans l'attente que quiconque ayant légitimement accès à l'ordinateur aura le droit d'utilisateur Outrepasser le contrôle . Par conséquent, la suppression de tout le monde groupe dans la liste des entités de sécurité qui ont ce droit d'utilisateur par défaut peut entraîner une instabilité du système d'exploitation ou d'échec du programme. Il est préférable de laisser ce paramètre à sa valeur par défaut.
    3. Raisons d'accorder ce droit d'utilisateur

      Par défaut, le droit d'utilisateur Outrepasser le contrôle est autorise toute personne à outrepasser le contrôle. Pour a rencontré les administrateurs système de Windows, c'est le comportement attendu, et ils configurent les listes de contrôle d'accès (SACL) du système de fichiers en conséquence. La seule scénario dans lequel la configuration par défaut peut entraîner un problème est si le administrateur qui configure les autorisations ne comprend pas le comportement et attend que les utilisateurs qui ne peuvent pas accéder à un dossier parent ne sera pas en mesure d'accéder le 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 très engagées sur la sécurité peuvent être tentées de supprimer le groupe tout le monde, ou même le groupe d'utilisateurs, dans la liste des groupes qui ont le droit d'utilisateur Outrepasser le contrôle .
    5. Exemples de problèmes de compatibilité
      • Windows 2000, Windows Server 2003 :Si le droit d'utilisateur Outrepasser le contrôle est supprimé ou est mal configuré sur les ordinateurs qui sont Windows 2000 ou Windows Server 2003, les paramètres de stratégie de groupe dans le SYSVOL dossier n'est pas répliqués entre les contrôleurs de domaine dans le domaine.
      • Windows 2000, Windows XP Professionnel, Windows Server 2003 :Les ordinateurs qui exécutent Windows 2000, Windows XP Professionnel ou Windows Server 2003 enregistrent les événements 1000 et 1202 et ne sera pas en mesure d'appliquer des stratégies ordinateur et utilisateur lorsque les autorisations de système de fichiers requis sont supprimées de l'arborescence SYSVOL si l'utilisateur Bypass traverse checking droit est supprimé ou est mal configuré.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        290647ID d'événement 1000 et 1001 est enregistré toutes les cinq minutes dans le journal des événements Application
      • Windows 2000, Windows Server 2003 : Sur les ordinateurs qui exécutent Windows 2000 ou Windows Server 2003, le Quota onglet dans l'Explorateur Windows disparaît lorsque afficher les propriétés d'un volume.
      • Windows 2000 : Les non-administrateurs ouvrent une session sur un serveur Terminal Server Windows 2000 peut 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 quitter l'application.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        272142Les utilisateurs sont déconnectés automatiquement lorsque vous tentez d'ouvrir une session sur Terminal Server
      • 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 n'est peut-être pas en mesure d'accéder aux dossiers partagés ou des fichiers sur les dossiers partagés et recevra les messages d'erreur « Accès refusé » s'ils ne disposent pas du droit d'utilisateur Outrepasser le contrôle .

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        277644Message d'erreur « Accès refusé » lorsque les utilisateurs tentent d'accéder aux dossiers partagés
      • Windows NT 4.0 :Sur les ordinateurs Windows NT 4.0, suppression du droit d'utilisateur Outrepasser le contrôle entraîne une copie du fichier à l'abandon des flux de fichier. Si vous supprimer ce droit d'utilisateur, lorsqu'un fichier est copié à partir d'un client Windows ou d'un Client de Macintosh à un contrôleur de domaine Windows NT 4.0 qui exécute les Services pour Macintosh, le flux de fichier de destination est perdu et le fichier s'affiche sous la forme d'un fichier texte.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        172930Le retrait de « Outrepasser le contrôle de » entraîne un abandon des flux de la copie de fichier
      • Microsoft Windows 95, Microsoft Windows 98 :Sur un ordinateur client qui exécute Windows 95 ou Windows 98, le net use * /home commande échouera avec un accès" Message d'erreur refusé » si le groupe utilisateurs authentifiés n'est pas le droit Outrepasser le contrôle utilisateur.
      • Outlook Web Access :Les non-administrateurs ne pourront pas ouvrir une session sur Microsoft Outlook Web Access, et ils recevront un message d'erreur « Accès refusé » s'ils ne disposent pas du droit d'utilisateur Outrepasser le contrôle .

Paramètres de sécurité

Cliquez ici pour afficher des informations sur les paramètres de sécurité
La liste suivante identifie un paramètre de sécurité, et la liste imbriquée fournit une description sur le paramètre de sécurité, identifie les paramètres de configuration qui peuvent provoquer des problèmes, explique pourquoi vous devez appliquer le paramètre de sécurité et décrit ensuite les raisons pourquoi vous souhaitez supprimer le paramètre de sécurité. La liste imbriquée fournit ensuite un nom symbolique pour le paramètre de sécurité et le chemin d'accès du Registre du paramètre de sécurité. Enfin, les exemples sont fournis des problèmes de compatibilité qui peuvent se produire lorsque le paramètre de sécurité est configuré.
  1. Audit : Arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité
    1. Arrière-plan
      • La Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité détermine si le système s'arrête si vous ne pouvez pas enregistrer les événements de sécurité. Ce paramètre est requis pour l'évaluation C2 du programme approuvé ordinateur sécurité évaluation critères TCSEC () et pour le Common Criteria for Information Technology Security Evaluation empêcher les événements auditables 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 Stop s'affiche.
      • Si l'ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, les preuves critiques ou importantes informations de dépannage peuvent ne pas être disponibles pour examen après un incident de sécurité.
    2. Configuration à risque

      L'exemple suivant est un paramètre de configuration nuisible : le Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité est activé et la taille du journal des événements sécurité est limitée par l'option ne pas remplacer les événements (nettoyage manuel du journal) , l'option Remplacer les événements si nécessaire , ou le Remplacer les événements datant de plus nombre jours option dans l'Observateur d'événements. Reportez-vous à la section « Exemples de compatibilité Section des problèmes » pour plus d'informations sur les risques spécifiques pour les ordinateurs la version d'origine de Windows 2000, Windows 2000 Service en cours d'exécution 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 informations de résolution des problèmes importantes ou des preuves stratégiques soient pas disponibles pour la révision après un incident de sécurité.
    4. Raisons de désactiver ce paramètre
      • L'activation de la d'Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité paramètre arrête le système si un audit de sécurité ne peut pas être consigné pour une raison quelconque. En règle générale, un événement ne peut pas être enregistré lorsque le journal d'audit de sécurité est complet et lorsque la méthode de rétention est l'option ne pas remplacer les événements (nettoyage manuel du journal) ou le Remplacer les événements datant de plus nombre jours option.
      • La charge administrative de l'activation de la Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité paramètre peut être très élevé, surtout si vous activez également l'option ne pas remplacer les événements (nettoyage manuel du journal) pour le journal de sécurité. Ce paramètre permet une gestion individuelle des actions de l'opérateur. Par exemple, un administrateur peut réinitialiser les autorisations sur tous les utilisateurs, ordinateurs et groupes dans une unité d'organisation (UO) où l'audit a été activé à l'aide du compte administrateur intégré ou autre compte partagé et puis refuser qu'il a réinitialisé ces autorisations. Toutefois, l'activation du paramètre réduit la robustesse du système, car un serveur peut être forcé de fermer surchargé par elle d'événements d'ouverture de session et avec d'autres événements de sécurité sont écrits dans le journal de sécurité. En outre, étant donné que l'arrêt n'est pas normal, un préjudice irréparable pour système d'exploitation, des programmes ou des données peut entraîner. Même si NTFS garantit l'intégrité du système de fichiers en un arrêt système anormal, il ne peut pas garantir que chaque fichier de données de chaque programme sera toujours présent dans un formulaire utilisable lorsque le système redémarre.
    5. Nom symbolique :

      CrashOnAuditFail

    6. Chemin d'accès du 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 de Windows 2000, Windows 2000 SP1, Windows 2000 SP2 ou Service Pack 3 de Windows Server peuvent cesser d'enregistrement des événements avant que la taille est spécifiée dans l'option taille maximale du journal pour le journal de sécurité est atteinte. Ce bogue est résolu. dans Windows 2000 Service Pack 4 (SP4). Assurez-vous que votre domaine Windows 2000 contrôleurs ont installé avant d'envisager de Windows 2000 Service Pack 4 l'activation de ce paramètre.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        312571Le journal des événements arrête l'enregistrement des événements avant d'atteindre la taille maximale du journal
      • Windows 2000, Windows Server 2003 :Ordinateurs qui exécutent Windows 2000 ou Windows Server 2003 peut cesser de répondre et puis peut redémarrer spontanément si le Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité paramètre est activé, le journal de sécurité est plein, et une entrée de journal des événements existant ne peut pas être remplacée. Lorsque l'ordinateur redémarre, le message d'erreur suivant s'affiche :
        STOP : C0000244 {L'audit a échoué}
        Une tentative de génération d'un audit de sécurité a échoué.
        Pour récupérer, un administrateur doit ouvrir une session, archiver le journal de sécurité (facultatif) Effacer le journal de sécurité et réinitialiser cette option (facultative et en fonction des besoins).
      • Client réseau Microsoft pour MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003 :Les non-administrateurs essaient d'ouvrir une session sur 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.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        160783Message d'erreur : les utilisateurs ne peuvent pas ouvrir une session sur une station de travail
      • Windows 2000 :Sur les ordinateurs Windows 2000, les utilisateurs non administrateurs ne pourront pas ouvrir une session sur les serveurs d'accès distant, et ils recevront un message d'erreur semblable au suivant :
        Utilisateur inconnu ou mauvais mot de passe
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        285665Message d'erreur : votre compte est configuré pour empêcher l'utilisation de cet ordinateur
      • Windows 2000 :Sur les contrôleurs de domaine Windows 2000, le service Messagerie inter-sites (Ismserv.exe) s'arrête et ne peut pas être redémarré. L'outil DCDIAG signale l'erreur "Échec du test des services ISMserv" et ID d'événement 1083 est enregistré 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 de sécurité est plein.
      • Microsoft Exchange 2000 :Les serveurs qui exécutent Exchange 2000 ne seront pas en mesure de monter la base de données de banque d'informations et d'événement 2102 est enregistré dans le journal des événements.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        314294Messages d'erreur Exchange 2000 sont générés en raison de droit SeSecurityPrivilege et à Policytest
      • Outlook, Outlook Web Access : Les non-administrateurs ne pourront pas accéder à leur courrier par le biais de Microsoft Outlook ou via Microsoft Outlook Web Access, et ils seront une erreur 503.
  2. Contrôleur de domaine : signature de serveur LDAP
    1. Arrière-plan

      Le contrôleur de domaine : signature de serveur LDAP paramètre de sécurité détermine si le serveur Lightweight Directory Access Protocol (LDAP) exige que les clients LDAP négocier la signature de données. Les valeurs possibles pour ce paramètre de stratégie sont les suivantes :
      • Aucun : Signature de données n'est pas nécessaire pour créer une liaison avec le serveur. Si le la signature des données demandes client, le serveur prend en charge il.
      • Nécessite la signature : L'option de signature des données LDAP doit être négociée tant que le Transport Layer Security/Secure Socket Layer (SSL/TLS) est utilisé.
      • non défini : Ce paramètre n'est pas activé ou désactivé.
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • L'activation nécessite la signature dans les environnements où les clients ne gèrent pas la signature LDAP ou où la signature LDAP côté client n'est pas activée sur le client
      • Appliquer le Windows 2000 ou Windows Server Modèle de sécurité Hisecdc.inf 2003 dans des environnements où les clients ne prise en charge la signature LDAP ou où la signature LDAP côté client n'est activé
      • Appliquer le Windows 2000 ou Windows Server Modèle de sécurité Hisecws.inf 2003 dans des environnements où les clients ne prise en charge la signature LDAP ou où la signature LDAP côté client n'est activé
    3. Raisons d'activer ce paramètre

      Le trafic réseau non signé est sensible aux attaques man-in-the-middle où un intrus intercepte des paquets entre le client et le serveur modifie les paquets et puis les transfère au serveur. Lorsque ce problème se produit sur un serveur LDAP, un agresseur pourrait obliger le serveur à prendre des décisions qui reposent sur de fausses requêtes provenant du client LDAP. Vous pouvez réduire ce risque dans un réseau d'entreprise en mettant en œuvre des mesures de sécurité physiques fortes pour protéger l'infrastructure réseau. Mode en-tête d'authentification Internet Protocol security (IPSec) peut aider à prévenir les attaques man-in-the-middle. Car il effectue l'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 seront pas être en mesure d'effectuer des requêtes LDAP sur les contrôleurs de domaine et les global Si l'authentification NTLM est négociée et si le bon service packs des catalogues ne sont pas installés sur les contrôleurs de domaine Windows 2000.
      • Le traçage réseau du trafic LDAP entre clients et serveurs sera crypté. Cela rend difficile l'examen des conversations LDAP.
      • Serveurs Windows 2000 ou doivent être Windows 2000 Service Pack 3 (SP3) installé lorsqu'ils sont administrés par des programmes qui prennent en charge LDAP de signature qui sont exécutés à partir d'ordinateurs clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        325465Les contrôleurs de domaine Windows 2000 nécessitent le Service Pack 3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003
    5. Nom symbolique :

      LDAPServerIntegrity
    6. Chemin d'accès du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
    7. Exemples de problèmes de compatibilité
      • Liaisons simples échouent, et vous recevrez le message d'erreur suivant :
        Échec de Ldap_simple_bind_s() : 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 fonctionneront pas correctement sur les contrôleurs de domaine qui exécutent les versions de Windows 2000 antérieures au Service Pack 3 lorsque l'authentification NTLM est négociée.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        325465Les contrôleurs de domaine Windows 2000 nécessitent le Service Pack 3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003
      • 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 des contrôleurs de domaine exécutant des versions de Windows 2000 qui sont antérieures au Service Pack 3 ne fonctionnent pas correctement s'ils utilisent des adresses IP (par exemple "DSA.msc/Server =x.x.x.x« where x.x.x.x est une adresse IP).

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        325465Les contrôleurs de domaine Windows 2000 nécessitent le Service Pack 3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003
      • 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 des contrôleurs de domaine exécutant des versions de Windows 2000 qui sont antérieures au Service Pack 3 ne fonctionnent pas correctement.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        325465Les contrôleurs de domaine Windows 2000 nécessitent le Service Pack 3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003
  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 une clé de session forte (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 crypter le trafic de canal sécurisé avec un clé de session forte de 128 bits. L'activation de ce paramètre empêche l'établissement d'un canal sécurisé avec n'importe quel contrôleur de domaine qui ne peut pas crypter un canal sécurisé données avec une clé forte. La désactivation de ce paramètre permet de clés de session de 64 bits.
      • Avant de pouvoir activer ce paramètre sur un membre station de travail ou sur un serveur, tous les contrôleurs de domaine dans le domaine qui le membre appartient doivent être capables de crypter les données des canaux sécurisés avec un nom fort clé de 128 bits. Cela signifie que tous ces contrôleurs de domaine doivent exécuter Windows 2000 ou version ultérieure.
    2. Configuration à risque

      L'activation de le membre de domaine : exiger une clé de session forte (Windows 2000 ou version ultérieure) paramètre est un paramètre de configuration nuisible.
    3. Raisons d'activer ce paramètre
      • Sécuriser les clés de session servent à établir canal de communications entre les ordinateurs membres et contrôleurs de domaine sont beaucoup plus fortes dans Windows 2000 que dans les versions antérieures de Microsoft systèmes d'exploitation.
      • Lorsqu'il est possible, il est conseillé de tirer parti de ces clés de session fortes pour protéger les communications des canaux sécurisés à partir de l'écoute clandestine et de réseau de détournements de sessions. Écoutes clandestines est une forme d'attaque malveillante, où les données de réseau sont en lecture ou modifié en transit. Les données peuvent être modifiées pour masquer ou changer l'expéditeur, ou encore rediriger.
      Important : Un ordinateur qui exécute Windows Server 2008 R2 ou Windows 7 prend en charge uniquement des clés fortes lorsque les canaux sécurisés sont utilisés. Cette restriction empêche une approbation entre un domaine Windows NT 4.0 et de n'importe quel domaine Windows Server 2008 R2. En outre, cette restriction bloque l'appartenance de domaine Windows NT 4.0 d'ordinateurs qui exécutent Windows 7 ou Windows Server 2008 R2, et vice versa.
    4. Raisons de désactiver ce paramètre

      Le domaine contient des ordinateurs membres qui exécutent les systèmes d'exploitation autres que Windows 2000, Windows XP ou Windows Server 2003.
    5. Nom symbolique :

      StrongKey
    6. Chemin d'accès du 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, réinitialisation des canaux sécurisés des relations d'approbation entre Windows NT 4.0 et les domaines Windows 2000 avec l'utilitaire NLTEST échoue. Un message d'erreur « Accès refusé » s'affiche :
      L'approbation relation 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 pas respecté plus et une clé forte est toujours utilisée. Pour cette raison, les approbations de domaines Windows NT 4.0 ne fonctionnent pas plus.
  4. Membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (toujours)
    1. Arrière-plan
      • L'activation de membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (toujours) Impossible d'établir un canal sécurisé avec n'importe quel contrôleur de domaine qui ne peut pas signer ou crypter toutes les données des canaux sécurisés. Pour protéger le trafic d'authentification contre les attaques man-in-the-middle, les attaques de relecture et d'autres types d'attaques réseau, les ordinateurs Windows créent un canal de communication est connu comme un 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 dans un domaine se connecte à une ressource réseau dans un domaine distant. Cette authentification comportant plusieurs domaines, ou l'authentification directe, permet à un ordinateur fonctionnant sous Windows qui s'est joint à un domaine l'accès à la base de données de compte utilisateur dans son domaine et dans tous les domaines approuvés.
      • Pour activer la membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (toujours) configuration sur un ordinateur membre, tous les contrôleurs de domaine dans le domaine auquel appartient le membre doivent être en mesure de signer ou crypter toutes les données des canaux sécurisés. Cela signifie que tous ces contrôleurs de domaine doivent exécuter Windows NT 4.0 avec Service Pack 6 a (SP6a) ou version ultérieure.
      • L'activation de le membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (toujours) automatiquement permet le membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (lorsque cela est possible) paramètre.
    2. Configuration à risque

      L'activation de le membre de domaine : crypter numériquement ou signer les données des canaux sécurisés (toujours) dans des domaines où pas tous les contrôleurs de domaine peuvent signer ou crypter les données du canal sécurisé sont un paramètre de configuration nuisible.
    3. Raisons d'activer ce paramètre

      Le trafic réseau non signé est sensible aux attaques man-in-the-middle, où un intrus intercepte des paquets entre le serveur et le client et les modifie, puis les transfère au client. Lorsque ce problème se produit sur un serveur LDAP Lightweight Directory Access Protocol (), l'agresseur pourrait obliger le client à prendre des décisions basées sur des enregistrements incorrects de l'annuaire LDAP. Vous pouvez réduire le risque d'une telle attaque sur un réseau d'entreprise en mettant en œuvre des mesures de sécurité physiques fortes pour protéger l'infrastructure réseau. En outre, mise en œuvre de la sécurité du protocole Internet (IPSec) mode d'en-tête d'authentification permet d'éviter les attaques man-in-the-middle. Ce mode effectue l'authentification mutuelle et l'intégrité des paquets pour le trafic IP.
    4. Raisons de désactiver ce paramètre
      • Ordinateurs de domaines locaux ou externes ne prennent pas en charge les canaux sécurisés cryptés.
      • Pas tous les contrôleurs de domaine dans le domaine du niveaux de révision de pack de service approprié pour prendre en charge crypté sécurisé canaux.
    5. Nom symbolique :

      StrongKey
    6. Chemin d'accès du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)
    7. Exemples de problèmes de compatibilité
      • Windows NT 4.0 : Ordinateurs membres Windows 2000 ne sera pas en mesure de rejoindre Domaines Windows NT 4.0 et vous recevrez le message d'erreur suivant :
        Le compte n'est pas autorisé à ouvrir une session à partir de cette station.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        281648Message d'erreur : le compte n'est pas autorisé à se connecter depuis cette station
      • Windows NT 4.0 :Domaines Windows NT 4.0 ne sera pas en mesure d'établir une approbation de bas niveau avec un domaine Windows 2000 et reçoivent le message d'erreur suivant :
        Le compte n'est pas autorisé à ouvrir une session à partir de cette station.
        Approbations de bas niveau existantes peuvent également pas authentifier les utilisateurs du domaine approuvé. Certains utilisateurs peuvent avoir des problèmes de connexion au domaine et ils peuvent recevoir un message d'erreur indiquant que le client ne peut pas trouver le domaine.
      • Windows XP :Les clients Windows XP qui sont joints à des domaines Windows NT 4.0 ne sera pas en mesure d'authentifier les tentatives d'ouverture de session et peuvent recevoir le message d'erreur suivant, ou les événements suivants peuvent être enregistrés dans le journal des événements :
        Impossible de se connecter au domaine soit parce que le contrôleur de domaine est en panne ou est indisponible ou parce que votre ordinateur compte n'a pas été trouvé.

        Événement 5723 : La configuration de session à partir de l'ordinateur Nom_Ordinateur l'authentification a échoué. Le nom du compte référencé dans la sécurité base de données est Nom_Ordinateur. L'erreur suivante s'est produite : l'accès est refusé.

        Événement 3227 : La configuration de session sur l'ordinateur Windows NT ou Windows contrôleur de domaine 2000 Nom du serveur pour le domaine Nom de domaine a échoué car Serveur Nom ne prend pas en charge signature ni la clôture de la session Netlogon. Mise à niveau le contrôleur de domaine soit paramétrer l'entrée de Registre RequireSignOrSeal sur Cet ordinateur à 0.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        318266Un client Windows XP ne peut pas ouvrir une session sur un domaine Windows NT 4.0
      • Réseau Microsoft :Les clients Microsoft Network reçoit l'un des messages d'erreur suivants :
        Échec de la connexion : nom d'utilisateur inconnu ou mauvais mot de passe.
        Il n'existe aucune clé de session utilisateur pour le ouverture de session spécifiée.
  5. Client réseau Microsoft : communications signées numériquement (toujours)
    1. Arrière-plan

      Server Message Block (SMB) est le protocole de partage des ressources pris en charge par de nombreux systèmes d'exploitation de Microsoft. Il s'agit de la base de network basic input/output system (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie l'utilisateur et le serveur qui héberge les données. Si des côtés échoue le processus d'authentification, la transmission de données n'aura pas lieu.

      Activation de la signature SMB démarre au cours de 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 de Windows 2000 prend en charge l'authentification mutuelle. L'authentification mutuelle ferme une attaque « man-in-the-middle ». Le protocole d'authentification SMB de Windows 2000 prend également en charge l'authentification des messages. L'authentification des messages permet d'empêcher les attaques par messages actifs. Pour vous donner cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur de vérifient 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 au cours de toutes les sessions de paquet. Si la signature SMB est requise sur un serveur, un client ne peut pas établir une session, à moins que le client est activé ou requise pour la signature SMB.

      Activation de la signature numérique dans les réseaux haute sécurité permet d'empêcher 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 les outils de piratage de session pour interrompre, d'arrêter ou de subtiliser une session en cours. Un attaquant peut intercepter et modifier des paquets SBM non signés, modifier le trafic et puis le transférer à un serveur pour réaliser des actions non souhaitées. Ou bien, l'attaquant pourrait poser en tant que le serveur ou le client après une authentification légitime et ensuite accéder aux données.

      Le protocole SMB qui est utilisé pour le partage de fichiers et d'imprimantes sur des ordinateurs qui exécutent Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l'authentification mutuelle. L'authentification mutuelle détournements de sessions et prend en charge l'authentification des messages. Par conséquent, il empêche les attaques man-in-the-middle. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur, puis vérifient la signature.

      Remarques
      • Sous la forme d'une autre contre-mesure, 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 cryptage IPSec et la signature que vous pouvez utiliser afin de minimiser l'impact sur les performances de l'UC du serveur. Il n'y a pas d'accélérateurs qui sont disponibles pour la signature SMB.

        Pour plus d'informations, consultez le Signer numériquement les communications serveur chapitre sur le site Web MSDN de Microsoft.

        Configurer la signature SMB par le biais de l'éditeur d'objets de stratégie de groupe dans la mesure où une modification d'une valeur de Registre local n'a aucun effet s'il existe une stratégie de domaine prioritaire.
      • Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le Client Service d'annuaire utilise la signature SMB lors de l'authentification avec les serveurs Windows Server 2003 à l'aide de l'authentification NTLM. Toutefois, ces clients n'utilisent pas de signature SMB lorsqu'ils s'authentifient avec ces serveurs à l'aide de l'authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de ces clients de signature SMB. Pour plus d'informations, consultez l'article 10: « sécurité réseau : niveau d'authentification Lan Manager. "
    2. Configuration à risque

      L'exemple suivant est un paramètre de configuration nuisible : en laissant les deux le client réseau Microsoft : communications signées numériquement (toujours) paramètre et le client réseau Microsoft : communications signées numériquement (lorsque le serveur l'accepte) paramètre la valeur « Non défini » ou désactivé. Ces paramètres permettent au redirecteur d'envoyer des mots de passe en texte brut aux serveurs SMB non-Microsoft qui ne prennent pas en charge cryptage de mot de passe lors de l'authentification.
    3. Raisons d'activer ce paramètre

      L'activation de client réseau Microsoft : communications signées numériquement (toujours) exige que les clients à signer le trafic SMB lorsqu'il contacte les serveurs qui ne nécessitent pas la signature SMB. Cela rend les clients moins vulnérables aux détournements de sessions.
    4. Raisons de désactiver ce paramètre
      • L'activation de client réseau Microsoft : communications signées numériquement (toujours) empêche les clients de communiquer avec les serveurs cible qui ne prennent pas en charge la signature SMB.
      • Configuration des ordinateurs pour ignorer toutes les PME/PMI non signé empêche les communications antérieures des programmes et des systèmes d'exploitation à partir de la connexion.
    5. Nom symbolique :

      RequireSMBSignRdr
    6. Chemin d'accès du 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 :Copie des fichiers à partir de Windows XP aux clients pour les serveurs Windows 2000 et de serveurs basés sur Windows Server 2003 peuvent prendre plus de temps.
      • Vous ne serez pas en mesure de mapper un lecteur réseau à partir d'un client avec ce paramètre est activé et vous recevrez l'erreur suivante message :
        Le compte n'est pas autorisé à ouvrir une session à partir de Cette station.
    8. Nécessité d'un redémarrage

      Redémarrez l'ordinateur, ou le service station de travail. Pour ce faire, tapez les commandes suivantes à une invite de commande. Appuyez sur ENTRÉE après chaque commande.
      net stop workstation
      Net start workstation
  6. Serveur réseau Microsoft : communications signées numériquement (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 de Microsoft. Il s'agit de la base de network basic input/output system (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie l'utilisateur et le serveur qui héberge les données. Si des côtés échoue le processus d'authentification, la transmission de données n'aura pas lieu.

        Activation de la signature SMB démarre au cours de 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 de Windows 2000 prend en charge l'authentification mutuelle. L'authentification mutuelle ferme une attaque « man-in-the-middle ». Le protocole d'authentification SMB de Windows 2000 prend également en charge l'authentification des messages. L'authentification des messages permet d'empêcher les attaques par messages actifs. Pour vous donner cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur de vérifient 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 au cours de toutes les sessions de paquet. Si la signature SMB est requise sur un serveur, un client ne peut pas établir une session, à moins que le client est activé ou requise pour la signature SMB.

        Activation de la signature numérique dans les réseaux haute sécurité permet d'empêcher 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 les outils de piratage de session pour interrompre, d'arrêter ou de subtiliser une session en cours. Un attaquant peut intercepter et modifier des paquets de gestionnaire de bande passante de sous-réseau (SBM) non signés, modifier le trafic et puis le transférer à un serveur pour réaliser des actions non souhaitées. Ou bien, l'attaquant pourrait poser en tant que le serveur ou le client après une authentification légitime et ensuite accéder aux données.

        Le protocole SMB qui est utilisé pour le partage de fichiers et d'imprimantes sur des ordinateurs qui exécutent Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l'authentification mutuelle. L'authentification mutuelle détournements de sessions et prend en charge l'authentification des messages. Par conséquent, il empêche les attaques man-in-the-middle. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur, puis vérifient la signature.
      • Sous la forme d'une autre contre-mesure, 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 cryptage IPSec et la signature que vous pouvez utiliser afin de minimiser l'impact sur les performances de l'UC du serveur. Il n'y a pas d'accélérateurs qui sont disponibles pour la signature SMB.
      • Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le Client Service d'annuaire utilise la signature SMB lors de l'authentification avec les serveurs Windows Server 2003 à l'aide de l'authentification NTLM. Toutefois, ces clients n'utilisent pas de signature SMB lorsqu'ils s'authentifient avec ces serveurs à l'aide de l'authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de ces clients de signature SMB. Pour plus d'informations, consultez l'article 10: « sécurité réseau : niveau d'authentification Lan Manager. "
    2. Configuration à risque

      L'exemple suivant est un paramètre de configuration nuisible : l'activation de la serveur réseau Microsoft : communications signées numériquement (toujours) sur les serveurs et contrôleurs de domaine qui sont accessibles par les ordinateurs Windows incompatibles et tiers basés sur le système d'exploitation client dans les 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 via le paramètre de stratégie de groupe prennent en charge SMB la signature. En d'autres termes, tous les ordinateurs clients qui ont ce paramètre 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 serveur réseau Microsoft : communications signées numériquement (toujours) est désactivé, la signature SMB est complètement désactivée. Complètement la désactivation de la signature SMB tous les laisse les ordinateurs plus vulnérable aux détournement de session attaques.
    4. Raisons de désactiver ce paramètre
      • L'activation de ce paramètre peut entraîner la copie de fichiers plus lente et les performances du réseau sur les ordinateurs clients.
      • L'activation de ce paramètre empêche les clients qui ne peut pas négocier la signature SMB de communiquer avec les serveurs et domaine contrôleurs. Cela entraîne des opérations telles que les jointures de domaine, utilisateur et ordinateur l'authentification ou l'accès réseau par des programmes à échouer.
    5. Nom symbolique :

      RequireSMBSignServer
    6. Chemin d'accès du 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 Services d'annuaire (DS) va échouer l'authentification d'ouverture de session et recevront le message d'erreur suivant :
        Le mot de passe de domaine fourni n'est pas Corrigez ou accéder à votre ouverture de session serveur a été refusé.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        811497Message d'erreur lorsque le client Windows 95 ou Windows NT 4.0 ouvre une session sur un domaine Windows Server 2003
      • Windows NT 4.0 : Ordinateurs clients qui exécutent des versions de Windows NT 4.0 antérieures au Service Pack 3 (SP3) sera l'authentification d'ouverture de session a échoué et sera recevoir le message d'erreur suivant :
        Le système n'a pas pu ouvrir une session. Assurez-vous que votre nom d'utilisateur et votre domaine sont corrects, puis entrez votre mot de passe.
        Certains serveurs SMB non-Microsoft prennent en charge uniquement les échanges de mot de passe non crypté lors de l'authentification. (Ces échanges également connu sous le nom des échanges « texte brut ».) Pour Windows NT 4.0 SP3 et versions ultérieures, le redirecteur SMB n'envoie pas un mot de passe non crypté lors de l'authentification à un serveur SMB sauf si vous ajoutez une entrée de Registre spécifique.
        Pour activer les mots de passe non cryptés pour le client SMB sur Windows NT 4.0 Service Pack 3 et versions ultérieures, 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

        Pour plus d'informations sur les rubriques connexes, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
        224287Message d'erreur : erreur système 1240 s'est produite. Le compte n'est pas autorisé à se connecter depuis cette station.
        166730 Les mots de passe non cryptés peuvent provoquer le Service Pack 3 pour ne pas se connecter aux serveurs SMB
      • 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 afin d'empêcher les communications des contrôleurs de domaine ne soient interceptés ou falsifié par des utilisateurs malveillants. Pour les utilisateurs de communiquer 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 des canaux sécurisés. Par défaut, les clients qui exécutent Windows NT 4.0 avec Service Pack 2 (SP2) ou version antérieure et les clients qui exécutent Windows 95 n'ont pas activé la signature des paquets SMB. Par conséquent, ces clients ne peuvent pas être capables de s'authentifier à un contrôleur de domaine Windows Server 2003.
      • Paramètres de stratégie Windows 2000 et Windows Server 2003 : Selon vos besoins spécifiques d'installation et la configuration, nous vous recommandons de définir les paramètres de stratégie suivants à l'entité minimale de portée nécessaire dans la hiérarchie du composant logiciel enfichable Éditeur de stratégie de groupe de la Console MMC :
        • Ordinateur Configuration ordinateur\Paramètres Windows\Paramètres de sécurité : Options
        • Envoyer le mot de passe non crypté pour se connecter aux serveurs SMB de tiers (ce paramètre est pour Windows 2000)
        • Client réseau Microsoft : envoyer un mot de passe non crypté aux serveurs SMB de tiers (ce paramètre est pour Windows Server 2003)

        Remarque : Sur certains serveurs CIFS tiers, tels que les anciennes versions de Samba, vous ne pouvez pas utiliser des mots de passe cryptés.
      • Les clients suivants sont incompatibles avec la serveur réseau Microsoft : communications signées numériquement (toujours) paramètre :
        • Apple Computer, Inc., Mac OS X clients
        • Microsoft MS-DOS (par exemple, les clients réseau Microsoft LAN Manager)
        • Microsoft Windows pour Workgroups clients
        • Clients Microsoft Windows 95 sans le service d'annuaire Client installé
        • Ordinateurs Microsoft Windows NT 4.0 sans Service Pack 3 ou version ultérieure
        • Clients CIFS Novell Netware 6
        • Clients SMB SAMBA qui n'ont pas de prise en charge de la signature SMB
    8. Nécessité d'un redémarrage

      Redémarrez l'ordinateur, ou le service serveur. Pour ce faire, tapez les commandes suivantes à une invite de commande. Appuyez sur ENTRÉE après chaque commande.
      net stop server
      Net start server
  7. Accès réseau : permet la traduction de noms/SID anonymes
    1. Arrière-plan

      Le accès réseau : permet la traduction de noms/SID anonymes paramètre de sécurité détermine si un utilisateur anonyme peut demander Attributs de numéro d'Identification (SID) de sécurité pour un autre utilisateur.
    2. Configuration à risque

      L'activation de la accès réseau : permet la traduction de noms/SID anonymes paramètre est un paramètre de configuration nuisible.
    3. Raisons d'activer ce paramètre

      Si le accès réseau : permet la traduction de noms/SID anonymes paramètre est désactivés, antérieures systèmes d'exploitation ou des applications ne peut pas être en mesure de communiquer avec les domaines Windows Server 2003. Par exemple, systèmes d'exploitation, services ou applications suivantes peuvent ne pas fonctionnent :
      • Service de Windows NT 4.0-accès distant serveurs
      • Microsoft SQL Server qui s'exécutent sur les ordinateurs Windows NT 3.x ou Windows NT 4.0 sur les ordinateurs
      • Service d'accès distant est en cours d'exécution sur les ordinateurs Windows 2000 qui sont trouvent dans les domaines de Windows NT 3.x ou Windows NT 4.0
      • SQL Server qui s'exécute sur les ordinateurs Windows 2000 qui sont situés dans des domaines Windows NT 3.x ou 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 utilisateur comptes de domaines de compte contenant le domaine Windows Server 2003 contrôleurs
    4. Raisons de désactiver ce paramètre

      Si ce paramètre est activé, un utilisateur malveillant pourrait utiliser le SID des administrateurs pour obtenir le nom réel du compte administrateur intégré, même si le compte a été renommé. Cette personne pourrait ensuite utiliser le nom du compte pour lancer une attaque visant à deviner le mot de passe.
    5. Nom symbolique : N/A
    6. Chemin d'accès du Registre : Aucun. Le chemin d'accès spécifié dans le code de l'interface utilisateur.
    7. Exemples de problèmes de compatibilité

      Windows NT 4.0 :Ordinateurs dans les domaines de ressources Windows NT 4.0 affichent le message d'erreur « Compte inconnu » dans l'éditeur ACL si des ressources, y compris les dossiers partagés, les fichiers partagés et les objets de Registre sont sécurisés avec des entités de sécurité qui résident dans les domaines de compte contenant des contrôleurs de domaine Windows Server 2003.
  8. Accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes
    1. Arrière-plan
      • Le accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes paramètre détermine quelles autorisations supplémentaires vont être accordées pour les connexions anonymes à l'ordinateur. Windows autorise les utilisateurs anonymes à effectuer certaines activités, par exemple énumérer les noms des comptes de gestionnaire de comptes de sécurité (SAM) workstation et server et des partages réseau. Par exemple, un administrateur peut utiliser ceci pour accorder l'accès aux utilisateurs dans un domaine approuvé ne conservant pas une approbation réciproque. Une fois une session, un utilisateur anonyme peut avoir le même accès est accordé à tout le monde groupe basé sur le paramètre dans la accès réseau : les autorisations vous permettent de tout le monde s'appliquent aux utilisateurs anonymes paramètre ou la liste de contrôle d'accès discrétionnaire (DACL) de l'objet.

        En général, les connexions anonymes sont demandées par les versions antérieures de clients (clients de bas niveau) au cours de l'installation de la session SMB. Dans ces cas, une trace réseau indique que l'ID du processus (PID) SMB est que le redirecteur du client comme 0xFEFF dans Windows 2000 ou 0xCAFE dans Windows NT RPC peut également tenter d'établir des connexions anonymes.
      • Important Ce paramètre n'a aucun impact sur le domaine contrôleurs. 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é Additional Restrictions pour les connexions anonymes gère le
        RestrictAnonymous
        valeur de Registre. L'emplacement de cette valeur est la suivante
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
        Pour plus d'informations sur la valeur de Registre RestrictAnonymous, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
        246261Comment utiliser la valeur de Registre RestrictAnonymous dans Windows 2000
        143474 Restriction des informations disponibles aux utilisateurs de l'ouverture de session anonyme
    2. Configurations à risque

      L'activation de la accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes paramètre est un paramètre de configuration nuisible à partir d'un point de vue de compatibilité. Sa désactivation est un paramètre de configuration nuisible du point de vue sécurité.
    3. Raisons d'activer ce paramètre

      Un utilisateur non autorisé pourrait répertorier de façon anonyme les noms de compte, puis utilisez 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 signifie que les personnes amener à révéler leurs mot de passe ou des 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 provoque également des problèmes avec des clients de bas niveau (par exemple, les clients Windows NT 3.51 et Windows 95), essaient d'utiliser des ressources sur le serveur.
    5. Nom symbolique :


      RestrictAnonymousSAM
    6. Chemin d'accès du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)
    7. Exemples de problèmes de compatibilité
    • Découverte du réseau SMS ne sera pas en mesure d'obtenir données du système d'exploitation et écrit « Inconnu » dans le Propriété OperatingSystemNameandVersion.
    • Windows 95, Windows 98 :Clients Windows 95 et Windows 98 ne sera pas en mesure de modifier leur mot de passe.
    • Windows NT 4.0 :Ordinateurs membres de NT 4.0 de Windows ne pourront pas être authentifié.
    • Windows 95, Windows 98 :Les ordinateurs Windows 95 et Windows 98 ne sera pas en mesure d'ê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 sera pas en mesure de modifier les mots de passe pour leur compte utilisateur.
  9. Accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes et partages
    1. Arrière-plan
      • Le accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes et partages (également appelé RestrictAnonymous) détermine si anonyme l'énumération des comptes de sécurité Actions et des comptes SAM (Gestionnaire) est autorisé. Windows permet aux utilisateurs anonymes effectuer certaines activités, par exemple énumérer les noms des comptes de domaine (utilisateurs, ordinateurs et groupes) et des partages réseau. Cette méthode est pratique pour exemple, lorsqu'un administrateur veut accorder l'accès aux utilisateurs dans une confiance domaine qui ne maintenance pas une approbation 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é Additional Restrictions pour les connexions anonymes gère le
        RestrictAnonymous
        valeur de Registre. L'emplacement de cette valeur est la suivante :
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
    2. Configuration à risque

      L'activation de la accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes et partages paramètre est un paramètre de configuration nuisible.
    3. Raisons d'activer ce paramètre
      • L'activation de la accès réseau : ne pas autoriser l'énumération anonyme des SAM comptes et partages paramètre empêche l'énumération des comptes SAM et des partages 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é Impossible de répertorier de façon anonyme les noms de compte et 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 signifie que les personnes amener à révéler leurs mot de passe ou certaines des informations de sécurité.
      • Si ce paramètre est activé, il est impossible établir des approbations avec des domaines Windows NT 4.0. Ce paramètre provoque également 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 est impossible d'accorder l'accès aux utilisateurs des 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 anonymement des serveurs de fichiers et impression ne sera pas en mesure de répertorier les ressources réseau partagées sur ces serveurs. Les utilisateurs doivent s'authentifier avant de pouvoir afficher les listes de dossiers et imprimantes partagés.
    5. Nom symbolique :

      RestrictAnonymous
    6. Chemin d'accès du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous
    7. Exemples de problèmes de compatibilité
      • Windows NT 4.0 : Les utilisateurs ne seront pas en mesure de modifier leur mot de passe de Windows NT stations de 4.0 travail lorsque le paramètre RestrictAnonymous est activé sur les contrôleurs de domaine dans le domaine des utilisateurs. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        198941Les utilisateurs ne peuvent pas changer de mot de passe lors de la connexion
      • Windows NT 4.0 :Ajout d'utilisateurs ou groupes globaux à partir de domaines Windows 2000 à des groupes locaux Windows NT 4.0 dans le Gestionnaire des utilisateurs échoue et le message d'erreur suivant s'affiche :
        Il n'existe actuellement aucun serveur d'ouverture de session disponible pour traiter la demande d'ouverture de session.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        296405La valeur de Registre « RestrictAnonymous » peut rompre l'approbation à un domaine Windows 2000
      • Windows NT 4.0 :Windows NT 4.0 sur les ordinateurs ne seront pas en mesure de joindre des domaines lors de l'installation ou à l'aide de l'interface utilisateur de jonction de domaine.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        184538Message d'erreur : un contrôleur de ce domaine est introuvable.
      • Windows NT 4.0 :Établissement d'une approbation de bas niveau avec les domaines de ressources Windows NT 4.0 échouera. Le message d'erreur suivant s'affiche lorsque le paramètre RestrictAnonymous est activé sur le domaine approuvé :
        N'a pas pu trouver un contrôleur de domaine pour ce domaine.
        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        178640Impossible de trouver de contrôleur de domaine lors de l'établissement d'une relation d'approbation
      • Windows NT 4.0 :Les utilisateurs qui ouvrent une session des ordinateurs fonctionnant sous Windows NT 4.0 Terminal Server mappe sur le répertoire par défaut au lieu du répertoire de base est défini dans le Gestionnaire des utilisateurs pour les domaines.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        236185Les profils utilisateur Terminal Server et les chemins de dossier de base sont ignorés après l'application de SP4 ou version ultérieure
      • Windows NT 4.0 :Contrôleurs de domaine secondaires Windows NT 4.0 (BDC) ne sera pas en mesure de démarrer le service Net Logon, obtenir la liste des explorateurs secondaires ou synchroniser la base de données SAM à partir de Windows 2000 ou à partir des contrôleurs de domaine Windows Server 2003 dans le même domaine.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        293127Le service Net Logon d'un BDC Windows NT 4.0 ne fonctionne pas dans un domaine Windows 2000
      • Windows 2000 :Les ordinateurs membres Windows 2000 dans les domaines Windows NT 4.0 ne sera pas en mesure d'afficher les imprimantes dans les domaines externes si le paramètre Aucun accès sans autorisation explicite est activé dans la stratégie de sécurité locale du client ordinateur.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        280329Utilisateur ne peut pas gérer ou d'afficher les propriétés de l'imprimante
      • Windows 2000 :Les utilisateurs de domaine Windows 2000 ne sera pas en mesure d'ajouter des imprimantes réseau à partir d'Active Directory ; Toutefois, ils seront en mesure d'ajouter des imprimantes après que les avoir sélectionnées dans l'arborescence.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        318866Les clients Outlook ne peut pas afficher la liste d'adresses globale après l'installation du Security Rollup Package 1 (SRP1) sur le serveur de catalogue global
      • Windows 2000 :Sur les ordinateurs Windows 2000, l'éditeur ACL ne sera pas en mesure d'ajouter des utilisateurs ou groupes globaux à partir de domaines Windows NT 4.0 approuvés.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        296403La valeur RestrictAnonymous rompt l'approbation dans un environnement de domaine mixte
      • L'outil ADMT version 2:Migration de mot de passe pour les comptes d'utilisateurs sont migrés entre forêts avec outil Active Directory Migration (ADMT) version 2 échoue.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        322981Comment faire pour résoudre les problèmes de migration de mot de passe entre forêts avec ADMTv2
      • Les clients outlook :La liste d'adresses globale s'affiche vide pour les clients Microsoft Exchange Outlook.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        318866Les clients Outlook ne peut pas afficher la liste d'adresses globale après l'installation du Security Rollup Package 1 (SR) sur le serveur de catalogue global
        321169 Ralentissement des performances SMB lors de la copie de fichiers de Windows XP vers un contrôleur de domaine Windows 2000
      • SMS :Découverte du réseau de Microsoft Systems Management Server (SMS) ne sera pas en mesure d'obtenir les informations du système d'exploitation. Par conséquent, il écrit « Inconnu » dans la propriété OperatingSystemNameandVersion de la propriété DDR SMS de l'enregistrement de données de découverte (DDR).

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        229769Comment le Gestionnaire de données de découverte détermine quand générer une demande de configuration client
      • SMS : Lorsque vous utilisez l'Assistant d'utilisateur administrateur SMS pour rechercher des utilisateurs et groupes, aucun utilisateur ou groupe n'apparaît. En outre, les clients avancés ne peuvent pas communiquer avec le Point de gestion. L'accès anonyme est requis sur le Point de gestion.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        302413Aucun utilisateur ou groupe n'est répertoriés dans l'Assistant utilisateur administrateur
      • SMS : Lorsque vous utilisez la fonctionnalité de découverte du réseau dans SMS 2.0 et dans l'Installation du Client distant avec l'option de découverte réseau topologie, client et les systèmes d'exploitation client activée, les ordinateurs peuvent être découvertes mais ne peut ne pas être installé.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        311257Ressources ne sont pas découvertes si les connexions anonymes sont désactivées
  10. Sécurité réseau : niveau d'authentification Lan Manager
    1. Arrière-plan

      L'authentification LAN Manager (LM) est le protocole utilisé pour authentifier les clients Windows pour les opérations de réseau, y compris les jonctions de domaines, l'accès aux ressources réseau et l'authentification utilisateur ou ordinateur. Le niveau d'authentification LM détermine quel protocole d'authentification stimulation/réponse est négocié entre les ordinateurs clients et les serveur. En particulier, le niveau d'authentification LM détermine les protocoles d'authentification que le client va tenter de négocier ou que le serveur acceptera. La valeur est définie pour LmCompatibilityLevel détermine quel protocole d'authentification stimulation/réponse est utilisé pour les ouvertures de session réseau. Cette valeur affecte le niveau de protocole d'authentification qu' utilisent 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 suivantes.
      ValeurParamètreDescription
      0 Envoyer les réponses LM et NTLM &Les clients utilisent l'authentification LM et NTLM et n'utilisent jamais la sécurité de session NTLMv2. Contrôleurs de domaine acceptent l'authentification LM, NTLM et NTLMv2.
      1Envoyer LM et NTLM & - utiliser la sécurité de session NTLMv2 si négociéeLes clients utilisent l'authentification LM et NTLM et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Contrôleurs de domaine acceptent l'authentification LM, NTLM et NTLMv2.
      2Envoyer uniquement les réponses NTLMLes clients utilisent uniquement l'authentification NTLM et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Contrôleurs de domaine acceptent l'authentification LM, NTLM et NTLMv2.
      3Envoyer uniquement les réponses NTLMv2Les clients utilisent uniquement l'authentification NTLMv2 et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Contrôleurs de domaine acceptent l'authentification LM, NTLM et NTLMv2.
      4Envoyer uniquement les réponses NTLMv2 / refuser LMLes clients utilisent uniquement l'authentification NTLMv2 et utilisent 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.
      5Envoyer uniquement les réponses NTLMv2 / refuser LM et NTLM &Les clients utilisent uniquement l'authentification NTLMv2 et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Contrôleurs de domaine refusent l'authentification LM et NTLM et acceptent uniquement l'authentification NTLMv2.
      Remarque : Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le Client Service d'annuaire utilise la signature SMB lors de l'authentification avec les serveurs Windows Server 2003 à l'aide de l'authentification NTLM. Toutefois, ces clients n'utilisent pas de signature SMB lorsqu'ils s'authentifient avec ces serveurs à l'aide de l'authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de ces clients de signature SMB.

      Vérifier le niveau d'authentification LM: Vous devez modifier la stratégie sur le serveur pour autoriser NTLM ou vous devez configurer l'ordinateur client pour prendre en charge NTLMv2.

      Si la stratégie est définie sur (5) envoyer des réponses NTLMv2 \ refuser LM et NTLM & sur l'ordinateur cible auquel vous souhaitez vous connecter, vous devez réduire ce paramètre sur cet ordinateur ou définir la sécurité sur le même paramètre qui se trouve sur l'ordinateur source que vous vous connectez à partir de.

      Trouver l'emplacement où vous pouvez modifier le Gestionnaire de réseau local de niveau d'authentification pour définir le client et le serveur au même niveau. Après avoir trouvé la stratégie qui consiste à définir le Gestionnaire de réseau local au niveau d'authentification, si vous souhaitez vous connecter à et à partir d'ordinateurs qui exécutent des versions antérieures de Windows, réduisez la valeur au moins (1) Envoi LM & NTLM - utiliser NTLM version 2 si négociée la sécurité de session. L'un des effets des paramètres incompatibles sont que si le serveur nécessite l'authentification NTLMv2 (valeur 5), mais le client est configuré pour utiliser LM et NTLMv1 uniquement (valeur 0), l'utilisateur qui essaie d'authentification rencontre un échec d'ouverture de session qui a un mauvais mot de passe et qui incrémente le nombre de mot de passe incorrect. Si le verrouillage de compte est configuré, l'utilisateur peut finalement être verrouillé.

      Par exemple, vous devrez peut-être rechercher sur le contrôleur de domaine, ou vous devrez peut-être examiner les stratégies du contrôleur de domaine.

      Recherche sur le contrôleur de domaine

      Remarque : Il se peut que vous deviez 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 LAN manager, puis cliquez sur une valeur dans la liste.

      Si le paramètre en cours 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 afin de déterminer si la sécurité réseau : niveau d'authentification LAN manager y est défini. Si elle n'est pas définie, examinez les stratégies du contrôleur de domaine.

      Examinerstratégies du contrôleur de domaine
      1. Cliquez sur Démarrer, pointez sur Programmes, puis cliquez sur Outils d'administration.
      2. Dans le Sécurité du contrôleur de domaine stratégie, développez Paramètres de sécurité, puis développez Stratégies locales.
      3. Cliquez sur Options de sécurité.
      4. Double-cliquez sur la sécurité réseau : niveau d'authentification LAN manager, puis cliquez sur une valeur dans la liste.

      Remarque
      • Vous devrez peut-être également vérifier les stratégies qui sont liés au niveau du site, le niveau du domaine ou l'unité d'organisation au niveau (UO) pour déterminer où vous devez configurer le niveau d'authentification LAN manager.
      • Si vous implémentez un paramètre de stratégie de groupe en tant que la 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 de 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 dans l'unité d'organisation du contrôleur de domaine.
      • Il est conseillé de définir le niveau d'authentification LAN manager dans l'entité minimale de portée nécessaire dans la hiérarchie d'application de stratégie.

      Actualisation de la stratégie une fois que vous apportez des modifications. (Si la modification est apportée au niveau de paramètres de sécurité locale, la modification est immédiate. Toutefois, vous devez redémarrer les clients avant de tester.)

      Par défaut, les paramètres de stratégie de groupe sont mises à jour sur les contrôleurs de domaine toutes les cinq minutes. Pour appliquer immédiatement la mise à jour les paramètres de stratégie sur Windows 2000 ou version ultérieure, utilisez la commande gpupdate .

      La commande gpupdate /force met à jour les paramètres de stratégie de groupe locaux et les paramètres de stratégie de groupe basés sur le service d'annuaire Active Directory, y compris les paramètres de sécurité. Cette commande remplace l'option désormais obsolète /refreshpolicy de la commande secedit .

      La commande gpupdate utilise la syntaxe suivante :
      gpupdate [/ target: {ordinateur|utilisateur[}] [/ force] [/ wait :valeur] [/logoff] [/ Boot]

      Appliquer l'objet de stratégie de groupe (GPO) nouvelle à l'aide de la commande gpupdate pour réappliquer manuellement tous les paramètres de stratégie. Pour ce faire, tapez la commande suivante à l'invite de commande et appuyez sur ENTRÉE :
      GPUpdate /Force
      Examinez le journal des événements applications pour vous assurer que le paramètre de stratégie a été appliqué avec succès.

      Sur Windows XP et Windows Server 2003, vous pouvez utiliser le composant logiciel enfichable jeu de stratégie résultant pour afficher le paramètre en cours. Pour ce faire, cliquez surDémarrer, cliquez sur Exécuter, type RSoP.msc, puis cliquez sur OK.

      Si le problème persiste après avoir apporté la modification à la stratégie, redémarrez le serveur Windows et vérifiez que le problème est résolu.

      Remarque : Si vous avez plusieurs contrôleurs de domaine Windows 2000, les contrôleurs de domaine Windows Server 2003 ou les deux, vous devrez peut-être répliquer Active Directory pour vous assurer que ces contrôleurs de domaine ont les modifications de mise à jour immédiatement.

      Le paramètre peut semble être définie pour le paramètre le plus bas dans la stratégie de sécurité locale. Si vous pouvez appliquer le paramètre au moyen d'une base de données de sécurité, vous pouvez également définir le niveau d'authentification LAN manager dans le Registre en modifiant l'entrée LmCompatibilityLevel dans la sous-clé de Registre suivante :
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
      Windows Server 2003 a un nouveau paramètre par défaut à utiliser NTLMv2 uniquement. Par défaut, Windows Server 2003 et des contrôleurs de domaine Windows 2000 Server SP3 ont activé le « serveur réseau Microsoft : communications signées numériquement (toujours) » stratégie. Ce paramètre nécessite le serveur SMB à signer les paquets SMB.Windows Server 2003 ont été modifiées dans la mesure où les contrôleurs de domaine, les serveurs de fichiers, les serveurs d'infrastructure réseau et les serveurs Web dans n'importe quelle organisation nécessitent des paramètres différents pour optimiser leur sécurité.

      Si vous souhaitez implémenter l'authentification NTLMv2 sur votre réseau, vous devez vous assurer que tous les ordinateurs du domaine sont configurés pour utiliser ce niveau d'authentification. Si vous appliquez Active Directory Client Extensions pour Windows 95 ou Windows 98 et Windows NT 4.0, les extensions client utilisent les fonctionnalités d'authentification améliorée disponibles dans NTLMv2. Étant donné que les ordinateurs clients qui exécutent un des système d'exploitation suivant ne sont pas affectés par les objets de stratégie de groupe Windows 2000, vous devrez peut-être configurer ces clients manuellement :
      • 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 pas stocker de valeurs de hachage LAN manager sur la prochaine modification de mot de passe ou définissez la NoLMHash clé de Registre, les clients basés sur Windows 98 et Windows 95 qui n'ont pas le Client Service d'annuaire ne peut pas se connecter au domaine après un changement de mot de passe.

      De nombreux serveurs CIFS tiers, tels que Novell Netware 6 ne sont pas en charge NTLMv2 et utilisent NTLM uniquement. Par conséquent, les niveaux supérieurs à 2 ne permettent pas de connectivité.

      Pour plus d'informations sur la façon de configurer manuellement le niveau d'authentification LAN manager, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
      147706Comment faire pour désactiver l'authentification LM sous Windows NT
      175641 LMCompatibilityLevel et ses effets
      299656 Comment empêcher Windows de stocker un hachage LAN manager de votre mot de passe dans Active Directory et des bases de données SAM locales
      312630 Outlook continue à vous demander vos informations d'identification d'ouverture de session
      Pour plus d'informations sur les niveaux d'authentification LM, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
      239869Comment faire pour activer l'authentification NTLM 2
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Paramètres non restrictifs qui envoient des mots de passe dans en clair et que refuser la négociation NTLMv2.
      • Paramètres restrictifs qui empêchent incompatible clients et les contrôleurs de domaine de négocier un protocole d'authentification commun
      • Exiger l'authentification NTLMv2 sur les ordinateurs membres et sont des contrôleurs de domaine qui exécutent des versions de Windows NT 4.0 au plus tôt le Service Pack 4 (SP4)
      • Exiger l'authentification NTLMv2 sur Windows 95 les clients ou sur les clients Windows 98 qui n'ont pas le répertoire Windows Client des services installé.
      • Si vous cliquez sur pour sélectionner le Nécessite une sécurité de session NTLMv2 case à cocher dans Microsoft Management Console éditeur stratégie de groupe enfichable sur un ordinateur Windows Server 2003 Service Pack 3 Windows 2000 basée ou ordinateur et vous réduisez le niveau d'authentification LAN manager à 0, les deux paramètres entrent en conflit, et le message d'erreur suivant peut s'afficher dans le fichier Secpol.msc ou 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 la Configuration de la sécurité et l'outil d'analyse, consultez le Windows 2000 ou les fichiers d'aide de Windows Server 2003.

        Pour plus d'informations sur la façon d'analyser les niveaux de sécurité sur Windows 2000 et Windows Server 2003, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
        313203Comment analyser la sécurité système dans Windows 2000
        816580 Comment analyser la sécurité système dans Windows Server 2003
    3. Raisons de modifier ce paramètre
      • Vous souhaitez augmenter la commun le plus bas protocole d'authentification pris en charge par les clients et les contrôleurs de domaine votre organisation.
      • Où l'authentification sécurisée est une entreprise exigence, que vous souhaitez interdire la négociation de LM et le NTLM protocoles.
    4. Raisons de désactiver ce paramètre

      Client ou les exigences d'authentification de serveur ou les deux, ont augmenté au point où l'authentification à travers un protocole commun ne peut pas se produire.
    5. Nom symbolique :

      LmCompatibilityLevel
    6. Chemin d'accès du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
    7. Exemples de problèmes de compatibilité
      • Windows Server 2003 :Par défaut, les réponses NTLM envoyer Windows Server 2003 NTLMv2 paramètre 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 version antérieure de client à un serveur Windows Server 2003.
      • Vous installez Windows 2000 Security Rollup Package 1 (SRP1).SRP1 force NTLM version 2 (NTLMv2). Ce package de correctifs a été publié après la publication de Windows 2000 Service Pack 2 (SP2). Pour plus d'informations sur SRP1, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

        311401 Windows 2000 Security Rollup Package 1, janvier 2002
      • Windows 7 et Windows Server 2008 R2: de nombreux serveurs CIFS tiers, tels que les serveurs Novell Netware 6 ou Samba basé sur Linux, ne sont pas en charge NTLMv2 et utilisent NTLM uniquement. Par conséquent, les niveaux supérieurs à « 2 » ne permettent pas de connectivité. Maintenant dans cette version du système d'exploitation, la valeur par défaut pour LmCompatibilityLevel a été modifié en « 3 ». Ainsi, lorsque vous mettez à niveau de Windows, ces systèmes de fichiers tiers peuvent cesser de fonctionner.
      • Les clients Microsoft Outlook peuvent être invités pour les informations d'identification même s'ils sont déjà connectés au domaine. Lorsque les utilisateurs entrent 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 sont incorrectes. Assurez-vous que votre nom d'utilisateur et le domaine sont corrects, puis entrez de nouveau votre mot de passe.
        Lorsque vous démarrez Outlook, vous devrez peut-être utiliser vos informations d'identification même si votre paramètre de sécurité de connexion au réseau est défini sur Passthrough ou à l'authentification par mot de passe. Après avoir tapé vos informations d'identification correctes, vous pouvez recevoir le message d'erreur suivant :
        Les informations d'identification fournies sont incorrectes.
        Une trace du Moniteur réseau peut indiquer que le catalogue global émis une erreur RPC (appel) de procédure distante avec un état 0 x 5. Un état 0 x 5 signifie « Accès refusé ».
      • Windows 2000 :Une capture Moniteur réseau peut afficher les erreurs suivantes dans le NetBIOS sur session de TCP/IP (NetBT) server message block (SMB) :
        Erreur SMB R Search Directory Dos, identificateur d'utilisateur non valide (91) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (5)
      • Windows 2000 : Si un domaine Windows 2000 avec NTLMv2 niveau 2 ou version ultérieure est approuvé par un domaine Windows NT 4.0, les ordinateurs membres Windows 2000 dans la ressource domaine peut rencontrer des erreurs d'authentification.

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        305379Problèmes d'authentification dans Windows 2000 avec des niveaux NTLM 2 supérieurs à 2 dans un domaine Windows NT 4.0
      • Windows 2000 et Windows XP : Par défaut, Windows 2000 et Windows XP définissent l'option de LAN Manager d'authentification au niveau stratégie de sécurité locale sur 0. La valeur 0 signifie « réponses Envoyer LM et NTLM ».

        Remarque : Windows clusters basés sur NT 4.0 doivent utiliser LM pour l'administration.
      • Windows 2000 : Gestion de clusters Windows 2000 n'authentifie pas un noeud à joindre si les deux noeuds font partie d'un 6 a Windows NT 4.0 Service Pack domaine (SP6a).

        Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
        305379Problèmes d'authentification dans Windows 2000 avec des niveaux NTLM 2 supérieurs à 2 dans un domaine Windows NT 4.0
      • L'outil IIS Lockdown (HiSecWeb) définit la valeur de LMCompatibilityLevel sur 5 et la valeur RestrictAnonymous à 2.
      • Services pour Macintosh

        Module d'authentification utilisateur (UAM): Microsoft UAM (Module d'authentification de l'utilisateur) fournit une méthode de chiffrement des mots de passe que vous utilisez pour vous connecter aux serveurs Windows AFP (AppleTalk Filing Protocol). Apple User Authentication Module (UAM) fournit uniquement un minimum ou aucun chiffrement. Par conséquent, votre mot de passe peut être intercepté facilement sur le réseau local ou sur Internet. Bien que le module UAM n'est pas obligatoire, il fournit une authentification chiffrée aux serveurs Windows 2000 qui exécutent les Services pour Macintosh. Cette version prend en charge l'authentification chiffrée NTLMv2 128 bits et une version de 10.1 compatible MacOS X.

        Par défaut, les Services Windows Server 2003 pour le serveur Macintosh autorise uniquement Microsoft Authentication.

        Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants de la Base de connaissances Microsoft.
        834498Client Macintosh ne peut pas se connecter aux Services pour Macintosh sur Windows Server 2003
        838331 Les utilisateurs de Mac OS X ne peut pas ouvrir les dossiers partagés Macintosh sur un serveur Windows Server 2003
      • Windows Server 2008, Windows Server 2003, Windows XP et Windows 2000 : Si vous configurez la valeur de LMCompatibilityLevel sur 0 ou 1, puis configurez la valeur de NoLMHash sur 1, applications et des composants peuvent être refusés l'accès via NTLM. Ce problème se produit car l'ordinateur est configuré pour activer LM mais ne pas d'utiliser des mots de passe stockés par LM.

        Si vous configurez la valeur de NoLMHash sur 1, vous devez configurer la valeur de LMCompatibilityLevel 2 ou version ultérieure.
  11. Sécurité réseau : conditions de signature de client LDAP
    1. Arrière-plan

      La sécurité réseau : conditions de signature de client LDAP paramètre détermine le niveau de signature des données demandé sur compte de clients qui émettent des accès protocole LDAP (Lightweight Directory) BIND demande comme suit :
      • Aucun: la requête LDAP BIND est émise avec l'appelant spécifié Options.
      • Négocier la signature: si la Secure Sockets Layer/Transport Layer Security (SSL/TLS) n'a pas été démarré, la requête LDAP BIND est initiée avec les données LDAP option de signature en outre définie les options spécifiées par l'appelant. Si SSL/TLS a été démarré, la requête LDAP BIND est initiée avec l'appelant spécifié Options.
      • Exiger la signature: c'est le même que négocier la signature. Toutefois, si l'intermédiaire du serveur LDAP saslBindInProgress réponse n'indique pas que la signature du trafic LDAP est requise, l'appelant est Échec de la requête BIND LDAP signalé.
    2. Configuration à risque

      L'activation de la sécurité réseau : conditions de signature de client LDAP paramètre est un paramètre de configuration nuisible. Si vous définissez le serveur pour demander des signatures LDAP, vous devez également configurer la signature LDAP sur le client. N'est ne pas configuré le client pour utiliser des signatures LDAP empêche la communication avec le serveur. Ainsi, l'authentification des utilisateurs, stratégie de groupe paramètres, les scripts d'ouverture de session et autres fonctionnalités à échouer.
    3. Raisons de modifier ce paramètre

      Le trafic réseau non signé est sensible aux attaques man-in-the-middle où un intrus intercepte des paquets entre le client et les serveurs, les modifie et puis les transfère au serveur. Lorsque cela se produit sur un serveur LDAP, un agresseur pourrait obliger le serveur à répondre en fonction de fausses requêtes provenant du client LDAP. Vous pouvez réduire ce risque dans un réseau d'entreprise en mettant en œuvre des mesures de sécurité physiques fortes pour protéger l'infrastructure réseau. En outre, vous pouvez empêcher tous les types d'attaques man-in-the-middle 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 du Registre :
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
  12. Journal des événements : Taille maximale du journal de sécurité
    1. Arrière-plan

      Le journal des événements : taille maximale du journal de sécurité paramètre de sécurité spécifie la taille maximale de l'événement de sécurité journal. Ce journal a une taille maximale de 4 Go. Pour trouver ce paramètre, développez Paramètres de Windows, puis développez Sécurité Paramètres.
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Limiter la taille du journal de sécurité et de la sécurité log, méthode de conservation lors de la Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité paramètre est activé. Voir le « Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité » section de cet article pour plus de détails.
      • Limiter la taille du journal de sécurité ainsi que la sécurité événements d'intérêt sont remplacés.
    3. Raisons d'augmenter ce paramètre

      Exigences de sécurité peuvent imposer que vous augmenter la taille du journal de sécurité pour gérer le détail du journal de sécurité supplémentaires ou à conserver les journaux de sécurité pour une période plus longue.
    4. Raisons de diminuer ce paramètre

      Journaux de l'Observateur d'événements sont des fichiers mappés en mémoire. La valeur maximale taille d'un journal des événements est limitée par la quantité de mémoire physique dans le ordinateur local et par la mémoire virtuelle qui est disponible dans le journal des événements processus. Augmenter la taille du journal au-delà de la quantité de mémoire virtuelle qui est disponible à l'Observateur d'événements n'augmente pas le nombre d'entrées de journal sont maintenue.
    5. Exemples de problèmes de compatibilité

      Windows 2000 :Sont des ordinateurs qui exécutent des versions de Windows 2000 versions antérieures au Service Pack 4 (SP4) peuvent arrêter l'enregistrement des événements dans le journal des événements avant Atteindre la taille qui est spécifié dans le paramètre taille maximale du journal dans l'Observateur d'événements si l'option ne pas remplacer les événements (nettoyage manuel du journal) est activée.

      Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
      312571Le journal des événements arrête l'enregistrement des événements avant d'atteindre la taille maximale du journal
  13. Journal des événements : Conserver le journal de sécurité
    1. Arrière-plan

      Le journal des événements : conserver le journal de sécurité paramètre de sécurité détermine la méthode de « présentation » du journal de sécurité. Pour trouver ce paramètre, développez Paramètres de Windows, puis développez Paramètres de sécurité.
    2. Configurations à risque

      Paramètres de configuration nuisibles sont les suivantes :
      • Incapables de conserver tous les événements de sécurité avant enregistrés ils sont remplacés
      • Configuration de la taille maximale du journal de sécurité définissant trop petite pour que soient les événements de sécurité écrasé
      • Limiter la taille du journal de sécurité et de rétention la méthode alors que la Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécurité sécurité est activé
    3. Raisons d'activer ce paramètre

      Activer ce paramètre uniquement si vous sélectionnez la Remplacer les événements par jours méthode de conservation. 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 la fréquence d'interrogation au moins trois fois. Cela pour permettre à des cycles d'interrogation a échoué.
  14. Accès réseau : tout le monde les autorisations s'appliquent aux utilisateurs anonymes
    1. Arrière-plan

      Par défaut, le accès réseau : les autorisations vous permettent de tout le monde s'appliquent aux 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 tout le monde groupe.
    2. Exemple des problèmes de compatibilité

      La valeur suivante de
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
      [REG_DWORD] = 0 x 0 arrête 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 le domaine de ressources est faible sur le côté de Windows Server 2003. Ce problème se produit car le processus de démarrage de l'approbation après la connexion anonyme initiale ACL serait avec le jeton qui inclut le SID anonyme sur Windows NT 4.0 tout le monde.
    3. Raisons de modifier ce paramètre

      La valeur doit définir sur 0 x 1 ou définie à l'aide d'un objet de stratégie de groupe sur unité d'organisation du contrôleur de domaine pour être : accès réseau : les autorisations vous permettent de tout le monde s'appliquent aux utilisateurs anonymes - activés pour rendre les créations d'approbation possible.

      Remarque : La plupart des autres paramètres de sécurité augmentent en valeur et non à 0 x 0 dans leur état le plus sûr. Une pratique plus sécurisée consisterait à modifier le Registre sur l'émulateur du contrôleur principal de domaine à la place de tous les contrôleurs de domaine. Si le rôle d'émulateur de contrôleur principal de domaine est déplacé pour une raison quelconque, le Registre doit être mis à jour sur le nouveau serveur.

      Un redémarrage est nécessaire après que cette valeur est définie.
    4. Chemin d'accès du Registre
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
  15. Authentification NTLMv2

    Sécurité de session

    La sécurité de session détermine les normes minimales de sécurité pour les sessions client et serveur. Il est conseillé de vérifier les paramètres de stratégie de sécurité suivant dans le composant logiciel enfichable Éditeur de stratégie de groupe de la Console MMC :
    • Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies Locales\options de sécurité
    • La sécurité du réseau : Sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris RPC sécurisé)
    • La sécurité du 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 suivants :
    • Exiger l'intégrité des messages
    • Exiger la confidentialité des messages
    • Exiger de NTLM version 2 la sécurité de session
    • Exiger le cryptage 128 bits
    Le paramètre par défaut n'est aucune exigence.

    Ces stratégies déterminent les normes minimales de sécurité pour une session de communications d'application à application sur un serveur pour un client.

    Historiquement, Windows NT prend en charge deux variantes d'authentification stimulation/réponse pour les ouvertures de session réseau :
    • Stimulation/réponse LM
    • Stimulation/réponse NTLM version 1
    LM permet une interopérabilité avec la base installée de clients et serveurs. NTLM offre une sécurité accrue pour les connexions entre clients et serveurs.

    Les clés de Registre correspondantes sont comme suit :
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"

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

Synchronisation de l'heure

Échec de la synchronisation de l'heure. L'heure est décalée 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

Cliquez ici pour plus d'informations sur la façon de contourner des problèmes de signature SMB
Nous vous conseillons d'installer Service Pack 6 a (SP6a) sur les clients Windows NT 4.0 qui interagissent dans un domaine Windows Server 2003. Clients basés sur Windows 98 Deuxième Édition, Windows 98, des clients et des clients Windows 95 doivent exécuter le Client Service d'annuaire pour effectuer l'authentification NTLMv2. Si les clients Windows NT 4.0 n'ont pas installé Windows NT 4.0 SP6 ou si des clients Windows 95, les clients basés sur Windows 98 et Windows 98SE basés sur les clients effectuent pas le Client Service d'annuaire installé, désactiver la signature SMB dans la stratégie du contrôleur de domaine par défaut sur l'unité d'organisation du contrôleur de domaine et puis lier cette stratégie à toutes les unités d'organisation qui hébergent des contrôleurs de domaine.

Le Directory Services Client pour Windows 98 Deuxième Édition, Windows 98 et Windows 95 effectue la signature SMB avec les serveurs Windows 2003 l'authentification NTLM, mais pas l'authentification NTLMv2. En outre, les serveurs Windows 2000 répondra pas aux demandes de signature SMB de ces clients.

Bien que nous ne le recommandons pas, vous pouvez empêcher la signature SMB est obligatoire 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 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 : communications signées numériquement (toujours) paramètre de stratégie, puis cliquez sur désactivé.
Important : Cette section, la méthode ou la tâche qui va suivre contient des étapes qui vous indiquent la méthode pour modifier le Registre de Windows. Toutefois, des problèmes sérieux peuvent survenir si vous modifiez le Registre de façon incorrecte. Par conséquent, assurez-vous de suivre ces étapes avec une attention toute particulière. Afin de couvrir votre système d'une protection supplémentaire, veuillez sauvegarder le Registre avant d'intervenir pour y apporter des modifications. Ainsi, si à la suite des modifications un problème devait survenir, vous pourrez toujours restaurer le Registre. Pour obtenir des informations sur la marche à suivre pour sauvegarder ou restaurer la Base de Registre, cliquez sur le lien (numéro) ci-dessous et afficher l'article correspondant dans la Base de connaissances Microsoft :
322756 Comment sauvegarder et restaurer le Registre dans Windows
Vous pouvez également désactiver la signature SMB sur le serveur en modifiant le Registre. Pour ce faire, procédez comme suit :
  1. Cliquez sur Démarrer, cliquez sur Exécuter, type Regedit, puis cliquez sur OK.
  2. Recherchez et puis cliquez sur la sous-clé suivante :
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
  3. Cliquez sur le EnableSecuritySignature entrée.
  4. Sur la Modifier menu, cliquez sur Modifier.
  5. Dans le Données de la valeur zone, tapez 0, puis cliquez sur OK.
  6. Quittez l'éditeur du Registre.
  7. Redémarrez l'ordinateur, ou arrêter et puis redémarrez le service serveur. Pour ce faire, tapez les commandes suivantes à une invite de commande et appuyez sur ENTRÉE après chaque commande :
    net stop server
    Net start server
Remarque : La clé correspondante sur l'ordinateur client est dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters
Voici les numéros de code d'erreur traduit pour les codes d'état et les messages d'erreur textuel mentionnés plus haut :
erreur 5
ERROR_ACCESS_DENIED
Accès refusé.
erreur 1326
ERROR_LOGON_FAILURE
Échec de la connexion : nom d'utilisateur inconnu ou mauvais mot de passe.
erreur 1788
ERROR_TRUSTED_DOMAIN_FAILURE
La relation d'approbation entre le domaine principal et le domaine approuvé a échoué.
erreur 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
La relation d'approbation entre cette station de travail et le domaine principal a échoué.
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants de la Base de connaissances Microsoft.
324802Comment faire pour configurer des stratégies de groupe pour définir la sécurité pour les services système dans Windows Server 2003
306771 Message d'erreur « Accès refusé » lorsque vous configurez un cluster Windows Server 2003
101747 Comment faire pour installer l'authentification Microsoft sur un ordinateur Macintosh
161372 Comment faire pour activer la signature SMB dans Windows NT
236414 Impossible d'utiliser des partages lorsque LMCompatibilityLevel est défini sur authentification NTLM 2 uniquement
241338 Client Windows NT LAN Manager version 3 avec la première ouverture de session empêche toute activité de l'ouverture de session ultérieures
262890 Impossible d'obtenir la connexion de lecteur de répertoire de base dans un environnement mixte
308580 Mappages de dossier de base à des serveurs de bas niveau peut ne pas fonctionnent lors de l'ouverture de session
285901 Accès à distance, VPN et RIS clients ne peut pas établir de session avec un serveur est configuré pour accepter uniquement l'authentification NTLM version 2
816585 Comment appliquer des modèles de sécurité prédéfinis dans Windows Server 2003
820281 Vous devez fournir des informations d'identification du compte Windows lorsque vous vous connectez à Exchange Server 2003 à l'aide de la RPC d'Outlook 2003 sur la fonctionnalité HTTP
utilisateur droit sécurité paramètre compatible compatibilité registre sûr groupe stratégie acl droits gpedit pdce

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 823659 - Dernière mise à jour : 07/12/2013 10:20:00 - Révision : 28.1

Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise x64 Edition, Microsoft Windows XP Professional, Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Professionnel, Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows NT Workstation 4.0 Édition Développeur, Microsoft Windows 98 Standard Edition, Microsoft Windows 95

  • kbinfo kbmt KB823659 KbMtfr
Commentaires