Résumé
Les paramètres de sécurité et les attributions de droits utilisateur peuvent être modifiés dans les stratégies locales et les stratégies de groupe pour renforcer la sécurité sur les contrôleurs de domaine et les ordinateurs membres. Cependant, l’inconvénient d’une sécurité accrue est l’introduction d’incompatibilités avec les clients, les services et les programmes.
Cet article décrit les incompatibilités qui peuvent se produire sur les ordinateurs clients Windows XP ou une version antérieure de Windows lorsque vous modifiez des paramètres de sécurité spécifiques et des attributions de droits d’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 :
- Pour Windows 7, voir Gestion des stratégie de groupe pour les professionnels de l’informatique
- Pour Windows 7 et Windows Server 2008 R2, voir Nouveautés de la stratégie de groupe
Remarque : le reste du contenu de cet article concerne Windows XP, Windows Server 2003 et les versions antérieures de Windows.
Windows XP
Pour mieux connaître les paramètres de sécurité mal configurés, utilisez l’outil Éditeur d’objets de stratégie de groupe pour modifier les paramètres de sécurité. Lorsque vous utilisez l’Éditeur d’objets de stratégie de groupe, les attributions de droits utilisateur sont améliorées sur les systèmes d’exploitation suivants :
- Windows XP Professional Service Pack 2 (SP2)
- Windows Server 2003 Service Pack 1 (SP1)
La fonctionnalité améliorée est une boîte de dialogue contenant un lien vers cet article. La boîte de dialogue s’affiche lorsque vous modifiez un paramètre de sécurité ou une attribution de droits utilisateur en un paramètre qui offre moins de compatibilité et est plus restrictif. Si vous modifiez directement le même paramètre de sécurité ou l’attribution des droits utilisateur à l’aide du Registre ou de modèles de sécurité, l’effet est le même que si vous modifiez le 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, de programmes et d’opérations qui sont affectés par des paramètres de sécurité spécifiques ou des attributions de droits d’utilisateur. Toutefois, les exemples ne font pas autorité pour tous les systèmes d’exploitation Microsoft, pour tous les systèmes d’exploitation tiers ou pour toutes les versions de programme concernées. Cet article ne contient pas tous les paramètres de sécurité et toutes les attributions de droits utilisateur.
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 mettre en miroir la forêt de production des manières suivantes :
Versions des systèmes d’exploitation client et serveur, des programmes client et serveur, des versions de Service Packs, des correctifs, des modifications de schéma, des groupes de sécurité, des appartenances à des groupes, des autorisations sur les objets dans le système de fichiers, les dossiers partagés, le Registre, le service Active Directory, les paramètres de stratégie locale et de stratégie de groupe, ainsi que le type et l’emplacement du nombre d’objets.
Tâches administratives effectuées, outils d’administration utilisés et systèmes d’exploitation utilisés pour effectuer des tâches administratives
Opérations effectuées, par exemple :
- Authentification de l’ordinateur et de l’utilisateur
- Réinitialisations de mot de passe par les utilisateurs, les ordinateurs et les administrateurs
- Navigation
- Définition d’autorisations pour le système de fichiers, les dossiers partagés, le registre et les ressources Active Directory à l’aide de l’éditeur ACL dans tous les systèmes d’exploitation clients de tous les domaines de compte ou de ressources à partir de tous les systèmes d’exploitation clients de tous les domaines de compte ou de ressources
- Impression à partir de comptes administratifs et non administratifs
Windows Server 2003 SP1
Avertissements dans Gpedit.msc
Pour aider les clients à savoir qu’ils modifient un droit d’utilisateur ou une option de sécurité qui aurait pu nuire à 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’ensemble de l’entreprise, ils voient une nouvelle icône qui ressemble à un signe de cédez. Ils recevront également un message d’avertissement contenant un lien vers l’article 823659 de la Base de connaissances Microsoft. Le texte de ce message est le suivant :
La modification de ce paramètre peut affecter la compatibilité avec les clients, les services et les applications. Pour plus d’informations, consultez <Droits d’utilisateur ou option de sécurité en cours de modification> (Q823659) Si vous avez été dirigé vers cet article de la Base de connaissances à partir d’un lien dans Gpedit.msc, assurez-vous que vous avez lu et compris l’explication fournie et l’effet possible de la modification de ce paramètre. La liste suivante des droits de l’utilisateur qui contient le texte d’avertissement :
- Accéder à cet ordinateur à partir du réseau
- Ouvrir une session localement
- Contourner la vérification de parcours
- Activer les ordinateurs et les utilisateurs pour la délégation approuvée
Les options de sécurité suivantes répertorient les options de sécurité qui ont un avertissement et un message contextuel :
- Membre de domaine : chiffrer ou signer numériquement les données des canaux sécurisés (toujours)
- Membre de domaine : nécessite une clé de session forte (Windows 2000 ou version ultérieure)
- Contrôleur de domaine : conditions requises pour la signature de serveur LDAP
- Serveur réseau Microsoft : communications signées numériquement (toujours)
- Accès réseau : permet la traduction de noms/SID anonymes
- Accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM
- Sécurité réseau : niveau d’authentification LAN Manager
- Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité
- Accès réseau : conditions requises pour la signature de client LDAP
Informations supplémentaires
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, Windows 2000 et Windows Server 2003.
Droits de l’utilisateur
La liste suivante décrit un droit d’utilisateur, identifie les paramètres de configuration susceptibles de causer des problèmes, décrit pourquoi vous devez l’appliquer et pourquoi vous souhaitez le supprimer, et fournit des exemples de problèmes de compatibilité qui peuvent se produire lorsque le droit d’utilisateur est configuré.
Accéder à cet ordinateur à partir du réseau
Arrière-plan
La capacité d’interagir avec des ordinateurs Windows distants nécessite le droit d’utilisateur Accéder à cet ordinateur à partir du réseau. Voici quelques exemples de ces opérations réseau :
- Réplication d’Active Directory entre les contrôleurs de domaine dans un domaine ou une forêt commune
- Demandes d’authentification adressées aux contrôleurs de domaine par des utilisateurs et des ordinateurs
- Accès aux dossiers partagés, aux imprimantes et à d’autres services système situés sur des ordinateurs distants sur le réseau
Les utilisateurs, ordinateurs et comptes de service gagnent ou perdent le droit d’utilisateur Accéder à cet ordinateur à partir du réseau en étant ajoutés ou supprimés explicitement ou implicitement d’un groupe de sécurité qui s’est vu accorder 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 intégré par un administrateur, ou peut être implicitement ajouté par le système d’exploitation à un groupe de sécurité calculé tel que Utilisateurs de domaine, Utilisateurs authentifiés ou Contrôleurs de domaine d’entreprise.
Par défaut, les comptes d’utilisateurs et les comptes d’ordinateurs disposent du droit Accéder à cet ordinateur à partir de l’utilisateur réseau quand des groupes calculés tels que Tout le monde ou, de préférence, Utilisateurs authentifiés et, pour les contrôleurs de domaine, le groupe Contrôleurs de domaine d’entreprise, sont définis dans l’objet de stratégie de groupe (GPO) des contrôleurs de domaine par défaut.
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Suppression du groupe de sécurité Contrôleurs de domaine d’entreprise de ce droit d’utilisateur
- Suppression du groupe Utilisateurs authentifiés ou d’un groupe explicite qui accorde aux utilisateurs, aux ordinateurs et aux comptes de service le droit d’utilisateur de se connecter aux ordinateurs sur le réseau
- Suppression de tous les utilisateurs et ordinateurs de ce droit d’utilisateur
Raisons d’accorder ce droit d’utilisateur
- L’octroi du droit Accéder à cet ordinateur à partir d’un utilisateur réseau au groupe Contrôleurs de domaine d’entreprise satisfait aux exigences d’authentification requises par la réplication Active Directory pour qu’une réplication ait lieu entre les contrôleurs de domaine de la même forêt.
- Ce droit d’utilisateur permet aux utilisateurs et aux ordinateurs d’accéder aux fichiers partagés, aux imprimantes et aux services système, y compris Active Directory.
- Ce droit d’utilisateur est nécessaire pour accéder au courrier à l’aide des versions antérieures de Microsoft Outlook Web Access (OWA).
Raisons de supprimer ce droit d’utilisateur
- Les utilisateurs qui peuvent connecter leurs ordinateurs au réseau peuvent accéder aux ressources sur les ordinateurs distants pour lesquels ils disposent d’autorisations. Par exemple, ce droit d’utilisateur est requis pour qu’un utilisateur se connecte à des imprimantes partagées et à des dossiers. Si ce droit d’utilisateur est accordé au groupe Tout le monde, et si certains dossiers partagés ont à la fois des autorisations de partage et de système de fichiers NTFS configurées de manière à ce 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, cette situation est peu probable pour les nouvelles installations de Windows Server 2003, car le partage par défaut et les autorisations NTFS dans Windows Server 2003 n’incluent pas le groupe Tout le monde. Pour les systèmes mis à niveau à partir de Microsoft Windows NT 4.0 ou Windows 2000, cette vulnérabilité peut présenter un niveau de risque plus élevé car le partage par défaut et les autorisations de système de fichiers pour ces systèmes d’exploitation ne sont pas aussi restrictifs que les autorisations par défaut dans Windows Server 2003.
- Il n’existe aucune raison valable de supprimer le groupe Contrôleurs de domaine d’entreprise de ce droit d’utilisateur.
- Le groupe Tout le monde est généralement supprimé au profit du groupe Utilisateurs authentifiés. Si le groupe Tout le monde est supprimé, le groupe Utilisateurs authentifiés doit disposer de ce droit d’utilisateur.
- Les domaines Windows NT 4.0 mis à niveau vers Windows 2000 n’accordent pas explicitement le droit Accéder à cet ordinateur à partir de l’utilisateur réseau au groupe Tout le monde, au groupe Utilisateurs authentifiés ou au groupe Contrôleurs de domaine d’entreprise. Par conséquent, lorsque vous supprimez le groupe Tout le monde de la stratégie de domaine Windows NT 4.0, la réplication Active Directory échoue avec un message d’erreur « Accès refusé » après la mise à niveau vers Windows 2000. Winnt32.exe dans Windows Server 2003 évite cette configuration incorrecte en accordant au groupe Contrôleurs de domaine d’entreprise le droit d’utilisateur lors de la mise à niveau des contrôleurs de domaine principaux (PDC) Windows NT 4.0. Accordez ce droit d’utilisateur au groupe Contrôleurs de domaine d’entreprise s’il n’est pas présent dans l’Éditeur d’objets de stratégie de groupe.
Exemples de problèmes de compatibilité
Windows 2000 et Windows Server 2003 : La réplication des partitions suivantes échoue avec des erreurs d’accès refusé signalées par les outils de surveillance tels que REPLMON et REPADMIN ou des événements de réplication dans le journal des événements.
- Partition de schéma Active Directory
- Partition de configuration
- Partition de domaine
- Partition de catalogue global
- Partition d’application
Tous les systèmes d’exploitation réseau Microsoft : L’authentification du compte d’utilisateur à partir d’ordinateurs clients de réseau distant échoue, sauf si l’utilisateur ou un groupe de sécurité dont il est membre dispose de ce droit d’utilisateur.
Tous les systèmes d’exploitation réseau Microsoft : l’authentification de compte à partir de clients de réseau distant échouera, sauf si le compte ou un groupe de sécurité dont le compte est membre dispose de ce droit d’utilisateur. Ce scénario s’applique aux comptes d’utilisateurs, aux comptes d’ordinateurs et aux comptes de service.
Tous les systèmes d’exploitation réseau Microsoft : La suppression de tous les comptes de ce droit d’utilisateur empêchera tout compte d’ouvrir une session sur le domaine ou d’accéder aux ressources réseau. Si des groupes calculés tels que Contrôleurs de domaine d’entreprise, Tout le monde ou Utilisateurs authentifiés sont supprimés, vous devez explicitement accorder à cet utilisateur le droit sur les comptes ou les groupes de sécurité dont il est 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’ordinateurs et à tous les comptes de service.
Tous les systèmes d’exploitation réseau Microsoft : Le compte d’administrateur local utilise un mot de passe « vide ». La connectivité réseau avec des mots de passe vides n’est pas autorisée pour les comptes d’administrateur dans un environnement de domaine. Avec cette configuration, vous pouvez vous attendre à recevoir un message d’erreur « Accès refusé ».
Permettre l’ouverture d’une session locale
Arrière-plan
Les utilisateurs qui tentent d’ouvrir une session sur la console d’un ordinateur Windows (en utilisant le raccourci clavier CTRL+ALT+SUPPR) et les comptes qui tentent de démarrer un service doivent disposer des privilèges d’ouverture de session locale sur l’ordinateur hôte. Des exemples d’opérations d’ouverture de session locale incluent les administrateurs qui ouvrent une session sur les consoles des ordinateurs membres ou les contrôleurs de domaine de l’entreprise, ainsi que les utilisateurs de domaine qui se connectent aux ordinateurs membres pour accéder à leur Bureau à l’aide de comptes non privilégiés. Les utilisateurs qui utilisent une connexion Bureau à distance ou des services Terminal Server doivent disposer du droit d’utilisateur Autoriser l’ouverture d’une session locale sur les ordinateurs de destination qui exécutent Windows 2000 ou Windows XP, car ces modes de connexion sont considérés comme locaux sur l’ordinateur hôte. Les utilisateurs qui se connectent à un serveur sur lequel Terminal Server est activé et qui ne disposent pas de ce droit d’utilisateur peuvent toujours démarrer une session interactive à distance dans des domaines Windows Server 2003 s’ils disposent du droit d’utilisateur Autoriser l’ouverture de session via les services Terminal Server.
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Suppression des groupes de sécurité administratifs, y compris les opérateurs de compte, les opérateurs de sauvegarde, les opérateurs d’impression ou de serveur, et le groupe Administrateurs intégré de la stratégie du contrôleur de domaine par défaut.
- Suppression de comptes de service utilisés par les composants et par les programmes sur les ordinateurs membres et sur les contrôleurs de domaine du domaine de la stratégie du contrôleur de domaine par défaut.
- Suppression des utilisateurs ou des groupes de sécurité qui ouvrent une session sur la console des ordinateurs membres du domaine.
- Suppression des comptes de service définis dans la base de données locale SAM (Security Accounts Manager) des ordinateurs membres ou des ordinateurs du groupe de travail.
- Suppression des comptes d’administration non intégrés qui s’authentifient sur les services Terminal Server qui s’exécutent sur un contrôleur de domaine.
- Ajout explicite ou implicite de tous les comptes d’utilisateur dans le domaine par le biais du groupe Tout le monde au droit d’ouverture de session Refuser l’ouverture de session locale. Cette configuration empêche les utilisateurs d’ouvrir une session sur l’ordinateur d’un membre ou sur un contrôleur de domaine du domaine.
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 au bureau d’un ordinateur de groupe de travail, d’un ordinateur membre ou d’un contrôleur de domaine.
- Les utilisateurs doivent disposer de ce droit d’utilisateur pour ouvrir une session des services Terminal Server sur un ordinateur membre ou un contrôleur de domaine Windows 2000.
Raisons de supprimer ce droit d’utilisateur
- Si vous ne parvenez pas à limiter l’accès de la console à des comptes d’utilisateur légitimes, des utilisateurs non autorisés pourraient télécharger et exécuter du code malveillant pour modifier leurs droits d’utilisateur.
- La suppression du droit d’utilisateur Autoriser l’ouverture d’une session locale empêche les ouvertures de session non autorisées sur les consoles des ordinateurs, comme les contrôleurs de domaine ou les serveurs d’applications.
- La suppression de ce droit d’ouverture de session empêche les comptes hors domaine d’ouvrir une session sur la console des ordinateurs membres du domaine.
Exemples de problèmes de compatibilité
- Windows 2000 Terminal Server : le droit d’utilisateur Autoriser l’ouverture d’une session locale est nécessaire pour ouvrir une session sur les serveurs Terminal Server Windows 2000.
- Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 : Les comptes d’utilisateur doivent disposer de ce droit d’utilisateur pour ouvrir une session sur 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érieures : sur les ordinateurs qui exécutent Windows NT 4.0 et versions ultérieures, si vous ajoutez le droit d’utilisateur Autoriser l’ouverture de session locale, mais que vous accordez implicitement ou explicitement le droit Interdire l’ouverture de session locale, les comptes ne pourront pas se connecter à la console des contrôleurs de domaine.
Contourner la vérification de parcours
Arrière-plan
Le droit d’utilisateur Contourner la vérification de parcours permet à l’utilisateur de parcourir les dossiers du système de fichiers NTFS ou du Registre sans vérifier l’autorisation d’accès spécial aux dossiers de parcours. Le droit d’utilisateur Contournement de la vérification de parcours ne permet pas à l’utilisateur d’afficher le contenu d’un dossier. Il permet à l’utilisateur de parcourir uniquement ses dossiers.
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Suppression des comptes non administratifs qui ouvrent une session sur des ordinateurs Windows 2000 ou Windows Server 2003 qui ne sont pas autorisés à accéder aux fichiers et dossiers du système de fichiers.
- Suppression du groupe Tout le monde de la liste des entités de sécurité qui disposent de ce droit d’utilisateur par défaut. Les systèmes d’exploitation Windows, ainsi que de nombreux programmes, sont conçus dans l’attente que toute personne pouvant accéder légitimement à l’ordinateur disposera du droit d’utilisateur de vérification de contournement de parcours. Par conséquent, la suppression du groupe Tout le monde de la liste des entités de sécurité qui disposent de ce droit d’utilisateur par défaut peut entraîner l’instabilité du système d’exploitation ou l’échec du programme. Il est préférable de laisser ce paramètre à sa valeur par défaut.
Raisons d’accorder ce droit d’utilisateur
Le paramètre par défaut du droit utilisateur Contourner la vérification de parcours est de permettre à tout le monde de contourner la vérification du parcours. Il s’agit du comportement attendu des administrateurs système Windows expérimentés qui configurent les listes de contrôle d’accès (SACL) du système de fichiers en conséquence. Le seul scénario où la configuration par défaut peut entraîner un incident est si l’administrateur qui configure les autorisations ne comprend pas le comportement et s’attend à ce que les utilisateurs qui ne peuvent pas accéder à un dossier parent ne puissent pas accéder au contenu des dossiers enfants.
Raisons de supprimer ce droit d’utilisateur
Pour tenter d’empêcher l’accès aux fichiers ou aux dossiers du système de fichiers, les organisations très préoccupées par la sécurité peuvent être tentées de supprimer le groupe Tout le monde, ou même le groupe Utilisateurs, de la liste des groupes disposant du droit d’utilisateur Contournement de la vérification de parcours.
Exemples de problèmes de compatibilité
Windows 2000, Windows Server 2003 : Si le droit d’utilisateur Contournement de la vérification de parcours est supprimé ou est mal configuré sur les ordinateurs Windows 2000 ou Windows Server 2003, les paramètres de la stratégie de groupe dans le dossier SYVOL ne seront pas répliqués entre les contrôleurs de domaine du domaine.
Windows 2000, Windows XP Professionnel, Windows Server 2003 : les ordinateurs qui exécutent Windows 2000, Windows XP Professionnel ou Windows Server 2003 consigneront les événements 1000 et 1202 et ne pourront pas appliquer la stratégie de l’ordinateur et la stratégie de l’utilisateur lorsque les autorisations requises du système de fichiers sont supprimées de l’arborescence SYSVOL si le droit de l’utilisateur Contournement de la vérification de parcours est supprimé ou est mal configuré.
Windows 2000, Windows Server 2003 : Sur les ordinateurs Windows 2000 ou Windows Server 2003, l’onglet Quota de l’Explorateur Windows disparaît lorsque vous affichez les propriétés d’un volume.
Windows 2000 : Les non-administrateurs qui ouvrent une session sur un serveur Terminal Server Windows 2000 peuvent recevoir le message d’erreur suivant :
Remarque
Userinit.exe erreur d’application. L’application n’a pas réussi à s’initialiser correctement 0xc0000142 cliquez sur OK pour mettre fin à l’application.
Dans 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 risquent de ne pas pouvoir accéder aux dossiers ou fichiers partagés sur des dossiers partagés et de recevoir des messages d’erreur « Accès refusé » s’ils ne disposent pas du droit d’utilisateur Contourner la vérification de parcours.
Windows NT 4.0 : sur les ordinateurs Windows NT 4.0, la suppression du droit d’utilisateur Contourner la vérification de parcours entraîne la suppression des flux de fichiers par une copie de fichier. Si vous supprimez ce droit d’utilisateur, lorsqu’un fichier est copié à partir d’un client Windows ou d’un client Macintosh vers un contrôleur de domaine Windows NT 4.0 qui exécute les Services pour Macintosh, le flux de fichier de destination est perdu et le fichier apparaît sous la forme d’un fichier texte uniquement.
Microsoft Windows 95, Microsoft Windows 98 : sur un ordinateur client qui exécute Windows 95 ou Windows 98, la commande net use * /home échoue avec un message d’erreur « Accès refusé » si le groupe Utilisateurs authentifiés ne dispose pas du droit d’utilisateur Contourner la vérification de parcours.
Outlook Web Access : Les non-administrateurs ne pourront pas se connecter à Microsoft Outlook Web Access et recevront un message d’erreur « Accès refusé » s’ils ne disposent pas du droit d’utilisateur Contourner la vérification de parcours.
Paramètres de sécurité
La liste suivante identifie un paramètre de sécurité. La liste imbriquée fournit une description du paramètre de sécurité, identifie les paramètres de configuration susceptibles de causer des problèmes, décrit pourquoi vous devez appliquer le paramètre de sécurité, puis décrit les raisons pour lesquelles vous souhaiterez peut-être 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 au Registre du paramètre de sécurité. Enfin, des exemples de problèmes de compatibilité pouvant se produire lorsque le paramètre de sécurité est configuré sont fournis.
Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité
Arrière-plan
- Le paramètre Audit : arrêter immédiatement le système s’il n’est pas possible 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 Critères d’évaluation de la sécurité informatique de confiance (TCSEC) et pour les Critères communs d’évaluation de la sécurité des technologies de l’information afin d’empêcher les événements vérifiables si le système d’audit ne peut pas enregistrer ces événements. Si le système d’audit échoue, le système est arrêté et un message d’erreur d’arrêt s’affiche.
- Si l’ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, les preuves critiques ou les informations de dépannage importantes peuvent ne pas être disponibles pour examen après un incident de sécurité.
Configuration risquée
Le paramètre de configuration suivant est nuisible : Le paramètre Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité est activé et la taille du journal des événements de sécurité est limitée par les options Ne pas remplacer les événements (effacer le journal manuellement), Remplacer les événements selon les besoins ou Remplacer les événements plus anciens que le nombre de jours dans l’observateur d’événements. Consultez la section « Exemples de problèmes de compatibilité » pour plus d’informations sur les risques spécifiques pour les ordinateurs qui exécutent la version d’origine de Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 ou Windows 2000 SP3.
Raisons d’activer ce paramètre
Si l’ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, les preuves critiques ou les informations de dépannage importantes peuvent ne pas être disponibles pour examen après un incident de sécurité.
Raisons de désactiver ce paramètre
- Activation de l’audit : arrêter immédiatement le système s’il n’est pas possible de se connecter au paramètre d’audit de sécurité 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 consigné lorsque le journal d’audit de sécurité est saturé et lorsque la méthode de rétention spécifiée est soit l’option Ne pas écraser les événements (effacer le journal manuellement), soit l’option Remplacer les événements antérieurs au nombre de jours.
- La charge administrative liée à l’activation du paramètre Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité peut être très élevée, en particulier si vous activez également l’option Ne pas remplacer les événements (effacer manuellement le journal) pour le journal de sécurité. Ce paramètre prévoit la responsabilité individuelle des actions de l’opérateur. Par exemple, un administrateur peut réinitialiser des autorisations sur tous les utilisateurs, ordinateurs et groupes d’une unité d’organisation (UO) où l’audit a été activé à l’aide du compte d’administrateur intégré ou d’un autre compte partagé, puis refuser de réinitialiser ces autorisations. Toutefois, l’activation du paramètre réduit la robustesse du système, car un serveur peut être contraint de s’arrêter en le submergeant d’événements d’ouverture de session et d’autres événements de sécurité écrits dans le journal de sécurité. En outre, étant donné que l’arrêt n’est pas normal, des dommages irréparables peuvent être causés au système d’exploitation, aux programmes ou aux données. Bien que NTFS garantisse que l’intégrité du système de fichiers sera préservée pendant un arrêt inabusif du système, il ne peut garantir que chaque fichier de données de chaque programme sera toujours utilisable lorsque le système redémarrera.
Nom symbolique :
CrashOnAuditFail
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)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 Windows Server SP3 peuvent arrêter la journalisation des événements avant que la taille spécifiée dans l’option Taille maximale du journal des événements de sécurité ne soit atteinte. Ce bogue est corrigé dans Windows 2000 Service Pack 4 (SP4). Assurez-vous que Windows 2000 Service Pack 4 est installé sur vos contrôleurs de domaine Windows 2000 avant d’envisager d’activer ce paramètre.
Windows 2000, Windows Server 2003 : Les ordinateurs sous Windows 2000 ou Windows Server 2003 peuvent cesser de répondre, puis redémarrer spontanément si l’option Audit : arrêter immédiatement le système s’il n’est pas possible de consigner les audits de sécurité est activé, si le journal de sécurité est saturé et si une entrée existante du journal des événements ne peut pas être remplacée. Lorsque l’ordinateur redémarre, le message d’erreur d’arrêt suivant s’affiche :
Remarque
STOP : C0000244 {Échec de l’audit}
Échec d’une tentative de génération d’audit de sécurité.Pour que la récupération puisse avoir lieu, l’administrateur doit ouvrir une session, archiver le journal de sécurité (facultatif), effacer le journal de sécurité, puis réinitialiser cette option (facultatif et selon vos besoins).
Client réseau Microsoft pour MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP et Windows Server 2003 : Si vous ne parvenez pas à vous connecter à un domaine, le message d’erreur suivant s’affiche :
Remarque
Votre compte est configuré pour vous empêcher d’utiliser cet ordinateur. Essayez un autre ordinateur.
Windows 2000 : Sur les ordinateurs Windows 2000, les non-administrateurs ne pourront pas ouvrir de session sur les serveurs d’accès à distance et recevront un message d’erreur semblable à ce qui suit :
Remarque
Utilisateur inconnu ou mot de passe incorrect
Windows 2000 : Sur les contrôleurs de domaine Windows 2000, le service de messagerie intersite (Ismserv.exe) s’arrête et ne peut pas être redémarré. DCDIAG signale l’erreur en tant que « services de test ISMserv ayant échoué » et l’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 le message « Accès refusé » s’affiche si le journal des événements de sécurité est saturé.
Microsoft Exchange 2000 : les serveurs qui exécutent Exchange 2000 ne pourront pas monter la base de données de la banque d’informations et l’événement 2102 sera enregistré dans le journal des événements.
Outlook, Outlook Web Access : Les non-administrateurs ne peuvent pas accéder à leur courrier par le biais de Microsoft Outlook ou de Microsoft Outlook Web Access, et ils reçoivent une erreur 503.
Contrôleur de domaine : conditions requises pour la signature de serveur LDAP
Arrière-plan
Le paramètre de sécurité Contrôleur de domaine : conditions de signature du serveur LDAP détermine si le serveur LDAP (Lightweight Directory Access Protocol) nécessite que les clients LDAP négocient la signature des données. Les valeurs possibles pour ce paramètre de stratégie sont les suivantes :
- Aucun : la signature de données n’est pas nécessaire pour se lier au serveur. Si le client demande une signature de données, le serveur la prend en charge.
- Exiger la signature : l’option de signature de données LDAP doit être négociée, sauf si TLS/SSL (Transport Layer Security/Secure Socket Layer) est utilisé.
- non défini : ce paramètre n’est pas activé ou désactivé.
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Activation de l’option Exiger la signature dans les environnements où les clients ne prennent pas en charge la signature LDAP ou dans lesquels la signature LDAP côté client n’est pas activée sur le client
- Application du modèle de sécurité Hisecdc.inf Windows 2000 ou Windows Server 2003 dans des environnements où les clients ne prennent pas en charge la signature LDAP ou où la signature LDAP côté client n’est pas activée
- Application du modèle de sécurité Windows 2000 ou Windows Server 2003 Hisecws.inf dans des environnements où les clients ne prennent pas en charge la signature LDAP ou dans lesquels la signature LDAP côté client n’est pas activée
Raisons d’activer ce paramètre
Si le trafic réseau n’est pas signé, il est exposé à des attaques de l’intercepteur (man-in-the-middle attacks), où le pirate intercepte des paquets entre le client et le serveur, les modifie, puis les transfère au serveur. Lorsque ce comportement se produit sur un serveur LDAP, l’attaquant peut obliger le serveur à prendre des décisions basées sur de fausses requêtes provenant du client LDAP. Vous pouvez réduire ce risque dans un réseau d’entreprise en implémentant des mesures de sécurité physique fortes pour protéger l’infrastructure réseau. Le mode d’en-tête d’authentification IPSec (Internet Protocol Security) peut aider à prévenir les attaques de l’intercepteur. Le mode d’en-tête d’authentification effectue l’authentification mutuelle et l’intégrité des paquets pour le trafic IP.
Raisons de désactiver ce paramètre
- Les clients qui ne prennent pas en charge la signature LDAP ne pourront pas effectuer d’interrogations LDAP sur des contrôleurs de domaine et des catalogues globaux si l’authentification NTLM est négociée et si les Service Packs corrects ne sont pas installés sur les contrôleurs de domaine Windows 2000.
- Les traces réseau du trafic LDAP entre les clients et les serveurs seront chiffrées. Cela rend difficile l’examen des conversations LDAP.
- Les serveurs Windows 2000 doivent disposer de Windows 2000 Service Pack 3 (SP3) ou être installés avec des programmes prenant en charge la signature LDAP exécutés à partir d’ordinateurs clients exécutant Windows 2000 SP4, Windows XP ou Windows Server 2003.
Nom symbolique :
LDAPServerIntegrity
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)Exemples de problèmes de compatibilité
Les liaisons simples échouent et vous recevez le message d’erreur suivant :
Remarque
Ldap_simple_bind_s() a échoué : authentification forte requise.
Windows 2000 Service Pack 4, Windows XP et 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 des versions de Windows 2000 antérieures à SP3 lorsque l’authentification NTLM est négociée.
Windows 2000 Service Pack 4, Windows XP Windows Server 2003 : Sur les clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003, certains outils d’administration Active Directory qui ciblent les contrôleurs de domaine qui exécutent des versions de Windows 2000 antérieures à SP3 ne fonctionneront pas correctement s’ils utilisent des adresses IP (par exemple, « dsa.msc /server=x.x.x.x » où
x.x.x.x est une adresse IP).Windows 2000 Service Pack 4, Windows XP et Windows Server 2003 : Sur des clients qui exécutent Windows 2000 SP4, Windows XP ou Windows Server 2003, certains outils d’administration Active Directory ciblant les contrôleurs de domaine qui exécutent des versions de Windows 2000 antérieures à SP3 ne fonctionneront pas correctement.
Membre de domaine : nécessite une clé de session forte (Windows 2000 ou ultérieur)
Arrière-plan
- Le paramètre de clé de session Membre de domaine : Exiger une clé de session forte (Windows 2000 ou ultérieur) détermine si un canal sécurisé peut être établi avec un contrôleur de domaine qui ne peut pas chiffrer le trafic du canal sécurisé avec une clé de session forte de 128 bits. L’activation de ce paramètre empêche l’établissement d’un canal sécurisé avec tout contrôleur de domaine qui ne peut pas chiffrer les données du canal sécurisé avec une clé forte. La désactivation de ce paramètre autorise les clés de session 64 bits.
- Avant de pouvoir activer ce paramètre sur une station de travail membre ou sur un serveur, tous les contrôleurs de domaine du domaine auquel appartient le membre doivent être en mesure de chiffrer les données des canaux sécurisés avec une clé forte de 128 bits. En d’autres termes, tous ces contrôleurs de domaine doivent exécuter Windows 2000 ou une version ultérieure.
Configuration risquée
Activation du paramètre Membre de domaine : Exiger une clé de session forte (Windows 2000 ou ultérieur) est un paramètre de configuration dangereux.
Raisons d’activer ce paramètre
- Les clés de session qui permettent d’établir des communications de canal sécurisées entre les ordinateurs membres et les contrôleurs de domaine sont beaucoup plus puissantes dans Windows 2000 que dans les versions antérieures des systèmes d’exploitation Microsoft.
- Lorsque cela est possible, il est judicieux de tirer parti de ces clés de session plus puissantes pour protéger les communications des canaux sécurisés contre l’écoute clandestine et les attaques de détournement de session. L’écoute clandestine est une forme d’attaque malveillante dans laquelle les données réseau sont lues ou modifiées en transit. Les données peuvent être modifiées pour masquer ou changer l’expéditeur, ou pour le rediriger.
Important Un ordinateur qui exécute Windows Server 2008 R2 ou Windows 7 ne prend en charge que des clés fortes lorsque des canaux sécurisés sont utilisés. Cette restriction empêche toute approbation entre un domaine Windows NT 4.0 et un domaine Windows Server 2008 R2. En outre, cette restriction bloque l’appartenance au domaine Windows NT 4.0 des ordinateurs qui exécutent Windows 7 ou Windows Server 2008 R2, et inversement.
Raisons de désactiver ce paramètre
Le domaine contient des ordinateurs membres qui exécutent des systèmes d’exploitation autres que Windows 2000, Windows XP ou Windows Server 2003.
Nom symbolique :
StrongKey
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)Exemples de problèmes de compatibilité
Windows NT 4.0 : Sur les ordinateurs Windows NT 4.0, la réinitialisation des canaux sécurisés des relations d’approbation entre les domaines Windows NT 4.0 et Windows 2000 avec NLTEST échoue. Un message d’erreur « Accès refusé » s’affiche :
La relation d'approbation entre le domaine principal et le domaine approuvé a échoué.Windows 7 et Server 2008 R2 : pour Windows 7 et les versions ultérieures et Windows Server 2008 R2 et les versions ultérieures, ce paramètre n’est plus honoré et la clé forte est toujours utilisée. C’est pourquoi les approbations avec des domaines Windows NT 4.0 ne fonctionnent plus.
Membre de domaine : chiffrer ou signer numériquement les données des canaux sécurisés (toujours)
Arrière-plan
- L’activation d’un membre de domaine : chiffrer ou signer numériquement les données des canaux sécurisés empêche (toujours) l’établissement d’un canal sécurisé avec un contrôleur de domaine qui ne peut pas signer ou chiffrer toutes les données des canaux sécurisés. Pour protéger le trafic d’authentification contre les attaques de l’intercepteur, les attaques par relecture et d’autres types d’attaques réseau, les ordinateurs Windows créent un canal de communication appelé canal sécurisé via le service d’ouverture de session réseau pour authentifier les comptes d’ordinateur. Les canaux sécurisés sont également utilisés lorsqu’un utilisateur d’un domaine se connecte à une ressource réseau dans un domaine distant. Cette authentification multidomaine, ou authentification directe, permet à un ordinateur Windows qui a rejoint un domaine d’accéder à la base de données des comptes d’utilisateur dans son domaine et dans tous les domaines approuvés.
- Pour activer le paramètre Membre de domaine : Chiffrer numériquement ou signer (toujours) les données du canal sécurisé Sur l’ordinateur d’un membre, tous les contrôleurs de domaine du domaine auquel le membre appartient doivent être en mesure de signer ou de chiffrer 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 6a (SP6a) ou version ultérieure.
- L’activation du paramètre Membre de domaine : chiffrer ou signer numériquement les données des canaux sécurisés (toujours) active automatiquement le paramètre Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (lorsque cela est possible).
Configuration risquée
Activer le paramètre Membre de domaine : chiffrer ou signer numériquement les données du canal sécurisé (toujours) dans les domaines où tous les contrôleurs de domaine ne peuvent pas signer ou chiffrer les données du canal sécurisé est un paramètre de configuration dangereux.
Raisons d’activer ce paramètre
Si le trafic réseau n’est pas signé, il est exposé à des attaques de l’intercepteur, où le pirate intercepte des paquets entre le serveur et le client, puis les modifie avant de les transférer au client. Lorsque ce comportement se produit sur un serveur LDAP (Lightweight Directory Access Protocol), le pirate peut amener un client à prendre des décisions basées sur de faux enregistrements du répertoire LDAP. Vous pouvez réduire le risque d’une telle attaque sur un réseau d’entreprise en implémentant des mesures de sécurité physique fortes pour protéger l’infrastructure réseau. En outre, la mise en œuvre du mode d’en-tête d’authentification IPSec (Internet Protocol Security) peut aider à prévenir les attaques de l’intercepteur. Ce mode effectue l’authentification mutuelle et l’intégrité des paquets pour le trafic IP.
Raisons de désactiver ce paramètre
- Les ordinateurs situés dans des domaines locaux ou externes prennent en charge les canaux sécurisés chiffrés.
- Les niveaux de révision de Service Pack appropriés pour prendre en charge les canaux sécurisés chiffrés ne sont pas tous présents dans le domaine.
Nom symbolique :
StrongKey
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)Exemples de problèmes de compatibilité
Windows NT 4.0 : les ordinateurs membres Windows 2000 ne peuvent pas joindre des domaines Windows NT 4.0 et reçoivent le message d’erreur suivant :
Remarque
Le compte n’est pas autorisé à se connecter depuis cette station.
Pour plus d’informations, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
281648 Message d’erreur : Le compte n’est pas autorisé à se connecter depuis cette station
Windows NT 4.0 : les domaines Windows NT 4.0 ne pourront pas établir d’approbation de niveau inférieur avec un domaine Windows 2000 et recevront le message d’erreur suivant :
Remarque
Le compte n’est pas autorisé à se connecter depuis cette station.
Les approbations de bas niveau existantes peuvent également ne pas authentifier les utilisateurs du domaine approuvé. Certains utilisateurs peuvent rencontrer des problèmes de connexion au domaine et recevoir un message d’erreur indiquant que le client ne trouve pas le domaine.
Windows XP : Les clients Windows XP joints à des domaines Windows NT 4.0 ne peuvent pas 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 :
Remarque
Windows ne peut pas se connecter au domaine, soit parce que le contrôleur de domaine est hors service ou indisponible, soit parce que votre compte d’ordinateur est introuvable
Réseau Microsoft : les clients réseau Microsoft recevront l’un des messages d’erreur suivants :
Remarque
Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect.
Remarque
Il n’existe aucune clé de session utilisateur pour la session d’ouverture de session spécifiée.
Client réseau Microsoft : communications signées numériquement (toujours)
Arrière-plan
SMB (Server Message Block) est le protocole de partage de ressources pris en charge par de nombreux systèmes d’exploitation Microsoft. Il constitue la base du système d’entrée/sortie de base réseau (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie à la fois l’utilisateur et le serveur qui héberge les données. Si l’une ou l’autre des parties échoue au processus d’authentification, la transmission de données n’a pas lieu.
L’activation de la signature SMB commence pendant la négociation du protocole SMB. Les stratégies de signature SMB déterminent si l’ordinateur signe toujours numériquement les communications client.
Le protocole d’authentification SMB Windows 2000 prend en charge l’authentification mutuelle. L’authentification mutuelle met fin à une attaque de l’intercepteur. Le protocole d’authentification SMB Windows 2000 prend également en charge l’authentification des messages. L’authentification des messages permet d’empêcher les attaques de messages actifs. Pour vous fournir cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur vérifient chacun la signature numérique.
Pour utiliser la signature SMB, vous devez activer la signature SMB ou exiger la signature SMB sur le client SMB et le serveur SMB. Si la signature SMB est activée sur un serveur, les clients également activés pour la signature SMB utilisent le protocole de signature de paquets lors de toutes les sessions ultérieures. Si la signature SMB est requise sur un serveur, un client ne peut pas établir de session à moins que le client ne soit activé ou requis pour la signature SMB.
L’activation de la signature numérique dans les réseaux hautement sécurisés permet d’éviter l’usurpation d’identité des clients et des serveurs. Ce type d’usurpation d’identité est connu sous le nom de détournement de session. Un attaquant qui a accès au même réseau que le client ou le serveur utilise des outils de détournement de session pour interrompre, mettre fin ou voler une session en cours. Un attaquant pourrait intercepter et modifier des paquets SMB non signés, modifier le trafic, puis le transférer afin que le serveur puisse effectuer des actions indésirables. Ou l’attaquant peut se faire passer pour le serveur ou le client après une authentification légitime, puis obtenir un accès non autorisé aux données.
Le protocole SMB utilisé pour le partage de fichiers et d’impression sur les ordinateurs sous Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme les attaques de détournement de session et prend en charge l’authentification des messages. Par conséquent, il empêche les attaques de type homme du milieu. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur vérifient ensuite la signature.
Notes
Comme contre-mesure, vous pouvez activer les signatures numériques avec IPSec pour protéger l’ensemble du trafic réseau. Il existe des accélérateurs matériels pour le chiffrement et la signature IPSec que vous pouvez utiliser pour réduire l’impact sur les performances du processeur du serveur. Aucun accélérateur de ce type n’est disponible pour la signature SMB.
Pour plus d’informations, consultez le chapitre Communications serveur signées numériquement sur le site web MSDN de Microsoft.
Configurer la signature SMB via l’Éditeur d’objets de stratégie de groupe, car la modification d’une valeur de Registre local n’a aucun effet en cas de remplacement de stratégie de domaine.
Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB émanant de ces clients. Pour plus d’informations, reportez-vous au point 10 : « Sécurité réseau : niveau d’authentification Lan Manager ».
Configuration risquée
Le paramètre de configuration suivant est nuisible : En laissant à la fois le client réseau Microsoft : paramètre (toujours) des communications signées numériquement et le client réseau Microsoft : le paramètre des communications signées numériquement (si le serveur l’accepte) est défini sur « Non défini » ou est désactivé. Ces paramètres permettent au redirecteur d’envoyer des mots de passe en texte brut à des serveurs SMB non-Microsoft qui ne prennent pas en charge le chiffrement de mot de passe lors de l’authentification.
Raisons d’activer ce paramètre
Activation du client réseau Microsoft : les communications signées numériquement nécessitent (toujours) que les clients signent le trafic SMB lorsqu’ils contactent des serveurs qui ne nécessitent pas de signature SMB. Cela rend les clients moins vulnérables aux attaques de détournement de session.
Raisons de désactiver ce paramètre
- Activation du client réseau Microsoft : les communications signées numériquement empêchent (toujours) les clients de communiquer avec des serveurs cibles qui ne prennent pas en charge la signature SMB.
- La configuration des ordinateurs pour ignorer toutes les communications SMB non signées empêche les programmes et systèmes d’exploitation antérieurs de se connecter.
Nom symbolique :
RequireSMBSignRdr
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignatureExemples 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 de NETDOM, et vous recevrez un message d’erreur « Accès refusé ».
Windows XP : La copie de fichiers à partir de clients Windows XP vers des serveurs Windows 2000 et Windows Server 2003 peut prendre plus de temps.
Vous ne pourrez pas mapper un lecteur réseau à partir d’un client avec ce paramètre activé, et vous recevrez le message d’erreur suivant :
Remarque
Le compte n’est pas autorisé à se connecter depuis cette station.
Exigences en matière de redémarrage
Redémarrez l’ordinateur ou redémarrez le service Station de travail. Pour cela, tapez la commande suivante à l’invite de commandes. Appuyez sur Entrée après chaque commande.
net stop workstation
net start workstation
Serveur réseau Microsoft : communications signées numériquement (toujours)
Arrière-plan
SMB (Server Messenger Block) est le protocole de partage de ressources pris en charge par de nombreux systèmes d’exploitation Microsoft. Il constitue la base du système d’entrée/sortie de base réseau (NetBIOS) et de nombreux autres protocoles. La signature SMB authentifie à la fois l’utilisateur et le serveur qui héberge les données. Si l’une ou l’autre des parties échoue au processus d’authentification, la transmission de données n’a pas lieu.
L’activation de la signature SMB commence pendant la négociation du protocole SMB. Les stratégies de signature SMB déterminent si l’ordinateur signe toujours numériquement les communications client.
Le protocole d’authentification SMB Windows 2000 prend en charge l’authentification mutuelle. L’authentification mutuelle met fin à une attaque de l’intercepteur. Le protocole d’authentification SMB Windows 2000 prend également en charge l’authentification des messages. L’authentification des messages permet d’empêcher les attaques de messages actifs. Pour vous fournir cette authentification, la signature SMB place une signature numérique dans chaque SMB. Le client et le serveur vérifient chacun la signature numérique.
Pour utiliser la signature SMB, vous devez activer la signature SMB ou exiger la signature SMB sur le client SMB et le serveur SMB. Si la signature SMB est activée sur un serveur, les clients également activés pour la signature SMB utilisent le protocole de signature de paquets lors de toutes les sessions ultérieures. Si la signature SMB est requise sur un serveur, un client ne peut pas établir de session à moins que le client ne soit activé ou requis pour la signature SMB.
L’activation de la signature numérique dans les réseaux hautement sécurisés permet d’éviter l’usurpation d’identité des clients et des serveurs. Ce type d’usurpation d’identité est connu sous le nom de détournement de session. Un attaquant qui a accès au même réseau que le client ou le serveur utilise des outils de détournement de session pour interrompre, mettre fin ou voler une session en cours. Un attaquant pourrait intercepter et modifier des paquets SBM (Subnet Bandwidth Manager) non signés, modifier le trafic, puis le transférer afin que le serveur puisse effectuer des actions indésirables. Ou l’attaquant peut se faire passer pour le serveur ou le client après une authentification légitime, puis obtenir un accès non autorisé aux données.
Le protocole SMB utilisé pour le partage de fichiers et d’impression sur les ordinateurs sous Windows 2000 Server, Windows 2000 Professionnel, Windows XP Professionnel ou Windows Server 2003 prend en charge l’authentification mutuelle. L’authentification mutuelle ferme les attaques de détournement de session et prend en charge l’authentification des messages. Par conséquent, il empêche les attaques de type homme du milieu. La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque SMB. Le client et le serveur vérifient ensuite la signature.
Comme contre-mesure, vous pouvez activer les signatures numériques avec IPSec pour protéger l’ensemble du trafic réseau. Il existe des accélérateurs matériels pour le chiffrement et la signature IPSec que vous pouvez utiliser pour réduire l’impact sur les performances du processeur du serveur. Aucun accélérateur de ce type n’est disponible pour la signature SMB.
Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB émanant de ces clients. Pour plus d’informations, reportez-vous au point 10 : « Sécurité réseau : niveau d’authentification Lan Manager ».
Configuration risquée
Le paramètre de configuration suivant est nuisible : Activation du paramètre de communication (toujours) signée numériquement sur les serveurs et sur les contrôleurs de domaine auxquels accèdent des ordinateurs Windows incompatibles et des ordinateurs clients basés sur un système d’exploitation tiers dans des domaines locaux ou externes.
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 la signature SMB. En d’autres termes, tous les ordinateurs clients sur lesquels ce paramètre est activé exécutent Windows 95 avec le client DS installé, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professionnel ou Windows Server 2003.
- Si le serveur réseau Microsoft : communications signées numériquement (toujours) est désactivé, la signature SMB est complètement désactivée. La désactivation complète de toutes les signatures SMB rend les ordinateurs plus vulnérables aux attaques de détournement de session.
Raisons de désactiver ce paramètre
- L’activation de ce paramètre peut ralentir la copie de fichiers et les performances réseau sur les ordinateurs clients.
- L’activation de ce paramètre empêche les clients qui ne peuvent pas négocier la signature SMB de communiquer avec les serveurs et les contrôleurs de domaine. Cela provoque l’échec d’opérations telles que les jonctions de domaines, l’authentification des utilisateurs et des ordinateurs ou l’accès au réseau par des programmes.
Nom symbolique :
RequireSMBSignServer
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)Exemples de problèmes de compatibilité
Windows 95 : Les clients Windows 95 sur lesquels le client Services d’annuaire (DS) n’est pas installé échoueront à l’authentification de connexion et recevront le message d’erreur suivant :
Remarque
Le mot de passe de domaine que vous avez fourni n’est pas correct ou l’accès à votre serveur de connexion a été refusé.
Windows NT 4.0 : l’authentification d’ouverture de session sur les ordinateurs clients exécutant des versions de Windows NT 4.0 antérieures au Service Pack 3 (SP3) échouera à l’authentification de connexion et recevra le message d’erreur suivant :
Remarque
Le système n’a pas pu ouvrir votre session. Assurez-vous que votre nom d’utilisateur et votre domaine sont corrects, puis tapez à nouveau votre mot de passe.
Certains serveurs SMB non-Microsoft ne prennent en charge que les échanges de mots de passe non chiffrés lors de l’authentification. (Ces échanges sont également connus sous le nom d’échanges en « texte brut ».) Pour Windows NT 4.0 SP3 et les versions ultérieures, le redirecteur SMB n’envoie pas de mot de passe non chiffré à un serveur SMB lors de l’authentification, sauf si vous ajoutez une entrée de Registre spécifique.
Pour activer les mots de passe non chiffrés pour le client SMB sur les systèmes Windows NT 4.0 SP 3 et versions ultérieures, modifiez le Registre comme suit : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\ParametersNom de la valeur : EnablePlainTextPassword
Type de données : REG_DWORD
Données : 1
Windows Server 2003 : Par défaut, les paramètres de sécurité des contrôleurs de domaine qui exécutent Windows Server 2003 sont configurés pour empêcher l’interception ou la falsification des communications du contrôleur de domaine par des utilisateurs malveillants. Pour que les utilisateurs communiquent correctement avec un contrôleur de domaine qui exécute Windows Server 2003, les ordinateurs clients doivent utiliser à la fois la signature et le chiffrement SMB ou la signature du trafic de canal sécurisé. Par défaut, les clients qui exécutent Windows NT 4.0 avec Service Pack 2 (SP2) ou une version antérieure installée et ceux qui exécutent Windows 95 n’ont pas activé la signature de paquets SMB. Par conséquent, il se peut que ces clients ne puissent pas s’authentifier sur un contrôleur de domaine basé sur Windows Server 2003.
Paramètres de stratégie Windows 2000 et Windows Server 2003 : En fonction de vos besoins et de votre configuration d’installation, nous vous recommandons de définir les paramètres de stratégie suivants à l’entité la plus basse de l’étendue nécessaire dans la hiérarchie du composant logiciel enfichable Éditeur stratégie de groupe Microsoft Management Console :
- Configuration ordinateur\Paramètres de sécurité Windows\Options de sécurité
- Envoyer un mot de passe non chiffré pour se connecter à des serveurs SMB tiers (ce paramètre est valable pour Windows 2000)
- Client réseau Microsoft : envoyer un mot de passe non chiffré aux serveurs SMB tiers (ce paramètre concerne Windows Server 2003)
Remarque Dans certains serveurs CIFS tiers, tels que les anciennes versions de Samba, vous ne pouvez pas utiliser de mots de passe chiffrés.
Les clients suivants sont incompatibles avec le serveur réseau Microsoft : Paramètre (toujours) des communications signées numériquement :
- Apple Computer, Inc., clients Mac OS X
- Clients réseau Microsoft MS-DOS (par exemple, Microsoft LAN Manager)
- Microsoft Windows pour les clients Workgroups
- Clients Microsoft Windows 95 sans DS Client installé
- Ordinateurs Microsoft Windows NT 4.0 sans SP3 ou version ultérieure installée
- Novell Netware 6 clients CIFS
- Clients SMB SAMBA qui ne prennent pas en charge la signature SMB
Exigences en matière de redémarrage
Redémarrez l’ordinateur ou le service Serveur. Pour cela, tapez la commande suivante à l’invite de commandes. Appuyez sur Entrée après chaque commande.
net stop server
net start server
Accès réseau : permet la traduction de noms/SID anonymes
Arrière-plan
Le paramètre de sécurité Accès réseau : autoriser la traduction de noms/SID anonymes détermine si un utilisateur anonyme peut demander des attributs de numéro d’identification de sécurité (SID) pour un autre utilisateur.
Configuration risquée
Activation de l’accès réseau : autoriser la traduction de noms/SID anonymes est un paramètre de configuration nuisible.
Raisons d’activer ce paramètre
Si le paramètre Accès réseau : autoriser la traduction de noms/SID anonymes est désactivé, il se peut que les systèmes d’exploitation ou applications antérieurs ne puissent pas communiquer avec les domaines Windows Server 2003. Par exemple, les systèmes d’exploitation, services ou applications suivants peuvent ne pas fonctionner :
- Serveurs de service d’accès à distance Windows NT 4.0
- Microsoft SQL Server s’exécutant sur des ordinateurs Windows NT 3.x ou Windows NT 4.0
- Service d’accès à distance qui s’exécute sur des ordinateurs Windows 2000 situés dans des domaines Windows NT 3.x ou Windows NT 4.0
- SQL Server exécuté sur des ordinateurs Windows 2000 situés dans des domaines Windows NT 3.x ou Windows NT 4.0
- Utilisateurs dans le domaine de ressources Windows NT 4.0 qui souhaitent accorder des autorisations pour accéder aux fichiers, aux dossiers partagés et aux objets de Registre à des comptes d’utilisateurs à partir de domaines de compte contenant des contrôleurs de domaine Windows Server 2003
Raisons de désactiver ce paramètre
Si ce paramètre est activé, un utilisateur malveillant peut utiliser le SID Administrateurs bien connu pour obtenir le vrai nom 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 par estimation de mot de passe.
Nom symbolique : N/A
Chemin d’accès au Registre : Aucun. Le chemin d’accès est spécifié dans le code de l’interface utilisateur.
Exemples de problèmes de compatibilité
Windows NT 4.0 : Les ordinateurs dans les domaines de ressources Windows NT 4.0 affichent le message d’erreur « Compte inconnu » dans l’éditeur ACL si les ressources, y compris les dossiers partagés, les fichiers partagés et les objets de registre, sont sécurisées par des entités de sécurité qui résident dans des domaines de compte contenant des contrôleurs de domaine Windows Server 2003.
Accès réseau : ne pas autoriser l’énumération anonyme des comptes SAM
Arrière-plan
Le paramètre Accès réseau : ne pas autoriser l’énumération anonyme des comptes SAM détermine les autorisations supplémentaires qui seront accordées pour les connexions anonymes à l’ordinateur. Windows permet aux utilisateurs anonymes d’effectuer certaines activités, par exemple énumérer les noms des comptes SAM (Security Accounts Manager) des stations de travail et des serveurs et des partages réseau. Par exemple, un administrateur peut utiliser cette commande pour accorder l’accès aux utilisateurs d’un domaine approuvé qui n’utilise pas de confiance réciproque. Une fois qu’une session est établie, un utilisateur anonyme peut avoir le même accès que celui accordé au groupe Tout le monde en fonction du paramètre dans le paramètre Accès réseau : Les autorisations Tout le monde s’appliquent aux utilisateurs anonymes ou à la liste de contrôle d’accès discrétionnaire (DACL) de l’objet.
En règle générale, les connexions anonymes sont demandées par les versions antérieures des clients (clients de bas niveau) lors de la configuration de la session SMB. Dans ce cas, une trace réseau montre que l’ID de processus SMB (PID) est le redirecteur client tel que 0xFEFF dans Windows 2000 ou 0xCAFE dans Windows NT. RPC peut également essayer d’établir des connexions anonymes.
Important : ce paramètre n’a aucun impact sur les contrôleurs de domaine. Sur les contrôleurs de domaine, ce comportement est contrôlé par la présence de « NT AUTHORITY\ANONYMOUS LOGON » dans « Accès compatible pré-Windows 2000 ».
Dans Windows 2000, un paramètre similaire appelé Restrictions supplémentaires pour les connexions anonymes gère la valeur de Registre RestrictAnonymous . L’emplacement de cette valeur est le suivant
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Configurations risquées
Activation de l’accès réseau : ne pas autoriser l’énumération anonyme des comptes SAM est un paramètre de configuration nuisible du point de vue de la compatibilité. Le désactiver est un paramètre de configuration dangereux du point de vue de la sécurité.
Raisons d’activer ce paramètre
Un utilisateur non autorisé peut répertorier de manière anonyme les noms des comptes, puis utiliser ces informations pour tenter de deviner le mot de passe ou d’effectuer des attaques d’ingénierie sociale. L’ingénierie sociale est un jargon qui consiste à inciter les gens à révéler leur mot de passe ou une forme d’information de sécurité.
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 pose également des problèmes avec les clients de bas niveau (tels que les clients Windows NT 3.51 et Windows 95) qui tentent d’utiliser des ressources sur le serveur.
Nom symbolique :
RestrictAnonymousSAM
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)Exemples de problèmes de compatibilité
- La découverte de réseau SMS ne pourra pas obtenir d’informations sur le système d’exploitation et écrira « Unknown » dans la propriété OperatingSystemNameandVersion.
- Windows 95, Windows 98 : les clients Windows 95 et Windows 98 ne pourront pas modifier leurs mots de passe.
- Windows NT 4.0 : l’authentification des ordinateurs membres Windows NT 4.0 ne sera pas possible.
- Windows 95, Windows 98 : les ordinateurs Windows 95 et Windows 98 ne pourront pas être authentifiés par les contrôleurs de domaine Microsoft.
- Windows 95, Windows 98 : les utilisateurs sur les ordinateurs Windows 95 et Windows 98 ne pourront pas modifier les mots de passe de leurs comptes d’utilisateur.
Accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM
Arrière-plan
- Le paramètre Accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM (également appelé RestrictAnonymous) détermine si l’énumération anonyme des comptes et partages SAM (Security Accounts Manager) est autorisée. Windows permet aux utilisateurs anonymes d’effectuer certaines activités, par exemple énumérer les noms des comptes de domaine (utilisateurs, ordinateurs et groupes) et des partages réseau. C’est pratique, par exemple, lorsqu’un administrateur veut accorder l’accès aux utilisateurs d’un domaine approuvé qui n’utilise pas de confiance réciproque. Si vous ne souhaitez pas autoriser l’énumération anonyme des comptes SAM et des partages, activez ce paramètre.
- Dans Windows 2000, un paramètre similaire appelé Restrictions supplémentaires pour les connexions anonymes gère la valeur de Registre RestrictAnonymous . L’emplacement de cette valeur se présente comme suit :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Configuration risquée
Activation de l’accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM est un paramètre de configuration dangereux.
Raisons d’activer ce paramètre
- Activation de l’accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM empêche l’énumération des comptes et partages SAM par les utilisateurs et les ordinateurs qui utilisent des comptes anonymes.
Raisons de désactiver ce paramètre
- Si ce paramètre est activé, un utilisateur non autorisé peut répertorier de manière anonyme les noms des comptes, puis utiliser ces informations pour tenter de deviner les mots de passe ou d’effectuer des attaques d’ingénierie sociale. L’ingénierie sociale est un jargon qui consiste à inciter les gens à révéler leur mot de passe ou toute autre forme d’information de sécurité.
- Si ce paramètre est activé, il sera impossible d’établir des approbations avec des domaines Windows NT 4.0. Ce paramètre entraîne également des problèmes avec les clients de bas niveau, tels que les clients Windows NT 3.51 et Windows 95, qui tentent d’utiliser des ressources sur le serveur.
- Il sera impossible d’accorder l’accès aux utilisateurs 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 aux serveurs de fichiers et d’impression de manière anonyme ne pourront pas répertorier les ressources réseau partagées sur ces serveurs. Les utilisateurs doivent s’authentifier pour pouvoir afficher les listes de dossiers et d’imprimantes partagés.
Nom symbolique :
RestrictAnonymous
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousExemples de problèmes de compatibilité
Windows NT 4.0 : les utilisateurs ne peuvent pas modifier leur mot de passe à partir de stations de travail Windows NT 4.0 lorsque RestrictAnonymous est activé sur les contrôleurs de domaine du domaine des utilisateurs.
Windows NT 4.0 : l’ajout d’utilisateurs ou de groupes globaux à partir de domaines Windows 2000 approuvés à des groupes locaux Windows NT 4.0 dans le Gestionnaire des utilisateurs échoue et le message d’erreur suivant s’affiche :
Remarque
Il n’existe actuellement aucun serveur d’ouverture de session disponible pour répondre à la demande d’ouverture de session.
Windows NT 4.0 : Les ordinateurs Windows NT 4.0 ne pourront pas joindre des domaines pendant la configuration ou l’utilisation de l’interface utilisateur de jonction de domaine.
Windows NT 4.0 : l’établissement d’une approbation de bas niveau avec des domaines de ressources Windows NT 4.0 échoue. Le message d’erreur suivant s’affiche lorsque RestrictAnonymous est activé sur le domaine approuvé :
Remarque
Impossible de trouver le contrôleur de domaine pour ce domaine.
Windows NT 4.0 : les utilisateurs qui se connectent sur des ordinateurs Windows NT 4.0 vont mapper au répertoire de base par défaut au lieu du répertoire de base défini dans le Gestionnaire des utilisateurs pour les domaines.
Windows NT 4.0 : Les contrôleurs de domaine secondaires (BDC) Windows NT 4.0 ne pourront pas démarrer le service d’ouverture de session réseau, obtenir une liste de navigateurs de sauvegarde ou synchroniser la base de données SAM à partir de Windows 2000 ou de contrôleurs de domaine Windows Server 2003 du même domaine.
Windows 2000 : Les ordinateurs membres Windows 2000 dans des domaines Windows NT 4.0 ne pourront pas afficher les imprimantes dans des domaines externes si le paramètre Pas d’accès sans autorisations explicitement anonymes est activé dans la stratégie de sécurité locale de l’ordinateur client.
Windows 2000 : les utilisateurs de domaine Windows 2000 ne pourront pas ajouter d’imprimantes réseau à partir d’Active Directory ; Toutefois, ils pourront ajouter des imprimantes après les avoir sélectionnées dans l’arborescence.
Windows 2000 : Sur les ordinateurs Windows 2000, l’éditeur ACL ne pourra pas ajouter d’utilisateurs ou de groupes globaux à partir de domaines Windows NT 4.0 approuvés.
ADMT version 2 : Échec de la migration des mots de passe pour les comptes d’utilisateurs migrés entre forêts à l’aide de la version 2 de l’outil de migration Active Directory (ADMT).
Pour plus d’informations, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
322981 Comment résoudre les problèmes de migration de mot de passe entre forêts avec ADMTv2Clients Outlook : la liste d’adresses globale apparaîtra vide aux clients Microsoft Exchange Outlook.
SMS : La recherche du réseau Microsoft Systems Management Server (SMS) ne peut pas obtenir les informations sur le système d’exploitation. Par conséquent, elle écrit « Unknown » dans la propriété OperatingSystemNameandVersion de la propriété SMS DDR de l’enregistrement de données de découverte (DDR).
SMS : Lorsque vous utilisez l’Assistant Utilisateur Administrateur SMS pour rechercher des utilisateurs et des groupes, aucun utilisateur ou groupe n’est répertorié. En outre, les clients avancés ne peuvent pas communiquer avec le point de gestion. L’accès anonyme est requis sur le point de gestion.
SMS : Lorsque vous utilisez la fonctionnalité de découverte du réseau dans SMS 2.0 et dans Installation client à distance avec l’option de découverte du réseau de la topologie, du client et des systèmes d’exploitation clients activée, les ordinateurs peuvent être détectés mais non installés.
Sécurité réseau : niveau d’authentification Lan Manager
Arrière-plan
L’authentification LAN Manager (LM) est le protocole utilisé pour authentifier les clients Windows pour les opérations réseau, y compris les jonctions de domaine, l’accès aux ressources réseau et l’authentification d’utilisateur ou d’ordinateur. Le niveau d’authentification LM détermine le protocole d’authentification défi/réponse négocié entre les ordinateurs client et serveur. Plus précisément, le niveau d’authentification LM détermine les protocoles d’authentification que le client tentera de négocier ou que le serveur acceptera. La valeur définie pour LmCompatibilityLevel détermine le protocole d’authentification de défi/réponse utilisé pour les ouvertures de session réseau. Cette valeur affecte le niveau de protocole d’authentification utilisé par les clients, le niveau de sécurité de session négocié et le niveau d’authentification accepté par les serveurs.
Les paramètres possibles sont les suivants.
Valeur Paramètre Description 0 Envoyer des réponses LM & NTLM Les clients utilisent l’authentification LM et NTLM et n’utilisent jamais la sécurité de session NTLMv2. Les contrôleurs de domaine acceptent les authentifications LM, NTLM et NTLMv2. 1 Envoyer des & LM NTLM - utiliser la sécurité de session NTLMv2 si elle est négociée Les clients utilisent l’authentification LM et NTLM, et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent les authentifications LM, NTLM et NTLMv2. 2 Envoyer une réponse NTLM uniquement Les clients utilisent l’authentification NTLM uniquement et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent les authentifications LM, NTLM et NTLMv2. 3 Envoyer une réponse NTLMv2 uniquement Les clients utilisent l’authentification NTLMv2 uniquement et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent les authentifications LM, NTLM et NTLMv2. 4 Envoyer la réponse NTLMv2 uniquement/refuser LM Les clients utilisent l’authentification NTLMv2 uniquement 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 les authentifications NTLM et NTLMv2. 5 Envoyer la réponse NTLMv2 uniquement/refuser LM & NTLM Les clients utilisent l’authentification NTLMv2 uniquement et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent LM et NTLM et acceptent uniquement l’authentification NTLMv2. Remarque Dans Windows 95, Windows 98 et Windows 98 Deuxième Édition, le client des services d’annuaire utilise la signature SMB lorsqu’il s’authentifie auprès des serveurs Windows Server 2003 à l’aide de l’authentification NTLM. Toutefois, ces clients n’utilisent pas la signature SMB lorsqu’ils s’authentifient auprès de ces serveurs à l’aide de l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB émanant de ces clients.
Vérifiez 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 qu’il prenne en charge NTLMv2.
Si la stratégie est définie sur (5) Envoyer une réponse NTLMv2 uniquement\refuser LM & NTLM sur l’ordinateur cible auquel vous souhaitez vous connecter, vous devez soit baisser le paramètre sur cet ordinateur, soit définir la sécurité sur le même paramètre que celui de l’ordinateur source à partir duquel vous vous connectez.
Trouvez l’emplacement correct où vous pouvez modifier le niveau d’authentification du gestionnaire LAN pour régler le client et le serveur au même niveau. Une fois que vous avez trouvé la stratégie qui définit le niveau d’authentification LAN Manager, 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) Envoyer LM & NTLM - utiliser la sécurité de session NTLM version 2 si elle est négociée. L’un des effets des paramètres incompatibles est que si le serveur nécessite NTLMv2 (valeur 5), mais que le client est configuré pour utiliser LM et NTLMv1 uniquement (valeur 0), l’utilisateur qui tente l’authentification rencontre un échec d’ouverture de session qui a un mot de passe incorrect et qui augmente le nombre de mots de passe incorrects. Si le verrouillage du compte est configuré, l’utilisateur peut être verrouillé à terme.
Par exemple, vous devrez peut-être examiner le contrôleur de domaine, ou les stratégies du contrôleur de domaine.
Examiner le contrôleur de domaine
Remarque : Vous devrez peut-être répéter la procédure suivante sur tous les contrôleurs de domaine.
- Cliquez sur Démarrer, pointez sur Programmes, puis cliquez sur Outils d’administration.
- Sous Paramètres de sécurité locaux, développez Stratégies locales.
- Cliquez sur Options de sécurité.
- Double-cliquez sur Sécurité réseau : niveau d’authentification LAN Manager, puis cliquez sur une valeur dans la liste.
Si le paramètre effectif et le paramètre local sont identiques, la stratégie a été modifiée à ce niveau. Si les paramètres sont différents, vous devez vérifier la stratégie du contrôleur de case activée pour déterminer si le paramètre Sécurité réseau : niveau d’authentification du gestionnaire LAN y est défini. S’il n’est pas défini à cet emplacement, examinez les stratégies du contrôleur de domaine.
Examiner les stratégies du contrôleur de domaine
- Cliquez sur Démarrer, pointez sur Programmes, puis cliquez sur Outils d’administration.
- Dans la stratégie de sécurité du contrôleur de domaine , développez Paramètres de sécurité, puis Stratégies locales.
- Cliquez sur Options de sécurité.
- Double-cliquez sur Sécurité réseau : niveau d’authentification LAN Manager, puis cliquez sur une valeur dans la liste.
Remarque
- Vous devrez peut-être également case activée des stratégies liées au niveau du site, du domaine ou de l’unité d’organisation pour déterminer où vous devez configurer le niveau d’authentification du gestionnaire LAN.
- Si vous implémentez un paramètre de stratégie de groupe en tant que 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 de l’unité d’organisation du contrôleur de domaine.
- Il est conseillé de définir le niveau d’authentification du LAN Manager dans l’entité la plus basse de l’étendue nécessaire dans la hiérarchie des applications de stratégie.
Windows Server 2003 dispose d’un nouveau paramètre par défaut pour utiliser uniquement NTLMv2. Par défaut, les contrôleurs de domaine basés sur Windows Server 2003 et Windows 2000 Server SP3 ont activé la stratégie « Serveur réseau Microsoft : communications signées numériquement (toujours) ». Ce paramètre nécessite que le serveur SMB effectue la signature de paquets SMB. Des modifications ont été apportées à Windows Server 2003, car les contrôleurs de domaine, les serveurs de fichiers, les serveurs d’infrastructure réseau et les serveurs Web de n’importe quelle organisation ont besoin de paramètres différents pour optimiser leur sécurité.
Si vous souhaitez mettre en œuvre l’authentification NTLMv2 dans votre réseau, vous devez vous assurer que tous les ordinateurs du domaine sont définis pour utiliser ce niveau d’authentification. Si vous appliquez des extensions clientes Active Directory pour Windows 95 ou Windows 98 et Windows NT 4.0, les extensions clientes utilisent les fonctionnalités d’authentification améliorées disponibles dans NTLMv2. Étant donné que les ordinateurs clients qui exécutent l’un des systèmes d’exploitation suivants ne sont pas concernés par les objets de stratégie de groupe Windows 2000, vous devrez peut-être les configurer 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 stockez pas de valeurs de hachage du gestionnaire de réseau local lors du prochain changement de stratégie de mot de passe ou définissez la clé de Registre NoLMHash , les clients Windows 95 et Windows 98 sur lesquels le client des services d’annuaire n’est pas installé ne peuvent pas ouvrir de session sur le domaine après un changement de mot de passe.
De nombreux serveurs CIFS tiers, tels que Novell Netware 6, ne connaissent pas NTLMv2 et utilisent uniquement NTLM. Par conséquent, les niveaux supérieurs à 2 n’autorisent pas la connectivité. Il existe également des clients SMB tiers qui n’utilisent pas la sécurité de session étendue. Dans ces cas, le niveau LmCompatiblityLevel du serveur de ressources n’est pas pris en considération. Le serveur empaquet ensuite cette demande héritée et l’envoie au contrôleur de domaine utilisateur. Les paramètres du contrôleur de domaine déterminent ensuite quels hachages sont utilisés pour vérifier la demande et si ceux-ci répondent aux exigences de sécurité du contrôleur de domaine.
299656 Comment empêcher Windows de stocker un hachage LAN Manager de votre mot de passe dans Active Directory et les bases de données SAM locales
2701704 événement d’audit affiche le package d’authentification sous la forme NTLMv1 au lieu de NTLMv2 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 :
239869 Comment activer l’authentification NTLM 2
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
Paramètres non restrictifs qui envoient des mots de passe en texte clair et qui refusent la négociation NTLMv2
Paramètres restrictifs qui empêchent les clients ou les contrôleurs de domaine incompatibles de négocier un protocole d’authentification commun
Authentification NTLMv2 obligatoire sur les ordinateurs membres et les contrôleurs de domaine qui exécutent des versions de Windows NT 4.0 antérieures au Service Pack 4 (SP4)
Authentification NTLMv2 requise sur les clients Windows 95 ou Windows 98 sur lesquels le client des services Windows Directory n’est pas installé.
Si vous activez la case à cocher Exiger le case activée de sécurité de session NTLMv2 dans le composant logiciel enfichable Microsoft Management Console stratégie de groupe Editor sur un ordinateur Windows Server 2003 ou Windows 2000 Service Pack 3 et que vous abaissez le niveau d’authentification du gestionnaire LAN à 0, les deux paramètres entrent en conflit et vous risquez de recevoir le message d’erreur suivant dans le fichier Secpol.msc ou le fichier GPEdit.msc :
Remarque
Windows ne peut pas ouvrir la base de données de stratégie locale. Une erreur inconnue s’est produite lors de la tentative d’ouverture de la base de données.
Pour plus d’informations sur l’outil d’analyse et de configuration de la sécurité, consultez les fichiers d’aide de Windows 2000 ou de Windows Server 2003.
Raisons de modifier ce paramètre
- Vous souhaitez augmenter le protocole d’authentification courant le plus bas qui est pris en charge par les clients et les contrôleurs de domaine de votre organization.
- Lorsque l’authentification sécurisée est une exigence métier, vous souhaitez interdire la négociation des protocoles LM et NTLM.
Raisons de désactiver ce paramètre
Les exigences d’authentification client ou serveur, ou les deux, ont été augmentées au point où l’authentification sur un protocole commun ne peut plus avoir lieu.
Nom symbolique :
LmCompatibilityLevel
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevelExemples de problèmes de compatibilité
Windows Server 2003 : par défaut, le paramètre Envoyer des réponses NTLM de Windows Server 2003 NTLMv2 est activé. Par conséquent, Windows Server 2003 reçoit le message d’erreur « Accès refusé » après l’installation initiale lorsque vous essayez de vous connecter à un cluster Windows NT 4.0 ou à des serveurs LanManager V2.1, tels que OS/2 Lanserver. Ce problème se produit également si vous essayez de vous connecter à partir d’un client de version antérieure à un serveur Windows Server 2003.
Vous installez le correctif cumulatif de sécurité 1 de Windows 2000 (SRP1). SRP1 force NTLM version 2 (NTLMv2). Ce package cumulatif a été publié après la publication de Windows 2000 Service Pack 2 (SP2).
Windows 7 et Windows Server 2008 R2 : De nombreux serveurs CIFS tiers, tels que Novell Netware 6 ou les serveurs Samba basés sur Linux, ne connaissent pas NTLMv2 et utilisent uniquement NTLM. Par conséquent, les niveaux supérieurs à « 2 » n’autorisent pas la connectivité. Désormais, dans cette version du système d’exploitation, la valeur par défaut de LmCompatibilityLevel a été remplacée par « 3 ». Par conséquent, lorsque vous mettez à niveau Windows, ces serveurs de fichiers tiers peuvent cesser de fonctionner.
Les clients Microsoft Outlook peuvent être invités à entrer des informations d’identification même s’ils sont déjà connectés au domaine. Lorsque les utilisateurs fournissent leurs informations d’identification, ils reçoivent le message d’erreur suivant : Windows 7 et Windows Server 2008 R2
Remarque
Les informations d’identification d’ouverture de session fournies étaient incorrectes. Assurez-vous que votre nom d’utilisateur et votre domaine sont corrects, puis tapez à nouveau votre mot de passe.
Lorsque vous démarrez Outlook, vous pouvez être invité à entrer vos informations d’identification, même si votre paramètre Sécurité réseau de connexion est défini sur Authentification directe ou par mot de passe. Une fois que vous avez tapé vos informations d’identification correctes, le message d’erreur suivant peut s’afficher :
Remarque
Les informations d’identification de connexion fournies étaient incorrectes.
Une trace du Moniteur réseau peut indiquer que le catalogue global a émis une erreur d’appel de procédure distante (RPC) avec une status de 0x5. Une status de 0x5 signifie « Accès refusé ».
Windows 2000 : Une capture du Moniteur réseau peut afficher les erreurs suivantes dans la session de blocage des messages du serveur (SMB) NetBIOS sur TCP/IP (NetBT) :
Remarque
Répertoire de recherche SMB R Erreur DOS, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Identificateur utilisateur non valide
Windows 2000 : Si un domaine Windows 2000 avec NTLMv2 niveau 2 ou ultérieur est approuvé par un domaine Windows NT 4.0, les ordinateurs membres de Windows 2000 dans le domaine de ressources peuvent rencontrer des erreurs d’authentification.
Windows 2000 et Windows XP : par défaut, Windows 2000 et Windows XP définissent l’option Stratégie de sécurité locale du niveau d’authentification LAN Manager sur 0. Le paramètre 0 signifie « Envoyer des réponses LM et NTLM ».
Remarque Les clusters Windows NT 4.0 doivent utiliser LM pour l’administration.
Windows 2000 : Le clustering Windows 2000 n’authentifie pas un nœud de jonction si les deux nœuds font partie d’un domaine Windows NT 4.0 Service Pack 6a (SP6a).
L’outil de verrouillage IIS (HiSecWeb) définit la valeur LMCompatibilityLevel sur 5 et la valeur RestrictAnonymous sur 2.
Services pour Macintosh
Module d’authentification utilisateur (UAM) : Microsoft UAM (module d’authentification utilisateur) fournit une méthode pour chiffrer les mots de passe que vous utilisez pour vous connecter aux serveurs Windows AFP (AppleTalk Filing Protocol). Le module d’authentification utilisateur (UAM) Apple ne fournit qu’un cryptage minimal ou inexistant. Par conséquent, votre mot de passe pourrait facilement être intercepté sur le réseau local ou sur Internet. Bien que l’UAM ne soit pas obligatoire, elle fournit une authentification chiffrée aux serveurs Windows 2000 qui exécutent des services pour Macintosh. Cette version inclut la prise en charge de l’authentification cryptée NTLMv2 128 bits et une version compatible avec MacOS X 10.1.
Par défaut, le serveur des services Windows Server 2003 pour Macintosh autorise uniquement l’authentification Microsoft.
Windows Server 2008, Windows Server 2003, Windows XP et Windows 2000 : Si vous configurez la valeur LMCompatibilityLevel sur 0 ou 1, puis configurez la valeur NoLMHash sur 1, l’accès des applications et des composants peut être refusé via NTLM. Ce problème se produit car l’ordinateur est configuré pour activer LM mais pas pour utiliser des mots de passe stockés dans LM.
Si vous configurez la valeur NoLMHash sur 1, vous devez configurer la valeur LMCompatibilityLevel sur 2 ou une valeur supérieure.
Sécurité réseau : conditions requises pour la signature de client LDAP
Arrière-plan
Le paramètre d’exigences de signature du client LDAP et de sécurité réseau détermine le niveau de signature de données demandé pour le compte des clients qui émettent des demandes de liaison du protocole LDAP (Lightweight Directory Access Protocol) comme suit :
- Aucun : la demande de liaison LDAP est émise avec les options spécifiées par l’appelant.
- Négocier la signature : si SSL / TLS (Secure Sockets Layer/Transport Layer Security) n’a pas démarré, la demande de liaison LDAP est lancée avec l’option de signature de données LDAP définie en plus des options spécifiées par l’appelant. Si SSL/TLS a été démarré, la demande de liaison LDAP est lancée avec les options spécifiées par l’appelant.
- Exiger la signature : C’est la même chose que la signature de négociation. Toutefois, si la réponse intermédiaire saslBindInProgress du serveur LDAP n’indique pas que la signature du trafic LDAP est requise, l’appelant est informé que la demande de commande LDAP BIND a échoué.
Configuration risquée
L’activation du paramètre Sécurité réseau : conditions requises pour la signature du client LDAP est un paramètre de configuration dangereux. Si vous configurez le serveur pour exiger des signatures LDAP, vous devez également configurer la signature LDAP sur le client. Le fait de ne pas configurer le client pour utiliser des signatures LDAP empêchera la communication avec le serveur. Cela provoque l’échec de l’authentification utilisateur, des paramètres de la stratégie de groupe, des scripts d’ouverture de session et d’autres fonctionnalités.
Raisons de modifier ce paramètre
Si le trafic réseau n’est pas signé, il est exposé à des attaques de l’intercepteur (man-in-the-middle attacks), où le pirate intercepte des paquets entre le client et les serveurs, les modifie, puis les transfère au serveur. Lorsque ce problème se produit sur un serveur LDAP, une personne malveillante peut provoquer la réponse d’un serveur sur la base de requêtes erronées provenant du client LDAP. Vous pouvez réduire ce risque dans un réseau d’entreprise en implémentant des mesures de sécurité physique fortes pour protéger l’infrastructure réseau. En outre, vous pouvez empêcher toutes sortes d’attaques de l’intercepteur en exigeant des signatures numériques sur tous les paquets réseau au moyen d’en-têtes d’authentification IPSec.
Nom symbolique :
LDAPClientIntegrity
Chemin d’accès du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
Journal des événements : Taille maximale du journal de sécurité
Arrière-plan
Le paramètre de sécurité du journal des événements : taille maximale du journal de sécurité, spécifie la taille maximale du journal des événements de sécurité. Ce journal a une taille maximale de 4 Go. Pour localiser ce paramètre, développez
Paramètres Windows, puis développez Paramètres de sécurité.Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Restriction de la taille du journal de sécurité et de la méthode de rétention du journal de sécurité lorsque le paramètre Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité est activé. Pour plus d’informations, reportez-vous à la section « Audit : arrêter immédiatement le système s’il n’est pas possible de se connecter aux audits de sécurité » de cet article.
- Limitation de la taille du journal de sécurité afin que les événements de sécurité pertinents soient remplacés.
Raisons d’augmenter ce paramètre
Les exigences commerciales et de sécurité peuvent vous obliger à augmenter la taille du journal de sécurité pour gérer des détails supplémentaires du journal de sécurité ou pour conserver les journaux de sécurité pendant une période plus longue.
Raisons de la diminution de ce paramètre
Les journaux de l’observateur d’événements sont des fichiers mappés en mémoire. La taille maximale d’un journal des événements est limitée par la quantité de mémoire physique de l’ordinateur local et par la mémoire virtuelle disponible pour le processus du journal des événements. L’augmentation de la taille du journal au-delà de la quantité de mémoire virtuelle disponible pour l’observateur d’événements n’augmente pas le nombre d’entrées de journal conservées.
Exemples de problèmes de compatibilité
Windows 2000 : Les ordinateurs qui exécutent des versions de Windows 2000 antérieures au Service Pack 4 (SP4) peuvent arrêter la journalisation des événements dans le journal des événements avant d’atteindre la taille spécifiée dans le paramètre Taille maximale du journal dans l’observateur d’événements si l’option Ne pas écraser les événements (effacer le journal manuellement) est activée.
Journal des événements : conserver le journal de sécurité
Arrière-plan
Le paramètre de sécurité Journal des événements : Conserver le journal de sécurité détermine la méthode d'« habillage » pour le journal de sécurité. Pour localiser ce paramètre, développez Paramètres Windows, puis Paramètres de sécurité.
Configurations risquées
Les paramètres de configuration suivants sont nuisibles :
- Échec de la conservation de tous les événements de sécurité enregistrés avant leur remplacement
- La configuration du paramètre Taille maximale du journal de sécurité est trop petite pour que les événements de sécurité soient remplacés
- Restriction de la taille du journal de sécurité et de la méthode de rétention pendant la Auditer : arrêter immédiatement le système s’il n’est pas possible de se connecter Le paramètre de sécurité des audits de sécurité est activé
Raisons d’activer ce paramètre
N’activez ce paramètre que si vous sélectionnez la méthode de rétention Remplacer les événements par jours . Si vous utilisez un système de corrélation d’événements qui interroge les événements, assurez-vous que le nombre de jours est au moins trois fois la fréquence d’interrogation. Procédez ainsi pour tenir compte des échecs de cycles d’interrogation.
Accès réseau : les autorisations spécifiques des utilisateurs appartenant au groupe Tout le monde s’appliquent aux utilisateurs anonymes
Arrière-plan
Par défaut, le paramètre Accès réseau : les autorisations spécifiques des utilisateurs appartenant au groupe d’utilisateurs anonymes est défini sur Non défini sur Windows Server 2003. Par défaut, Windows Server 2003 n’inclut pas le jeton d’accès anonyme dans le groupe Tout le monde.
Exemple de problèmes de compatibilité
La valeur suivante de
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 interrompt la création de l’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é sous Windows NT 4.0 et que le domaine de ressources est approuvé du 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 est ACL avec le jeton Tout le monde qui inclut le SID anonyme sous Windows NT 4.0.Raisons de modifier ce paramètre
La valeur doit être définie sur 0x1 ou définie à l’aide d’un GPO sur l’unité d’organisation du contrôleur de domaine pour être : Accès réseau : les autorisations spécifiques des utilisateurs appartenant au groupe Tout le monde s’appliquent aux utilisateurs anonymes : activé pour permettre la création d’approbations.
Remarque : la plupart des autres paramètres de sécurité augmentent au lieu de descendre à 0x0 dans leur état le plus sécurisé. Une pratique plus sûre consisterait à modifier le Registre sur l’émulateur du contrôleur de domaine principal plutôt que sur tous les contrôleurs de domaine. Si le rôle d’émulateur du contrôleur de domaine principal est déplacé pour une raison quelconque, le Registre doit être mis à jour sur le nouveau serveur.
Un redémarrage est nécessaire après la définition de cette valeur.
Chemin d'accès du Registre
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
Authentification NTLMv2
Sécurité de session
La sécurité de session détermine les normes de sécurité minimales pour les sessions client et serveur. Il est judicieux de vérifier les paramètres de stratégie de sécurité suivants dans le composant logiciel enfichable Microsoft Management Console stratégie de groupe Editor :
- Paramètres de l’ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité
- Sécurité réseau : sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris RPC sécurisé)
- Sécurité réseau : sécurité de session minimale pour les clients basés sur NTLM SSP (y compris RPC sécurisé)
Les options de ces paramètres sont les suivantes :
- Exiger l’intégrité du message
- Exiger la confidentialité des messages
- Exiger une sécurité de session NTLM version 2
- Exiger un chiffrement 128 bits
Le paramètre par défaut avant Windows 7 est Aucune configuration. À partir de Windows 7, la valeur par défaut a été modifiée pour exiger le cryptage 128 bits pour une sécurité améliorée. Avec cette valeur par défaut, les appareils hérités qui ne prennent pas en charge le chiffrement 128 bits ne pourront pas se connecter.
Ces stratégies déterminent les normes de sécurité minimales pour une session de communication d’application à application sur un serveur pour un client.
Notez que, bien qu’ils soient décrits comme des paramètres valides, les indicateurs nécessitant l’intégrité et la confidentialité des messages ne sont pas utilisés lorsque la sécurité de la session NTLM est déterminée.
Historiquement, Windows NT prend en charge les deux variantes suivantes d’authentification défi/réponse pour les ouvertures de session réseau :
- Défi / réponse LM
- NTLM version 1 challenge/response
LM permet l’interopérabilité avec la base installée de clients et de serveurs. NTLM fournit une sécurité améliorée pour les connexions entre clients et serveurs.
Les clés de Registre correspondantes sont les suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec »
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec »Configurations risquées
Ce paramètre contrôle la façon dont les sessions réseau sécurisées à l’aide de NTLM sont gérées. Cela affecte les sessions basées sur RPC authentifiées avec NTLM, par exemple. Les risques sont les suivants :
- L’utilisation de méthodes d’authentification plus anciennes que NTLMv2 facilite les attaques de communication en raison des méthodes de hachage plus simples utilisées.
- L’utilisation de clés de chiffrement inférieures à 128 bits permet aux attaquants de rompre les communications à l’aide d’attaques par force brute.
Synchronisation du temps
É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 celle du contrôleur de domaine.
Solution de contournement pour la signature SMB
Il est recommandé d’installer le Service Pack 6a (SP6a) sur les clients Windows NT 4.0 qui interagissent avec un domaine Windows Server 2003. Les clients Windows 98 Deuxième Édition, Windows 98 et Windows 95 doivent exécuter le client des services d’annuaire pour effectuer l’authentification NTLMv2. Si Windows NT 4.0 SP6 n’est pas installé sur les clients Windows NT 4.0 ou si le client des services d’annuaire n’est pas installé sur les clients Windows 95, Windows 98 et Windows 98SE, désactivez la signature SMB dans le paramètre de stratégie du contrôleur de domaine par défaut sur l’unité d’organisation du contrôleur de domaine, puis liez cette stratégie à toutes les unités d’organisation qui hébergent les contrôleurs de domaine.
Le client des services d’annuaire pour Windows 98 Deuxième Édition, Windows 98 et Windows 95 effectuera la signature SMB avec les serveurs Windows 2003 sous l’authentification NTLM, mais pas sous l’authentification NTLMv2. En outre, les serveurs Windows 2000 ne répondent pas aux demandes de signature SMB émanant de ces clients.
Bien que cela ne soit pas recommandé, vous pouvez empêcher la signature SMB d’être requise sur tous les contrôleurs de domaine qui exécutent Windows Server 2003 dans un domaine. Pour configurer ce paramètre de sécurité, procédez comme suit :
- Ouvrez la stratégie du contrôleur de domaine par défaut.
- Ouvrez le dossier Configuration de l’ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité.
- Recherchez et cliquez sur le paramètre de stratégie Serveur réseau Microsoft : communications signées numériquement (toujours), puis cliquez sur Désactivé.
Important : cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Faites attention, car des problèmes sérieux peuvent survenir si vous le modifiez de façon incorrecte. Nous ne saurions trop vous conseiller de suivre ces étapes scrupuleusement. Dans tous les cas, n’oubliez pas de sauvegarder le Registre avant de le modifier. Vous serez alors en mesure de le restaurer en cas de problème. Pour plus d'informations sur la procédure de sauvegarde et de restauration du Registre, cliquez sur le numéro ci-dessous pour 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 :
- Cliquez sur Démarrer, puis sur Exécuter, tapez regedit, puis cliquez sur OK.
- Recherchez la sous-clé suivante et cliquez dessus :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters - Cliquez sur l’entrée enablesecuritysignature .
- Dans le menu Edition, cliquez sur Modifier.
- Dans la zone Données de la valeur , tapez 0, puis cliquez sur OK.
- Quittez l’Éditeur du Registre.
- Redémarrez l’ordinateur, ou arrêtez puis redémarrez le service Serveur. Pour ce faire, tapez les commandes suivantes à l’invite de commandes, puis appuyez sur Entrée après avoir tapé chaque commande :
net stop server
net start server
Remarque La clé correspondante sur l’ordinateur client se trouve dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Vous trouverez ci-dessous la liste des numéros de code d’erreur traduits en codes de status et en messages d’erreur textuels mentionnés plus haut :
Remarque
erreur 5
ERROR_ACCESS_DENIED
Access is denied.
Remarque
erreur 1326
ERROR_LOGON_FAILURE
Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect.
Remarque
Erreur 1788
ERROR_TRUSTED_DOMAIN_FAILURE
La relation d'approbation entre le domaine principal et le domaine approuvé a échoué.
Remarque
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 dans la Base de connaissances Microsoft :
324802 Comment configurer des stratégies de groupe pour définir la sécurité des services système dans Windows Server 2003
816585 Comment appliquer des modèles de sécurité prédéfinis dans Windows Server 2003