Menaces et contre-mesures

Article
02/20/2009

Chapitre 5 : Options de sécurité

Dernière mise à jour le 27 décembre 2005

La section Options de sécurité de la stratégie de groupe active ou désactive les paramètres de sécurité de l'ordinateur pour les signatures numériques de données, les noms de comptes Administrateur et Invité, l'accès aux lecteurs de disquette et de CD-ROM, le comportement d'installation des pilotes et les invites d'ouverture de session. Le classeur Microsoft® Excel® « Windows Default Security and Services Configuration » [Configuration des services et de la sécurité par défaut Windows] (inclus dans la version téléchargeable de ce guide) décrit les paramètres par défaut.

Sur cette page

Paramètres des options de sécurité
Informations complémentaires

Paramètres des options de sécurité

Vous pouvez configurer les paramètres des options de sécurité à l’emplacement suivant de l’Éditeur d’objets de stratégie de groupe :

Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\
Stratégies locales\Options de sécurité

Comptes : État de compte d'administrateur

Ces paramètres de stratégie activent ou désactivent le compte Administrateur pour des conditions de fonctionnement normales. Si vous démarrez un ordinateur en mode sans échec, le compte Administrateur est toujours activé, quelle que soit la configuration de ce paramètre de stratégie.

Le paramètre Comptes : État de compte d'administrateur admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Dans certaines entreprises, maintenir une planification régulière des changements périodiques des mots de passe des comptes locaux peut apparaître comme un défi insurmontable en matière de gestion. Par conséquent, il peut être tentant de désactiver le compte Administrateur intégré plutôt que de s'appuyer sur des changements réguliers de mots de passe pour le protéger de toute attaque. Une autre raison poussant à désactiver ce compte intégré est qu'il ne peut pas être verrouillé, quel que soit le nombre d'échecs d'ouverture de session. Il devient alors une cible privilégiée pour les attaques en force qui tentent de deviner les mots de passe. En outre, ce compte possède un identificateur de sécurité (SID) bien connu et certains outils tiers permettent l'authentification à l'aide du SID plutôt que par le nom du compte. Cela signifie que, même si vous renommez le compte Administrateur, un attaquant pourrait lancer une attaque en force en utilisant le SID pour se connecter.

Contre-mesures

Configurez le paramètre Comptes : État de compte d'administrateur sur Désactivé pour que le compte Administrateur intégré ne soit plus exploitable dans le cadre d'un démarrage système normal.

Impact potentiel

La désactivation du compte Administrateur peut entraîner, dans certaines circonstances, des problèmes de maintenance. Par exemple, dans un environnement de domaine, si le canal sécurisé entre un ordinateur membre et le contrôleur de domaine présente une défaillance quelconque et qu'il n'existe pas d'autre compte Administrateur local, vous devez redémarrer en mode sans échec pour corriger le problème à l'origine de la rupture du canal sécurisé.

Si le mot de passe Administrateur courant ne répond pas aux conditions requises en matière de mot de passe, vous ne pouvez pas réactiver le compte Administrateur après sa désactivation. Si la situation se produit, un autre membre du groupe Administrateurs doit définir le mot de passe du compte Administrateur à l'aide de l'outil Utilisateurs et groupes locaux.

Comptes : État de compte d'invité

Ce paramètre de stratégie détermine si le compte Invité est activé ou désactivé.

Le paramètre Comptes : État de compte d'invité admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Le compte Invité par défaut permet aux utilisateurs de réseau non authentifiés de se connecter en tant qu'Invité sans mot de passe. Ces utilisateurs non autorisés peuvent accéder à toutes les ressources accessibles au compte Invité sur le réseau. Cela signifie que tout partage de réseau détenant des droits d'accès sur le compte Invité, le groupe Invités ou le groupe Tous les utilisateurs sera accessible sur le réseau. Cela pourrait conduire à l'exposition ou à la corruption des données.

Contre-mesures

Configurez le paramètre Comptes : État de compte d'invité sur Désactivé pour rendre le compte Invité intégré inutilisable.

Impact potentiel

Tous les utilisateurs du réseau devront s'authentifier avant de pouvoir accéder aux ressources partagées. Si vous désactivez le compte Invité et que l'option Accès réseau : Modèle de partage et de sécurité pour les comptes locaux est définie sur Invité seul, les ouvertures de session réseau, telles que celles exécutées par le serveur réseau Microsoft (service SMB), échoueront. L'impact de ce paramètre de stratégie risque d'être minime dans la plupart des entreprises, car il s'agit du paramètre par défaut de Microsoft Windows® 2000, Windows XP et Windows Server™ 2003.

Comptes : Restreindre l'utilisation de mots de passe vierges par le compte local à l'ouverture de session console

Ce paramètre de stratégie détermine si des ouvertures de session interactives effectuées à distance par des services de réseau tels que les services Terminal Server, Telnet et FTP (File Transfer Protocol) sont autorisées pour les comptes locaux ayant des mots de passe vierges. Si vous activez ce paramètre de stratégie, un compte local doit être doté d'un mot de passe réel pour exécuter une ouverture de session interactive ou réseau à partir d'un client distant.

Le paramètre Comptes : Restreindre l'utilisation de mots de passe vierges par le compte local à l'ouverture de session console admet les valeurs suivantes :

Activé
Désactivé
Non défini

Remarque : Ce paramètre de stratégie n'affecte pas les ouvertures de session interactives qui sont exécutées physiquement à la console ni celles qui utilisent des comptes de domaine.

Attention : Il est possible que des applications tierces utilisant des ouvertures de session interactives distantes ignorent ce paramètre de stratégie.

Vulnérabilité

Les mots de passe vierges constituent une menace sérieuse contre la sécurité de l'ordinateur et ils doivent être proscrits à la fois par la stratégie de l'entreprise et par des mesures techniques adaptées. En réalité, les paramètres par défaut des domaines du service d'annuaire Active Directory® de Windows Server 2003 nécessitent des mots de passe complexes d'au moins sept caractères. Néanmoins, si un utilisateur habilité à créer de nouveaux comptes contourne les stratégies de mot de passe basées sur un domaine, il peut créer des comptes dont les mots de passe sont vierges. Par exemple, un utilisateur peut créer un ordinateur autonome, créer un ou plusieurs comptes dont les mots de passe sont vierges, puis joindre l'ordinateur au domaine. Les comptes locaux dotés de mots de passe vierges fonctionneront quand même. Toute personne connaissant le nom de l'un de ces comptes non protégés pourrait ensuite l'utiliser pour ouvrir une session.

Contre-mesures

Activez le paramètre Comptes : Restreindre l'utilisation de mots de passe vierges par le compte local à l'ouverture de session console.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Comptes : Renommer le compte administrateur

Ce paramètre de stratégie détermine si un nom de compte différent est associé au SID du compte Administrateur.

Le paramètre Comptes : Renommer le compte administrateur admet les valeurs suivantes :

Texte défini par l'utilisateur
Non défini

Vulnérabilité

Le compte Administrateur existe sur tous les ordinateurs qui exécutent les systèmes d'exploitation Windows 2000, Windows Server 2003 ou Windows XP Professionnel. Si vous renommez ce compte, il est légèrement plus difficile pour les personnes non autorisées de deviner la combinaison nom d'utilisateur privilégié/mot de passe.

Le compte Administrateur intégré ne peut pas être verrouillé, quel que soit le nombre d'utilisations d'un mot de passe erroné par un attaquant. Cette caractéristique en fait une cible de premier choix pour les attaques en force qui tentent de deviner les mots de passe. La valeur de cette contre-mesure est atténuée dans la mesure où ce compte possède un SID bien connu et qu'il existe des outils tiers autorisant les authentifications à l'aide du SID plutôt que par le nom du compte. Par conséquent, même si vous renommez le compte Administrateur, un attaquant pourrait lancer une attaque en force en utilisant le SID pour se connecter.

Contre-mesures

Indiquez un nouveau nom dans le paramètre Comptes : Renommer le compte administrateur pour renommer le compte Administrateur.

Remarque : Dans les chapitres suivants, ce paramètre de stratégie n'est pas configuré dans les modèles de sécurité, et aucun nouveau nom d'utilisateur pour le compte n'est suggéré dans ce guide. Les modèles omettent ce paramètre de stratégie afin que les nombreuses entreprises implémentant ces instructions n'utilisent pas un même nom dans leurs environnements.

Impact potentiel

Vous devrez donner le nouveau nom du compte aux utilisateurs autorisés à utiliser ce compte. (Les conseils pour ce paramètre supposent que le compte Administrateur n'a pas été désactivé, ce qui a été recommandé précédemment dans ce chapitre.)

Comptes : Renommer le compte Invité

Le paramètre Comptes : Renommer le compte Invité détermine si un nom de compte différent est associé au SID du compte Invité.

Ce paramètre de stratégie de groupe admet les valeurs suivantes :

Texte défini par l'utilisateur
Non défini

Vulnérabilité

Le compte Invité existe sur tous les ordinateurs qui exécutent les systèmes d'exploitation Windows 2000, Windows Server 2003 ou Windows XP Professionnel. Si vous renommez ce compte, il est légèrement plus difficile pour les personnes non autorisées de deviner la combinaison nom d'utilisateur privilégié/mot de passe.

Contre-mesures

Indiquez un nouveau nom dans le paramètre Comptes : Renommer le compte Invité pour renommer le compte Invité.

Impact potentiel

L'impact devrait être minime, car le compte Invité est désactivé par défaut dans Windows 2000, Windows XP et Windows Server 2003.

Audit : Auditer l'accès des objets système globaux

Si vous activez ce paramètre de stratégie, une liste de contrôle d'accès système par défaut (SACL) sera appliquée lorsque l'ordinateur créera des objets système, tels que des mutex, des événements, des sémaphores et des périphériques MS-DOS®. Si vous activez également le paramètre Auditer l'accès aux objets conformément à la description du chapitre 3 de ce guide, l'accès à ces objets système est audité.

Les objets système globaux, ou « objets système de base », sont des objets éphémères du noyau auxquels un nom a été attribué par l'application ou le composant système qui les a créés. Ces objets sont le plus souvent utilisés pour synchroniser plusieurs applications ou plusieurs parties d'une application complexe. Parce qu'ils ont des noms, ces objets ont une portée globale, et sont donc visibles par tous les processus de l'ordinateur. Ils sont tous dotés d'un descripteur de sécurité, mais ont généralement une liste de contrôle d'accès système (SACL) de valeur NULL. Si vous activez ce paramètre de stratégie au moment du démarrage, le noyau attribuera une SACL à ces objets lors de leur création.

Le paramètre Audit : Auditer l'accès des objets système globaux admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

S'il est mal sécurisé, un objet nommé globalement visible pourrait être la cible d'une attaque par un programme malveillant qui connaîtrait le nom de l'objet. Par exemple, si un objet de synchronisation, du type mutex, était doté d'une liste DACL, un programme malveillant pourrait y accéder à l'aide de son nom et entraîner le dysfonctionnement du programme l'ayant créé. Ce risque est cependant très faible.

Contre-mesures

Activez le paramètre Audit : Auditer l'accès des objets système globaux.

Impact potentiel

Si vous activez le paramètre Audit : Auditer l'accès des objets système globaux, un grand nombre d'événements de sécurité pourraient être générés, en particulier sur des contrôleurs de domaine et des serveurs d'applications occupés. Les serveurs seraient alors plus lents à répondre et de nombreux événements peu importants seraient consignés dans le journal des événements de sécurité. Ce paramètre de stratégie ne peut être qu'activé ou désactivé. Il n'existe aucune façon de filtrer les événements enregistrés de ceux qui ne le sont pas. Même les entreprises disposant des ressources pour analyser les événements générés par ce paramètre de stratégie sont peu susceptibles de détenir le code source ou une description de l'objectif de chaque objet nommé. Il est donc peu probable que la configuration de ce paramètre de stratégie sur Activé profite à un grand nombre d'entreprises.

Audit : Auditer l'utilisation des privilèges de sauvegarde et de restauration

Ce paramètre de stratégie détermine s'il convient d'auditer l'utilisation de tous les privilèges utilisateur, notamment Sauvegarder et Restaurer, lorsque le paramètre Auditer l'utilisation des privilèges est en vigueur. L'activation des deux paramètres de stratégie génère un événement d'audit pour chaque fichier sauvegardé ou restauré.

Si vous activez ce paramètre de stratégie avec le paramètre Auditer l'utilisation des privilèges, toute utilisation de droits d'utilisateur dans le journal de sécurité est enregistrée. Si vous désactivez ce paramètre de stratégie, les actions effectuées par des utilisateurs appliquant les privilèges Sauvegarder ou Restaurer ne sont pas auditées, même si le paramètre Auditer l'utilisation des privilèges est activé.

Le paramètre Auditer l'utilisation des privilèges de sauvegarde et de restauration admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

L'activation de cette option, lorsque le paramètre Auditer l'utilisation des privilèges est également activé, génère un événement d'audit pour chaque fichier sauvegardé ou restauré. Ces informations pourraient vous aider à identifier un compte qui a été utilisé pour restaurer accidentellement ou par malveillance des données de façon non autorisée.

Contre-mesures

Activez le paramètre Auditer l'utilisation des privilèges de sauvegarde et de restauration. Sinon, implémentez la sauvegarde automatique de journal en configurant la clé de registre AutoBackupLogFiles, qui est décrite dans l'article de la Base de connaissances Microsoft « Le journal des événements cesse d'enregistrer des événements avant d'atteindre la taille maximale de journal » à l'adresse https://support.microsoft.com/kb/312571/fr.

Impact potentiel

Si vous activez ce paramètre de stratégie, un grand nombre d'événements de sécurité sont susceptibles d'être générés, ce qui pourraient ralentir le temps de réponse des serveurs et forcer le journal des événements de sécurité à consigner de nombreux événements sans importance. Si vous augmentez la taille du journal de sécurité pour réduire les risques d'arrêt du système, un fichier journal trop volumineux peut affecter les performances du système.

Audit : Arrêter immédiatement le système s'il n'est pas possible de se connecter aux audits de sécurité

Ce paramètre de stratégie détermine si l'ordinateur s'arrête lorsqu'il n'est pas capable de consigner les événements de sécurité. Les certifications TCSEC (Trusted Computer System Evaluation Criteria)-C2 et Common Criteria nécessitent que l'ordinateur soit capable d'empêcher l'occurrence d'événements auditables, si le système d'audit est incapable de les consigner. Pour satisfaire à cette exigence, Microsoft a décidé d'arrêter l'ordinateur et d'afficher un message d'arrêt en cas de défaillance du système d'audit. Si vous activez ce paramètre de stratégie, l'ordinateur s'arrête si un audit de sécurité ne peut pas être consigné pour une raison quelconque. En général, la consignation d'un événement échoue lorsque le journal des événements de sécurité est plein et que la méthode de rétention spécifie Ne pas remplacer les événements ou Remplacer les événements par jours.

Quand ce paramètre de stratégie est activé, le message d'arrêt suivant s'affiche si le journal de sécurité est complet et qu'une entrée existante ne peut pas être remplacée :

STOP: C0000244 {L'audit a échoué}

Une tentative de génération d'un audit de sécurité a échoué.

Pour exécuter une récupération, un administrateur doit ouvrir une session, archiver le journal (facultatif), vider le journal et désactiver cette option pour permettre le redémarrage de l'ordinateur. À ce stade, il peut être nécessaire d'effacer manuellement le journal des événements de sécurité avant de configurer ce paramètre de stratégie sur Activé.

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é peut prendre les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si l'ordinateur ne peut pas enregistrer les événements dans le journal de sécurité, des informations de dépannage cruciales ou des preuves stratégiques risquent de ne pas être disponibles pour examen après un incident de sécurité. De même, un attaquant pourrait éventuellement générer un grand nombre de messages dans le journal des événements de sécurité dans l'intention d'obliger l'ordinateur à s'arrêter.

Contre-mesures

Activez le paramètre Arrêter immédiatement le système s'il n'est pas possible de se connecter aux audits de sécurité.

Impact potentiel

Si vous activez ce paramètre de stratégie, la charge administrative peut être significative, notamment si vous configurez également la méthode de conservation du journal de sécurité sur Ne pas remplacer les événements (nettoyage manuel du journal). Cette configuration transforme une menace de répudiation (un opérateur de sauvegarde peut nier avoir sauvegardé ou restauré des données) en vulnérabilité de déni de service. En effet, un serveur pourrait être forcé de s'arrêter à cause d'une surcharge d'événements d'ouverture de session et d'autres événements de sécurité consignés dans le journal de sécurité. En outre, comme l'arrêt est brutal, il est possible qu'il entraîne des dégâts irréparables au niveau du système d'exploitation, des applications ou des données. Si le système de fichiers NTFS assure l'intégrité en cas d'arrêt brutal de l'ordinateur, il ne peut pas garantir que chaque fichier de données pour chaque application sera toujours dans un format exploitable au redémarrage de l'ordinateur.

DCOM : Restrictions d'accès machine en SDDL (Security Descriptor Definition Language)

Ce paramètre de stratégie permet aux administrateurs de définir des contrôles d'accès informatiques supplémentaires qui gouvernent l'accès à toutes les applications DCOM (Distributed Component Object Model) d'un ordinateur. Ces contrôles limitent l'appel, l'activation ou le lancement de requêtes sur l'ordinateur. La représentation la plus simple de ces contrôles d'accès est un appel de vérification d'accès supplémentaire effectuée par rapport à une liste de contrôle d'accès informatique (ACL) sur chaque appel, activation ou lancement de tout serveur COM sur l'ordinateur. Si la vérification d'accès échoue, la demande d'appel, d'activation ou de lancement sera refusée. (Cette vérification est effectuée en plus des vérifications d'accès exécutées par rapport aux listes ACL spécifiques aux serveurs.) Elle fournit en effet une norme minimale d'autorisation qui doit être satisfaite pour pouvoir accéder à un serveur COM de l'ordinateur. Le paramètre DCOM : Restrictions d'accès machine en SDDL (Security Descriptor Definition Language) contrôle les autorisations d'accès liées aux droits d'appel.

Ces ACL informatiques offrent un moyen de remplacer les paramètres de sécurité faibles indiqués par une application spécifique par le biais de CoInitializeSecurity ou de paramètres de sécurité propres à une application. Elles fournissent une norme de sécurité minimale qui doit être satisfaite, quels que soient les paramètres du serveur spécifique.

Ces ACL fournissent un emplacement centralisé permettant à un administrateur de déterminer la stratégie d'autorisation générale qui s'applique à tous serveurs COM sur l'ordinateur.

Le paramètre DCOM : Restrictions d'accès machine en SDDL (Security Descriptor Definition Language) permet de spécifier une liste ACL de deux manières différentes. Vous pouvez saisir le descripteur de sécurité dans SDDL, ou vous pouvez choisir des utilisateurs et des groupes et leur accorder ou refuser les autorisations d'accès local ou distant. Microsoft recommande que vous utilisiez l'interface utilisateur incorporée pour indiquer les contenus ACL que vous voulez appliquer avec ces paramètres.

Vulnérabilité

Beaucoup d'applications COM incluent un code de sécurité (par exemple, pour appeler CoInitializeSecurity), mais utilisent des paramètres faibles qui permettent souvent l'accès non authentifié au processus. Les administrateurs ne peuvent pas remplacer ces paramètres pour imposer une sécurité plus fiable dans les versions précédentes de Windows sans la modification de l'application. Un attaquant pourrait tenter d'exploiter la sécurité faible d'une application individuelle en l'attaquant par le biais d'appels COM.

De plus, l'infrastructure COM inclut le RPCSS, un service système qui s'exécute pendant le démarrage de l'ordinateur et de manière permanente par la suite. Ce service gère l'activation d'objets COM, la table d'objets en cours et fournit des services Application d'assistance à l'accès distant DCOM. Il expose les interfaces RPC qui peuvent être appelées à distance. Étant donné que certains serveurs COM permettent l'accès distant non authentifié (comme expliqué dans la section précédente), ces interfaces peuvent être appelées par n'importe qui, y compris des utilisateurs non authentifiés. Par conséquent, RPCSS peut être attaqué par des utilisateurs malveillants qui utilisent les ordinateurs à distance non authentifiés.

Contre-mesures

Pour protéger les applications ou services individuels COM, configurez le paramètre DCOM : Restrictions d'accès machine en SDDL (Security Descriptor Definition Language) selon une liste ACL informatique appropriée.

Impact potentiel

Windows XP avec SP2 et Windows Server 2003 avec SP1 utilisent des ACL COM par défaut comme indiqué dans leur documentation respective. Si vous mettez en œuvre un serveur COM et que vous remplacez les paramètres de sécurité par défaut, assurez-vous que la liste ACL des autorisations d'appel spécifiques à l'application attribue l'autorisation correcte aux utilisateurs adéquats. Si ce n'est pas le cas, vous devrez modifier votre liste ACL d'autorisations spécifiques à l'application pour fournir aux utilisateurs appropriés les droits d'activation nécessaires pour que les applications et les composants Windows qui utilisent DCOM ne présentent pas de dysfonctionnements.

Remarque : Pour plus d'informations sur les restrictions d'accès machine COM par défaut qui sont appliquées dans Windows XP avec SP2, reportez-vous au guide « Managing Windows XP Service Pack 2 Features Using Group Policy » à l'adresse technet.microsoft.com/fr-fr/library/bb457148.aspx. Pour toute information concernant les restrictions appliquées dans Windows Server 2003 avec SP1, voir la section « DCOM Security Enhancements » (Améliorations de sécurité DCOM) du guide « Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1 » à l'adresse http://technet2.microsoft.com/windowsserver/fr/library/
e3d396dd-c141-432b-9e69-50f597061e471036.mspx?mfr=true. Pour plus d'informations sur les autorisations de lancement, reportez-vous à la page « LaunchPermission » de Microsoft MSDN® à l'adresse https://go.microsoft.com/fwlink/?LinkId=20924.

DCOM : Restrictions de lancement machine en SDDL (Security Descriptor Definition Language)

Ce paramètre de stratégie est similaire au paramètre DCOM : Restrictions d'accès machine en SDDL (Security Descriptor Definition Language). En effet, il permet aux administrateurs de définir des contrôles d'accès informatiques supplémentaires qui gouvernent l'accès à toutes les applications DCOM d'un ordinateur. Cependant, les listes ACL indiquées dans ce paramètre de stratégie contrôlent les requêtes de lancement COM locales et distantes (mais pas les requêtes d'accès) sur l'ordinateur. La représentation la plus simple de ce contrôle d'accès est un appel de vérification d'accès supplémentaire effectué par rapport à une liste ACL informatique sur chaque lancement de serveur COM sur l'ordinateur. Si la vérification d'accès échoue, la demande d'appel, d'activation ou de lancement sera refusée. (Cette vérification est effectuée en plus des vérifications d'accès exécutées par rapport aux listes ACL spécifiques aux serveurs.) Elle fournit en effet une norme minimale d'autorisation qui doit être satisfaite pour pouvoir lancer un serveur COM sur l'ordinateur. Cette dernière stratégie diffère en ce sens qu'elle fournit une vérification d'accès minimale qui est appliquée aux tentatives d'accès à un serveur COM déjà lancé.

Ces ACL informatiques fournissent une façon de remplacer les paramètres de sécurité faibles indiqués par une application spécifique par le biais de CoInitializeSecurity ou de paramètres de sécurité propres à une application. Elles fournissent une norme de sécurité minimale qui doit être satisfaite, quels que soient les paramètres du serveur COM spécifique. Ces ACL fournissent un emplacement centralisé permettant à un administrateur de déterminer la stratégie d'autorisation générale qui s'applique à tous serveurs COM sur l'ordinateur.

Le paramètre DCOM : Restrictions de lancement machine en SDDL (Security Descriptor Definition Language) permet de spécifier une liste ACL de deux manières différentes. Vous pouvez saisir le descripteur de sécurité dans SDDL, ou vous pouvez choisir des utilisateurs et des groupes et leur accorder ou refuser les autorisations d'accès local ou distant. Microsoft recommande que vous utilisiez l'interface utilisateur incorporée pour indiquer les contenus ACL que vous voulez appliquer avec ces paramètres.

Vulnérabilité

De plus, l'infrastructure COM inclut le RPCSS, un service système qui s'exécute pendant le démarrage de l'ordinateur et de manière permanente par la suite. Ce service gère l'activation d'objets COM, la table d'objets en cours et fournit des services Application d'assistance à l'accès distant DCOM. Il expose les interfaces RPC qui peuvent être appelées à distance. Étant donné que certains serveurs COM permettent l'activation du composant distant non authentifié (comme expliqué dans la section précédente), ces interfaces peuvent être appelées par n'importe qui, y compris des utilisateurs non authentifiés. Par conséquent, RPCSS peut être attaqué par des utilisateurs malveillants qui utilisent les ordinateurs à distance non authentifiés.

Contre-mesures

Pour protéger les applications ou services individuels COM, configurez le paramètre DCOM : Restrictions de lancement machine en SDDL (Security Descriptor Definition Language) selon une liste ACL machine appropriée.

Impact potentiel

Windows XP avec SP2 et Windows Server 2003 avec SP1 utilisent des ACL COM par défaut comme indiqué dans leur documentation respective. Si vous mettez en œuvre un serveur COM et que vous remplacez les paramètres de sécurité par défaut, confirmez que la liste ACL des autorisations de lancement spécifiques à l'application attribue l'activation correcte aux utilisateurs adéquats. Si ce n'est pas le cas, vous devrez modifier votre liste ACL d'autorisations de lancement spécifique à l'application pour fournir aux utilisateurs appropriés les droits d'activation nécessaires pour que les applications et les composants Windows qui utilisent DCOM ne présentent pas de dysfonctionnements.

Remarque : Pour plus d'informations sur les restrictions de lancement machine COM par défaut qui sont appliquées dans Windows XP avec SP2, reportez-vous au guide « Managing Windows XP Service Pack 2 Features Using Group Policy » à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx. Pour toute information concernant les restrictions appliquées dans Windows Server 2003 avec SP1, voir la section « DCOM Security Enhancements » (Améliorations de sécurité DCOM) du guide « Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1 » à l'adresse http://technet2.microsoft.com/windowsserver/fr/library/e3d396dd-c141-432b-9e69-50f597061e471036.mspx?mfr=true
. Pour plus d'informations sur les autorisations de lancement, reportez-vous à la page « LaunchPermission » de MSDN à l'adresse https://go.microsoft.com/fwlink/?LinkId=20924.

Périphériques : Autoriser le retrait sans ouverture de session préalable

Ce paramètre de stratégie détermine si un utilisateur doit ouvrir une session pour demander l'autorisation de retirer un ordinateur portable d'une station d'accueil. Si vous activez ce paramètre de stratégie, les utilisateurs pourront appuyer sur un bouton d'éjection d'ordinateur portable intégré pour le retirer en toute sécurité. Si vous désactivez ce paramètre de stratégie, l'utilisateur doit ouvrir une session pour obtenir l'autorisation de retirer l'ordinateur. Seuls les utilisateurs disposant du droit Retirer l'ordinateur de la station d'accueil peuvent obtenir cette autorisation.

Remarque : Vous ne devez désactiver ce paramètre de stratégie que pour les ordinateurs portables qui ne peuvent pas être retirés mécaniquement de la station d'accueil. Les ordinateurs qui peuvent être retirés mécaniquement de la station d'accueil peuvent l'être physiquement par l'utilisateur qu'ils utilisent ou non la fonctionnalité de retrait Windows.

Le paramètre Périphériques : Autoriser le retrait sans ouverture de session préalable admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si ce paramètre de stratégie est activé, toute personne dotée d'un accès physique aux ordinateurs portables placés sur station d'accueil peut les retirer et les pirater. Pour les ordinateurs sans station d'accueil, ce paramètre de stratégie n'a aucun impact.

Contre-mesures

Désactivez le paramètre Périphériques : Autoriser le retrait sans ouverture de session préalable.

Impact potentiel

Les utilisateurs qui ont placé leurs ordinateurs sur la station d'accueil doivent ouvrir une session sur la console locale avant de pouvoir retirer leurs ordinateurs.

Périphériques : Permettre le formatage et l'éjection des supports amovibles

Ce paramètre de stratégie identifie le(s) utilisateur(s) autorisé(s) à formater et à éjecter des supports amovibles.

Le paramètre Périphériques : Permettre le formatage et l'éjection des supports amovibles admet les valeurs suivantes :

Administrateurs
Administrateurs et Utilisateurs avec pouvoir
Administrateurs, Utilisateurs interactifs
Non défini

Vulnérabilité

Les utilisateurs peuvent déplacer des données de disques amovibles sur un autre ordinateur sur lequel ils détiennent des privilèges administratifs. Ils pourraient ensuite s'approprier n'importe quel fichier, s'octroyer un contrôle total sur un fichier, et visualiser ou modifier n'importe quel fichier. Le fait qu'il soit possible d'éjecter un support de la plupart des dispositifs de stockage amovibles en appuyant sur un bouton mécanique réduit l'avantage de ce paramètre de stratégie.

Contre-mesures

Configurez le paramètre Permettre le formatage et l'éjection des supports amovibles sur Administrateurs.

Impact potentiel

Seuls les administrateurs pourront éjecter des supports amovibles formatés en NTFS.

Périphériques : Empêcher les utilisateurs d'installer des pilotes d'imprimante

Pour qu'un ordinateur puisse lancer une impression sur une imprimante réseau, le pilote de cette dernière doit être installé sur l'ordinateur local. Le paramètre Périphériques : Empêcher les utilisateurs d'installer des pilotes d'imprimante détermine qui peut installer un pilote d'imprimante dans le cadre de l'ajout d'une imprimante réseau. Si vous activez ce paramètre de stratégie, seuls les membres des groupes Administrateurs et Utilisateurs avec pouvoir sont autorisés à installer un pilote d'imprimante lors de l'ajout d'une imprimante réseau. Si vous désactivez ce paramètre de stratégie, tout utilisateur peut installer des pilotes d'imprimante lors de l'ajout d'une imprimante réseau. Ce paramètre de stratégie empêche des utilisateurs types de télécharger et d'installer des pilotes d'imprimante non approuvés.

Remarque : Ce paramètre de stratégie reste sans impact si un administrateur a configuré un chemin approuvé pour le téléchargement des pilotes. Si vous utilisez ces chemins, le sous-système d'impression essaie d'utiliser le chemin approuvé pour télécharger le pilote. Si le téléchargement du chemin approuvé réussit, le pilote est installé pour le compte de l'utilisateur. S'il échoue, le pilote n'est pas installé et l'imprimante réseau n'est pas ajoutée.

Le paramètre Périphériques : Empêcher les utilisateurs d'installer des pilotes d'imprimante admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Il peut être approprié dans certaines organisations de permettre aux utilisateurs d'installer des pilotes d'imprimante sur leurs propres stations de travail. Cependant, vous ne devez pas autoriser les utilisateurs à effectuer cette opération sur des serveurs. L'installation d'un pilote d'imprimante sur un serveur risque de causer accidentellement une instabilité de l'ordinateur. Seuls les administrateurs doivent détenir ce privilège sur les serveurs. Un utilisateur malveillant pourrait installer des pilotes d'imprimante inappropriés dans une tentative délibérée d'endommager l'ordinateur, ou un utilisateur pourrait installer accidentellement un code malveillant qui prend l'apparence d'un pilote d'imprimante.

Contre-mesures

Configurez le paramètre Périphériques : Empêcher les utilisateurs d'installer des pilotes d'imprimante sur Activé.

Impact potentiel

Seuls les utilisateurs disposant de privilèges Administrateur, Utilisateur avec pouvoir ou Opérateur de serveur pourront installer des imprimantes sur les serveurs. Si ce paramètre de stratégie est activé, mais que le pilote d'une imprimante réseau existe déjà sur l'ordinateur local, les utilisateurs peuvent toujours ajouter l'imprimante réseau.

Périphériques : Ne permettre l'accès au CD-ROM qu'aux utilisateurs connectés localement

Ce paramètre de stratégie détermine si un lecteur de CD-ROM est accessible simultanément aux utilisateurs locaux et distants. Si vous activez ce paramètre, seul l'utilisateur ayant ouvert une session de manière interactive est autorisé à accéder au lecteur de CD-ROM amovible. Si ce paramètre de stratégie est activé et que personne n'est connecté de façon interactive, le CD-ROM est accessible par le biais du réseau.

Le paramètre Périphériques : Ne permettre l'accès au CD-ROM qu'aux utilisateurs connectés localement admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un utilisateur à distance pourrait éventuellement accéder à un lecteur de CD-ROM monté contenant des informations sensibles. Ce risque est faible, car les lecteurs de CD-ROM ne sont pas automatiquement mis à disposition en tant que partages réseau ; les administrateurs doivent délibérément choisir de partager le lecteur. Cependant, les administrateurs peuvent refuser aux utilisateurs du réseau le droit d'afficher des données ou d'exécuter des applications sur des supports amovibles du serveur.

Contre-mesures

Activez le paramètre Ne permettre l'accès au CD-ROM qu'aux utilisateurs connectés localement.

Impact potentiel

Les utilisateurs qui se connectent au serveur sur le réseau ne pourront pas utiliser les lecteurs de CD-ROM installés sur le serveur si un utilisateur a ouvert une session sur la console locale du serveur. Les outils système nécessitant un accès au lecteur de CD-ROM échoueront. Par exemple, si le service de cliché instantané des volumes tente d'accéder à tous les lecteurs de CD-ROM et de disquettes présents sur l'ordinateur lors de l'initialisation et qu'il ne parvient pas à accéder à l'un de ces lecteurs, il échouera. Cette condition provoquera l'échec de l'utilitaire de sauvegarde Windows si les clichés instantanés de volume ont été indiqués pour la tâche de sauvegarde. Les produits de sauvegarde de tiers utilisant des clichés instantanés des volumes échoueront aussi. Ce paramètre de stratégie ne serait pas adapté à un ordinateur qui sert de jukebox à CD pour les utilisateurs du réseau.

Périphériques : Ne permettre l'accès aux disquettes qu'aux utilisateurs connectés localement

Ce paramètre de stratégie détermine si les supports de disquette amovibles sont accessibles simultanément aux utilisateurs locaux et distants. Si vous activez ce paramètre, seul l'utilisateur ayant ouvert une session de manière interactive est autorisé à accéder aux supports de disquette amovibles. Si ce paramètre de stratégie est activé et si personne n'est connecté de façon interactive, la disquette est accessible par le biais du réseau.

Le paramètre Périphériques : Ne permettre l'accès aux disquettes qu'aux utilisateurs connectés localement admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un utilisateur à distance pourrait éventuellement accéder à un lecteur de disquette monté contenant des informations sensibles. Ce risque est faible, car les lecteurs de disquette ne sont pas automatiquement mis à disposition en tant que partages réseau ; les administrateurs doivent volontairement choisir de partager le lecteur. Cependant, les administrateurs peuvent refuser aux utilisateurs du réseau le droit d'afficher des données ou d'exécuter des applications sur des supports amovibles du serveur.

Contre-mesures

Activer le paramètre Ne permettre l'accès aux disquettes qu'aux utilisateurs connectés localement.

Impact potentiel

Les utilisateurs qui se connectent au serveur sur le réseau ne pourront pas utiliser les lecteurs de disquette installés sur le serveur si un utilisateur a ouvert une session sur la console locale du serveur. Les outils système nécessitant un accès aux lecteurs de disquettes échoueront. Par exemple, si le service de cliché instantané des volumes tente d'accéder à tous les lecteurs de CD-ROM et de disquettes présents sur l'ordinateur lors de l'initialisation et qu'il ne parvient pas à accéder à l'un de ces lecteurs, il échouera. Cette condition provoquera l'échec de l'utilitaire de sauvegarde Windows si les clichés instantanés de volume ont été indiqués pour la tâche de sauvegarde. Les produits de sauvegarde de tiers utilisant des clichés instantanés des volumes échoueront aussi.

Périphériques : Comportement d'installation d'un pilote non signé

Ce paramètre de stratégie détermine ce qui se passe en cas de tentative d'installation d'un pilote de périphérique qui n'a pas été certifié et signé par le laboratoire de contrôle qualité du matériel Windows (WHQL) au moyen de l'interface de programmation d'applications d'installation (API).

Le paramètre Périphériques : Comportement d'installation d'un pilote non signé peut prendre les valeurs suivantes :

Réussite silencieuse
Avertir, mais autoriser l’installation
Ne pas autoriser l’installation
Non défini

Vulnérabilité

Ce paramètre de stratégie empêche l'installation de pilotes non signés ou avertit l'administrateur qu'un pilote non signé est sur le point d'être installé. Il peut empêcher l'usage de l'API d'installation pour installer des pilotes qui n'ont pas été certifiés pour s'exécuter sur Windows XP ou Windows Server 2003. Ce paramètre de stratégie ne fera pas échec à une méthode utilisée par certains outils d'attaque, dans laquelle des fichiers .sys malveillants sont copiés et enregistrés pour démarrer en tant que services système.

Contre-mesures

Configurez le paramètre Périphériques : Comportement d'installation d'un pilote non signé sur Avertir, mais autoriser l’installation, qui est la configuration par défaut de Windows XP avec SP2. La configuration par défaut de Windows Server 2003 est Non défini.

Impact potentiel

Les utilisateurs dotés de privilèges suffisants pour installer des pilotes de périphérique pourront installer des pilotes de périphérique non signés. Cette possibilité peut toutefois entraîner des problèmes de stabilité des serveurs. Un autre problème potentiel lié à la configuration Avertir, mais autoriser l’installation est que les scripts d'installation sans surveillance échouent lorsqu'ils essaient d'installer des pilotes non signés.

Contrôleur de domaine : Permettre aux opérateurs du serveur de planifier des tâches

Ce paramètre de stratégie détermine si les opérateurs de serveur sont autorisés à soumettre des tâches au moyen de la fonction de calendrier AT.

Remarque : Cette option de sécurité n'a une incidence que sur la fonction de calendrier AT. Elle n'a aucune répercussion sur la fonction de Planificateur de tâches.

Le paramètre Contrôleur de domaine : Permettre aux opérateurs du serveur de planifier des tâches admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si ce paramètre de stratégie est activé, les travaux créés par les opérateurs de serveur à l'aide du service AT s'exécuteront dans le contexte du compte exécutant ce service. (par défaut, le compte SYSTEM local). Si vous activez ce paramètre de stratégie, des opérateurs de serveur pourraient donc exécuter des tâches que SYSTEM peut réaliser, mais qu'eux-mêmes ne sont pas capables d'effectuer en temps normal, comme ajouter leur compte au groupe Administrateurs local.

Contre-mesures

Désactivez le paramètre Contrôleur de domaine : Permettre aux opérateurs du serveur de planifier des tâches.

Impact potentiel

L'impact risque d'être minime dans la plupart des organisations. Les utilisateurs (y compris ceux du groupe Opérateurs de serveur) pourront toujours créer des travaux à l'aide de l'Assistant du Gestionnaire de tâches. Cependant, ces travaux s'exécuteront dans le contexte du compte avec lequel l'utilisateur s'authentifie lors de la définition du travail.

Contrôleur de domaine : Conditions requises pour la signature de serveur LDAP

Ce paramètre de stratégie détermine si le serveur LDAP (Lightweight Directory Access Protocol) exige la négociation de la signature de données par les clients LDAP.

Le paramètre Contrôleur de domaine : Conditions requises pour la signature de serveur LDAP admet les valeurs suivantes :

Aucune. La signature des données n'est pas requise pour effectuer une liaison avec le serveur. Si le client demande la signature des données, le serveur la prend en charge.
Nécessite la signature. L'option de signature des données LDAP doit être négociée, sauf en cas d'utilisation du fournisseur de sécurité TLS/SSL (Transport Layer Security/Secure Socket Layer).
Non défini.

Vulnérabilité

Le trafic réseau non signé pourrait être la cible d'attaques « man-in-the-middle » (attaque de l'intercepteur). Lors ces attaques, un intrus capture des paquets entre le serveur et le client, les modifie et les transmet ensuite au client. Dans le cas de serveurs LDAP, un attaquant pourrait pousser un client à prendre des décisions sur la base d'enregistrements erronés provenant de l'annuaire LDAP. Pour réduire le risque de ce type d'intrusion dans un réseau d'entreprise, vous pouvez implémenter des mesures de sécurité physiques fortes pour protéger l'infrastructure du réseau. Vous pouvez également implémenter un mode d'en-tête d'authentification (AH) par protocole IPSec (Internet Protocol security), qui exécute une authentification mutuelle. Une intégrité de paquet pour le trafic IP peut rendre extrêmement difficiles les différents types d'attaques « man-in-the-middle » (attaque de l'intercepteur).

Contre-mesures

Configurez le paramètre Contrôleur de domaine : Conditions requises pour la signature de serveur LDAP sur Nécessite la signature.

Impact potentiel

Les clients ne prenant pas en charge la signature LDAP ne pourront pas exécuter les requêtes LDAP sur les contrôleurs de domaine. Tous les ordinateurs Windows 2000 de votre entreprise gérés à partir d'ordinateurs Windows Server 2003 ou Windows XP utilisant l'authentification de stimulation/réponse NTLM Windows NT® doivent être équipés de Windows 2000 Service Pack 3 (SP3). Sinon, ces clients doivent subir la modification de registre décrite dans l'article Q325465 de la Base de Connaissances Microsoft « Les contrôleurs de domaine Windows 2000 nécessitent SP3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003 » disponible à l'adresse https://support.microsoft.com/kb/325465/fr. En outre, certains systèmes d'exploitation tiers ne prennent pas en charge la signature LDAP. Si vous activez ce paramètre de stratégie, les ordinateurs clients qui utilisent ces systèmes d'exploitation peuvent être incapables d'accéder aux ressources de domaine.

Contrôleur de domaine : Refuser les modifications de mot de passe du compte ordinateur

Ce paramètre de stratégie détermine si un contrôleur de domaine acceptera ou non les demandes de changement de mot de passe pour les comptes ordinateur.

Le paramètre Contrôleur de domaine : Refuser les modifications de mot de passe du compte ordinateur admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si vous activez ce paramètre de stratégie sur tous les contrôleurs de domaine d'un domaine, les membres du domaine ne pourront pas modifier les mots de passe de leur compte ordinateur, et ces mots de passe seront plus susceptibles d'être attaqués.

Contre-mesures

Désactivez le paramètre Contrôleur de domaine : Refuser les modifications de mot de passe du compte ordinateur.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (plusieurs paramètres associés)

Les paramètres de stratégie suivants déterminent s'il est possible d'établir un canal sécurisé avec un contrôleur de domaine ne pouvant pas signer ou chiffrer le trafic du canal sécurisé :

Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (toujours)
Membre de domaine : Chiffrer numériquement les données des canaux sécurisés (lorsque cela est possible)
Membre de domaine : Signer numériquement les données des canaux sécurisés (lorsque cela est possible)

Si vous activez le paramètre Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (toujours), il est impossible d'établir un canal sécurisé avec un contrôleur de domaine ne pouvant ni signer ni chiffrer toutes les données de ce canal sécurisé.

Pour protéger le trafic d'authentification contre les attaques réseau, comme des attaques « man-in-the-middle » (attaque de l'intercepteur) ou de relecture, les ordinateurs Windows créent un canal de communication via NetLogon appelé canal sécurisé. Ce canal authentifie également les comptes ordinateur, ainsi que les comptes utilisateur lorsqu'un utilisateur distant se connecte à une ressource réseau alors que son compte existe dans un domaine approuvé. Ce mécanisme est appelé authentification directe et permet à un ordinateur rattaché à un domaine d'avoir accès à la base de données des comptes utilisateur de ce domaine et de tous les domaines approuvés.

Remarque : Pour activer le paramètre Membre de domaine : Crypter ou signer numériquement les données des canaux sécurisés (toujours) sur un poste de travail membre ou un serveur, il est nécessaire que tous les contrôleurs du domaine auquel appartient le membre puissent signer ou crypter toutes les données du canal sécurisé. Cette condition implique que tous ces contrôleurs de domaine doivent exécuter Windows NT 4.0 avec Service Pack 6a ou une version ultérieure du système d'exploitation Windows.

Si vous activez le paramètre Membre du domaine : Crypter ou signer numériquement les données des canaux sécurisés (toujours), le paramètre Membre de domaine : Signer numériquement les données des canaux sécurisés (si possible) est automatiquement activé.

Ce paramètre de stratégie admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Lorsqu'un ordinateur Windows Server 2003, Windows XP, Windows 2000 ou Windows NT intègre un domaine, un compte ordinateur est créé. Après l'intégration, l'ordinateur, à chacun de ses redémarrages, utilise le mot de passe correspondant au compte pour créer un canal sécurisé avec le contrôleur de domaine. Les requêtes envoyées sur le canal sécurisé sont authentifiées, et les informations confidentielles de type mot de passe sont chiffrées, mais l'intégrité du canal n'est pas vérifiée et toutes les informations ne sont pas chiffrées. Si un ordinateur est configuré pour toujours chiffrer ou signer des données de canal sécurisé, mais que le contrôleur de domaine ne peut ni signer, ni chiffrer une partie des données du canal sécurisé, l'ordinateur et le contrôleur de domaine ne peuvent pas établir de canal sécurisé. Si l'ordinateur est configuré pour chiffrer ou signer les données d'un canal sécurisé lorsque c'est possible, un canal sécurisé peut être établi, mais le niveau de chiffrement et de signature est négocié.

Contre-mesures

Configurez le paramètre Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (toujours) sur Activé.
Configurez le paramètre Membre de domaine : Chiffrer numériquement les données des canaux sécurisés (si possible) sur Activé.
Configurez le paramètre Membre de domaine : Signer numériquement les données des canaux sécurisés (si possible) sur Activé.

Impact potentiel

Lorsqu'elle est prise en charge, la politique de chiffrement et de signature numérique du « canal sécurisé » est une bonne pratique. Le canal sécurisé protège les informations d'identification du domaine lors de leur envoi au contrôleur du domaine. Cependant, seuls Windows NT 4.0 Service Pack 6a (SP6a) et les versions ultérieures du système d'exploitation Windows gèrent le chiffrement et la signature numérique du canal sécurisé. Les clients Windows 98 Deuxième édition ne prennent pas ce mécanisme en charge, sauf si Dsclient est installé. Vous ne pouvez donc pas activer le paramètre Membre de domaine : Chiffrer ou signer numériquement les données des canaux sécurisés (toujours) sur des contrôleurs de domaine qui prennent en charge des clients Windows 98 comme membres du domaine. Les impacts potentiels peuvent être les suivants :

désactivation de la possibilité de créer ou supprimer des relations d'approbation de niveau inférieur,
désactivation des ouvertures de session à partir de clients de niveau inférieur,
la désactivation de la possibilité d'authentifier les utilisateurs d'autres domaines à partir d'un domaine approuvé de niveau inférieur.

Vous pouvez activer ce paramètre de stratégie après avoir éliminé tous les clients Windows 9x du domaine et mis à jour vers Windows NT 4.0 SP6a tous les serveurs et contrôleurs de domaine Windows NT 4.0 à partir de domaines approuvés/d'approbation. Vous pouvez activer les deux autres paramètres de stratégie Membre de domaine : Chiffrer numériquement les données des canaux sécurisés (si possible) et Membre de domaine : Signer numériquement les données des canaux sécurisés (si possible) sur tous les ordinateurs du domaine qui les prennent en charge. Les applications et les clients de niveau inférieur ne seront pas affectés.

Membre de domaine : Désactiver les modifications de mot de passe du compte ordinateur

Ce paramètre de stratégie détermine si un membre de domaine change périodiquement le mot de passe de son compte sur son ordinateur. Si vous activez ce paramètre de stratégie, le membre de domaine ne peut pas modifier son mot de passe de compte sur son ordinateur. Si vous désactivez ce paramètre de stratégie, le membre de domaine est autorisé à modifier son mot de passe de compte ordinateur comme indiqué par le paramètre Membre de domaine : Age maximal du mot de passe du compte ordinateur, à savoir tous les 30 jours par défaut.

Attention : N'activez pas ce paramètre de stratégie. Les mots de passe d'un compte ordinateur servent à établir des communications par canal sécurisé entre les membres et les contrôleurs de domaine et, au sein du domaine, entre les contrôleurs eux-mêmes. Une fois que ces communications sont établies, le canal sécurisé transmet les informations confidentielles qui sont nécessaires aux décisions d'authentification et d'autorisation.

N'utilisez pas ce paramètre de stratégie dans une tentative de réponse à des scénarios de double amorçage utilisant le même compte ordinateur. Si vous voulez prendre en charge un scénario de ce type pour deux installations associées au même domaine, attribuez des noms d'ordinateur différents aux deux installations. Ce paramètre de stratégie a été ajouté dans Windows pour faciliter le travail des entreprises qui accumulent des ordinateurs intégrés, lesquels sont mis en production des mois plus tard. Ces ordinateurs n'ont alors pas besoin d'être intégrés au domaine. Ce paramètre de stratégie est également utilisé parfois avec les ordinateurs pour lesquels une image a été créée ou ceux dotés d'un système de prévention contre toute modification de version matérielle ou logicielle. Des procédures d'images correctes annulent l'intérêt de cette stratégie pour les ordinateurs avec image.

Le paramètre Membre de domaine : Désactiver les modifications de mot de passe du compte ordinateur peut prendre les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les ordinateurs Windows Server 2003 qui appartiennent à un domaine sont configurés par défaut pour changer automatiquement les mots de passe de leurs comptes tous les 30 jours. Si vous désactivez ce paramètre de stratégie, les ordinateurs qui exécutent Windows Server 2003 conservent les mêmes mots de passe que les comptes ordinateur. Les ordinateurs qui ne sont plus capables de modifier automatiquement leurs mots de passe de compte sont potentiellement exposés aux actions d'un attaquant qui pourrait déterminer le mot de passe du compte de domaine de l'ordinateur.

Contre-mesures

Vérifiez que le paramètre Membre de domaine : Désactiver les modifications de mot de passe du compte ordinateur est configuré sur Désactivé.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Membre de domaine : âge maximal du mot de passe du compte ordinateur

Ce paramètre de stratégie détermine l'âge maximal autorisable pour le mot de passe d'un compte ordinateur. Ce paramètre s'applique également aux ordinateurs Windows 2000, mais n'est pas disponible via les outils du Gestionnaire de configuration de sécurité sur ces ordinateurs.

Le paramètre Membre de domaine : Age maximal du mot de passe du compte ordinateur admet les valeurs suivantes :

Nombre de jours compris entre 0 et 999, défini par l'utilisateur
Non défini

Vulnérabilité

Dans les domaines basés sur Active Directory, chaque ordinateur dispose d'un compte et d'un mot de passe comme tout utilisateur. Par défaut, les membres de domaine changent automatiquement leur mot de passe de domaine tous les 30 jours. Si vous augmentez cet intervalle de façon importante ou si vous le définissez sur 0 pour que les ordinateurs ne changent plus leur mot de passe, un attaquant aura davantage de temps pour entreprendre une attaque en force et tenter de deviner le mot de passe d'au moins un compte ordinateur.

Contre-mesures

Configurez le paramètre Membre de domaine : Age maximal du mot de passe du compte ordinateur sur 30 jours.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Membre de domaine : Nécessite une clé de session forte (Windows 2000 ou ultérieur)

Ce paramètre de stratégie détermine si un canal sécurisé peut être établi avec un contrôleur de domaine qui ne peut pas chiffrer le trafic de ce canal avec une clé de session forte, à 128 bits. Si vous activez ce paramètre de stratégie, il n'est pas possible d'établir un canal sécurisé avec un contrôleur de domaine ne pouvant pas crypter les données de ce canal avec une clé forte. Si vous désactivez ce paramètre de stratégie, les clés de session de 64 bits sont autorisées.

Remarque : Pour activer ce paramètre de stratégie sur un serveur ou un poste de travail membre, tous les contrôleurs de domaine auxquels appartient ce membre doivent pouvoir chiffrer les données du canal sécurisé 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 du système d'exploitation Windows.

Le paramètre Membre de domaine : Nécessite une clé de session forte (Windows 2000 ou ultérieur) admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les clés de session utilisées pour établir les communications des canaux sécurisés entre les contrôleurs de domaine et les ordinateurs membres sont beaucoup plus fortes dans Windows 2000 que dans les systèmes d'exploitation Microsoft précédents.

Lorsque c'est possible, utilisez ces clés de session plus fortes pour vous aider à protéger les communications sur canal sécurisé contre les attaques qui tentent de pirater les sessions réseau et qui effectuent des écoutes clandestines. (L'écoute clandestine est une forme de piratage au cours duquel les données du réseau sont lues ou modifiées lors du transit. Les données peuvent être modifiées de façon à cacher ou changer l'expéditeur, ou être redirigées.)

Contre-mesures

Configurez le paramètre Membre de domaine : Nécessite une clé de session forte (Windows 2000 ou ultérieur) sur Activé.

Si vous activez ce paramètre de stratégie, tout le trafic du canal sécurisé sortant exigera une clé de chiffrement forte de niveau Windows 2000 ou ultérieur. Si vous désactivez ce paramètre de stratégie, la force de la clé est négociée. Vous devez activer ce paramètre de stratégie uniquement si les contrôleurs de domaine de tous les domaines approuvés prennent en charge des clés fortes. Par défaut, ce paramètre de stratégie est désactivé.

Impact potentiel

Les ordinateurs dont ce paramètre de stratégie est activé ne peuvent pas intégrer de domaines Windows NT 4.0. Les approbations entre les domaines Active Directory et les domaines de type Windows NT peuvent ne pas fonctionner correctement. De même, les ordinateurs qui ne prennent pas en charge ce paramètre de stratégie ne peuvent pas intégrer de domaines dans lesquels ce paramètre est activé pour les contrôleurs.

Ouverture de session interactive : Ne pas afficher le dernier nom d'utilisateur

Ce paramètre de stratégie détermine si la boîte de dialogue Ouverture de session Windows affiche le nom du dernier utilisateur s'étant connecté à l'ordinateur. Si vous activez ce paramètre de stratégie, le nom du dernier utilisateur à avoir réussi à ouvrir une session ne s'affiche pas. Au contraire, si vous désactivez ce paramètre, le nom du dernier utilisateur à avoir réussi à ouvrir une session s'affiche.

Le paramètre Ouverture de session interactive : Ne pas afficher le dernier nom d'utilisateur admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un attaquant ayant accès à la console (par exemple, une personne disposant d'un accès physique ou pouvant se connecter au serveur via les services Terminal Server) pourrait visualiser le nom du dernier utilisateur connecté au serveur. Il pourrait ensuite essayer de deviner le mot de passe, utiliser un dictionnaire ou lancer une attaque en force pour essayer d'ouvrir une session.

Contre-mesures

Configurez le paramètre Ne pas afficher le dernier nom d'utilisateur dans l'écran d'ouverture de session sur Activé.

Impact potentiel

Les utilisateurs doivent systématiquement saisir leur nom d'utilisateur lorsqu'ils ouvrent une session sur les serveurs.

Ouverture de session interactive : Ne pas demander la combinaison de touches CTRL+ALT+DEL

Ce paramètre de stratégie détermine si les utilisateurs doivent appuyer sur les touches CTRL+ALT+DEL avant d'ouvrir une session. Si vous activez ce paramètre de stratégie, les utilisateurs peuvent ouvrir une session sans cette combinaison de touches. Si vous désactivez ce paramètre de stratégie, les utilisateurs doivent appuyer sur les touches CTRL+ALT+DEL avant de pouvoir ouvrir une session Windows, sauf s'ils utilisent une carte à puce pour l'ouverture de session Windows. Une carte à puce est un périphérique à l'épreuve des manipulations qui stocke des informations de sécurité.

Le paramètre Ouverture de session interactive : Ne pas demander la combinaison de touches Ctrl+Alt+Suppr admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Microsoft a développé cette fonction pour permettre aux utilisateurs souffrant de certains handicaps physiques d'ouvrir des sessions sur des ordinateurs exécutant Windows. Si les utilisateurs ne sont pas obligés d'appuyer sur les touches CTRL+ALT+DEL, ils sont susceptibles de subir des attaques tentant d'intercepter leurs mots de passe. Si la combinaison de touches CTRL+ALT+DEL est requise avant l'ouverture de session, les mots de passe utilisateur sont communiqués au moyen d'un chemin approuvé.

Un attaquant pourrait installer un cheval de Troie ressemblant à la boîte de dialogue d'ouverture de session Windows standard et capturer le mot de passe de l'utilisateur. Il pourrait ensuite se connecter au compte compromis, avec le niveau de privilège dont dispose l'utilisateur.

Contre-mesures

Configurez le paramètre Désactiver la combinaison de touches Ctrl+Alt+Suppr lors de l'ouverture de session sur Désactivé.

Impact potentiel

Sauf en cas d'utilisation d'une carte à puce pour une ouverture de session, les utilisateurs doivent appuyer simultanément sur les trois touches avant que la boîte de dialogue d'ouverture de session ne s'affiche.

Ouverture de session interactive : Contenu du message pour les utilisateurs essayant de se connecter

Les paramètres Ouverture de session interactive : Contenu du message pour les utilisateurs essayant de se connecter et Ouverture de session interactive : Titre du message pour les utilisateurs essayant de se connecter sont étroitement liés. Le premier paramètre de stratégie spécifie le texte du message diffusé aux utilisateurs lorsqu'ils tentent de se connecter, le deuxième indique le titre qui s'affiche dans la barre de titre de la fenêtre contenant le message. Bien des entreprises utilisent ce texte à des fins légales, par exemple, pour prévenir les utilisateurs des conséquences que pourraient présenter pour eux une utilisation abusive des informations de la société ou pour les avertir que leurs actions peuvent être auditées.

Attention : Windows XP Professionnel ajoute la prise en charge de bannières d'ouverture de session pouvant dépasser 512 caractères et pouvant également contenir des séquences avec sauts de ligne et retours chariot. Cependant, les clients Windows 2000 ne peuvent ni interpréter, ni afficher ces messages. Vous devez utiliser un ordinateur Windows 2000 pour créer une stratégie de message d'ouverture de session s'appliquant aux ordinateurs Windows 2000. Si vous créez malencontreusement une stratégie de message d'ouverture de session sur un ordinateur Windows XP Professionnel et que vous découvrez que son affichage n'est pas correct sur les ordinateurs Windows 2000, procédez comme suit :

Configurez de nouveau le paramètre sur Non défini.
Redéfinissez ensuite le paramètre à l'aide d'un ordinateur Windows 2000.

Vous ne pouvez pas simplement modifier le paramètre de message d'ouverture de session défini par Windows XP Professionnel sur un ordinateur Windows 2000. Vous devez d'abord configurer le paramètre sur Non défini.

Les valeurs possibles pour ces paramètres de stratégie sont les suivantes :

Texte défini par l'utilisateur
Non défini

Vulnérabilité

Afficher un message d'avertissement avant l'ouverture de session peut permettre d'éviter une attaque en avertissant l'attaquant de sa mauvaise conduite avant qu'il n'intervienne. Cela peut également aider à renforcer la stratégie d'entreprise en indiquant aux employés la stratégie à adopter lors du processus d'ouverture de session.

Contre-mesures

Configurez les paramètres Contenu du message pour les utilisateurs essayant d’ouvrir une session et Titre du message pour les utilisateurs essayant d’ouvrir une session sur une valeur appropriée à votre entreprise.

Remarque : Tout avertissement affiché doit être approuvé par les représentants juridiques et des ressources humaines de votre entreprise.

Impact potentiel

Les utilisateurs visualisent un message dans une boîte de dialogue avant d'ouvrir une session sur la console du serveur.

Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas ou le contrôleur de domaine ne serait pas disponible)

Ce paramètre de stratégie détermine le nombre d'utilisateurs différents autorisés à se connecter à un domaine Windows en utilisant des informations de compte mises en cache. Il est possible de placer dans le cache local les informations d'ouverture de session de sorte que s'il s'avère impossible de contacter un contrôleur de domaine lors des connexions suivantes, un utilisateur peut quand même ouvrir une session. Ce paramètre de stratégie détermine le nombre d'utilisateurs uniques pour lesquels les informations de connexion sont placées dans le cache local.

Si un contrôleur de domaine n'est pas disponible et que les informations d'ouverture de session d'un utilisateur se trouvent dans le cache, l'utilisateur reçoit le message suivant :

« Le contrôleur de domaine pour votre domaine n'a pu être contacté You have been logged on using cached account information. Les changements effectués sur votre profil depuis votre dernière session ne sont peut-être pas disponibles. »

Si un contrôleur de domaine n'est pas disponible et que les informations d'ouverture de session d'un utilisateur ne se trouvent pas dans le cache, l'utilisateur reçoit le message suivant :

Le système n'a pas pu ouvrir de session, car le domaine <NOM_DOMAINE> n'est pas disponible

Le paramètre Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas ou le contrôleur de domaine ne serait pas disponible) peut prendre les valeurs suivantes :

Nombre défini par l'utilisateur, entre 0 et 50
Non défini

Vulnérabilité

Le nombre attribué à ce paramètre de stratégie indique le nombre d'utilisateurs dont les informations d'ouverture de session sont placées dans le cache local par les serveurs. Si ce nombre est défini sur 10, le serveur place dans le cache les informations d'ouverture de session se rapportant à 10 utilisateurs. Lorsqu'un onzième utilisateur ouvre une session sur l'ordinateur, le serveur écrase la session la plus ancienne.

Les informations d'identification des utilisateurs qui accèdent à la console du serveur sont placées dans le cache de ce serveur. Un attaquant ayant accès au système de fichiers du serveur peut localiser ces informations cachées et avoir recours à une attaque en force pour essayer de déterminer les mots de passe des utilisateurs.

Pour contrer ce type d'attaque, Windows chiffre les informations et dissimule son emplacement physique.

Contre-mesures

Configurez le paramètre Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas où le contrôleur de domaine ne serait pas disponible) sur 0 afin de désactiver la mise en cache locale des informations d'ouverture de session. Parmi les contre-mesures supplémentaires, on peut mentionner la mise en vigueur de stratégies de mots de passe forts et la protection physique des emplacements des ordinateurs.

Impact potentiel

Les utilisateurs ne pourront pas se connecter aux ordinateurs s'il n'existe pas de contrôleur de domaine pour les authentifier. Il est possible que les entreprises configurent cette valeur sur 2 pour les ordinateurs d'utilisateur final, notamment pour les utilisateurs nomades. Une valeur configurée sur 2 signifie que les informations d'ouverture de session de l'utilisateur se trouvent toujours dans le cache, même si un membre du service informatique vient de se connecter sur son ordinateur pour effectuer la maintenance du système. Cette méthode permet aux utilisateurs d'ouvrir une session sur leurs ordinateurs lorsqu'ils ne sont pas connectés au réseau de l'entreprise.

Ouverture de session interactive : Prévenir l'utilisateur qu'il doit changer son mot de passe avant qu'il n'expire

Ce paramètre de stratégie détermine le nombre de jours à l'avance auquel les utilisateurs sont avertis de l'expiration de leur mot de passe. Grâce à cet avertissement anticipé, l'utilisateur a le temps de définir un mot de passe suffisamment fort.

Le paramètre Ouverture de session interactive : Prévenir l'utilisateur qu'il doit changer son mot de passe avant qu'il n'expire admet les valeurs suivantes :

Nombre de jours défini par l'utilisateur, entre 1 et 999
Non défini

Vulnérabilité

Microsoft recommande de configurer les mots de passe utilisateur de façon à ce qu'ils expirent périodiquement. Il est nécessaire que les utilisateurs soient avertis de l'expiration prochaine de leur mot de passe pour ne pas trouver leur ordinateur verrouillé par inadvertance lors de l'expiration. Cette condition peut être source de confusion pour les utilisateurs qui accèdent au réseau en local ou peut les empêcher de se connecter au réseau de l'entreprise à distance (par numérotation ou par un réseau privé virtuel).

Contre-mesures

Configurez le paramètre Ouverture de session interactive : Prévenir l'utilisateur qu'il doit changer son mot de passe avant qu'il n'expire sur 14 jours.

Impact potentiel

Les utilisateurs verront une boîte de dialogue les invitant à modifier leur mot de passe à chaque connexion au domaine lorsque leur mot de passe est configuré pour expirer dans 14 jours maximum.

Ouverture de session interactive : Nécessite l'authentification par le contrôleur de domaine pour le déverrouillage de la station de travail

Les informations de connexion permettent de déverrouiller un ordinateur bloqué. Pour les comptes de domaine, le paramètre Ouverture de session interactive : Nécessite l'authentification par le contrôleur de domaine pour le déverrouillage de la station de travail détermine s'il est nécessaire de contacter un contrôleur de domaine pour déverrouiller un ordinateur. Si ce paramètre est activé, un contrôleur de domaine doit authentifier le compte de domaine utilisé pour déverrouiller l'ordinateur. Si vous désactivez ce paramètre, la confirmation des informations de connexion avec un contrôleur de domaine n'est pas nécessaire pour qu'un utilisateur puisse déverrouiller l'ordinateur. Cependant, si vous configurez le paramètre Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas ou le contrôleur de domaine ne serait pas disponible) sur une valeur supérieure à zéro, les informations d'identification de l'utilisateur se trouvant dans le cache sont utilisées pour déverrouiller l'ordinateur.

Remarque : Ce paramètre s'applique également aux ordinateurs Windows 2000, mais n'est pas disponible via les outils du Gestionnaire de configuration de sécurité sur ces ordinateurs.

Le paramètre Ouverture de session interactive : Nécessite l'authentification par le contrôleur de domaine pour le déverrouillage de la station de travail peut prendre les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Par défaut, l'ordinateur place dans le cache mémoire les informations d'identification des utilisateurs qui se sont authentifiés localement. Il a recours à ces informations cachées pour authentifier toute personne essayant de déverrouiller la console. Lorsque les informations mises en cache sont utilisées, toute modification récemment apportée au compte, comme des attributions de droits d'utilisateur, un verrouillage ou une désactivation du compte, n'est pas prise en compte ni appliquée après l'authentification du compte. Les privilèges utilisateur ne sont pas actualisés et (plus important encore) les comptes désactivés sont toujours capables de déverrouiller la console de l'ordinateur.

Contre-mesures

Configurez le paramètre Ouverture de session interactive : Nécessite l'authentification par le contrôleur de domaine pour le déverrouillage de la station de travail sur Activé et configurez le paramètre Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas ou le contrôleur de domaine ne serait pas disponible) sur 0.

Impact potentiel

Lorsque la console d'un ordinateur est verrouillée par un utilisateur ou automatiquement par le délai d'expiration d'un économiseur d'écran, elle ne peut être déverrouillée que si l'utilisateur est capable de s'authentifier à nouveau auprès du contrôleur de domaine. Si aucun contrôleur de domaine n'est disponible, les utilisateurs ne peuvent pas déverrouiller leur station de travail. Si vous configurez le paramètre Ouverture de session interactive : Nombre d'ouvertures de session précédentes dans le cache (au cas ou le contrôleur de domaine ne serait pas disponible) sur 0,les utilisateurs dont les contrôleurs de domaine sont indisponibles (utilisateurs mobiles ou distants, par exemple) ne pourront pas ouvrir de session.

Ouverture de session interactive : Carte à puce nécessaire

Ce paramètre de stratégie nécessite que les utilisateurs ouvrent une session sur un ordinateur avec une carte à puce.

Remarque : Ce paramètre s'applique également aux ordinateurs Windows 2000, mais n'est pas disponible via les outils du Gestionnaire de configuration de sécurité sur ces ordinateurs.

Le paramètre Ouverture de session interactive : Carte à puce nécessaire peut prendre les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les exigences relatives aux mots de passe complexes et longs pour l'authentification renforcent la sécurité du réseau, en particulier si les utilisateurs doivent changer régulièrement leurs mots de passe. Cette approche limite les risques qu'un attaquant puisse deviner le mot de passe d'un utilisateur par le biais d'une attaque en force. Cependant, il est difficile d'obliger les utilisateurs à choisir des mots de passe fiables, et même ces mots de passe sont vulnérables aux attaques en force si un attaquant dispose du temps et des ressources informatiques nécessaires. L'adoption de cartes à puce à la place des mots de passe pour l'authentification renforce radicalement la sécurité, car la technologie actuelle interdit quasiment toute usurpation d'identité d'un utilisateur par un attaquant. Les cartes à puce exigeant des numéros d'identification personnels (PIN) fournissent une authentification à deux facteurs. En d'autres termes, l'utilisateur doit à la fois posséder la carte à puce et connaître son code PIN. Un attaquant qui capture le trafic d'authentification entre l'ordinateur de l'utilisateur et le contrôleur du domaine aura beaucoup de mal à le déchiffrer et même s'il y parvient, à la prochaine ouverture de session de l'utilisateur sur le réseau, une nouvelle clé de session sera générée pour crypter le trafic entre l'utilisateur et le contrôleur de domaine.

Contre-mesures

Pour les comptes sensibles, émettez des cartes à puce pour les utilisateurs et configurez le paramètre Ouverture de session interactive : Carte à puce nécessaire sur Activé.

Impact potentiel

Tous les utilisateurs devront utiliser une carte à puce pour ouvrir une session sur le réseau, l'entreprise devra donc être équipée d'une infrastructure de clé publique (PKI) fiable, de cartes à puce et de lecteurs de carte à puce pour tous les utilisateurs. Ces exigences sont des défis significatifs, car expertise et ressources sont nécessaires pour planifier et déployer ces technologies. Cependant, Windows Server 2003 inclut des services de certificats, un service extrêmement avancé pour mettre en œuvre et gérer les certificats. Lorsque les services de certificats sont combinés à Windows XP, des fonctionnalités telles que l'inscription et le renouvellement automatiques d'utilisateur et d'ordinateur deviennent disponibles.

Ouverture de session interactive : Comportement lorsque la carte à puce est retirée

Ce paramètre de stratégie détermine la situation produite en cas de retrait de la carte à puce d'un utilisateur connecté du lecteur de cartes.

Le paramètre Ouverture de session interactive : Comportement lorsque la carte à puce est retirée peut prendre les valeurs suivantes :

Aucune action
Verrouiller la station de travail
Forcer la fermeture de session
Non défini

Vulnérabilité

Si des cartes à puce sont utilisées pour l'authentification, l'ordinateur devrait automatiquement se verrouiller lors du retrait de la carte. Cette approche empêche des utilisateurs malveillants d'accéder aux ordinateurs d'utilisateurs qui oublient de verrouiller manuellement leurs postes de travail lorsqu'ils sont en déplacement.

Contre-mesures

Configurez le paramètre Comportement lorsque la carte à puce est retirée sur Verrouiller la station de travail.

Si vous sélectionnez Verrouiller la station de travail dans la boîte de dialogue Propriétés de ce paramètre de stratégie, le poste de travail se verrouille au retrait de la carte à puce. Les utilisateurs peuvent quitter le site, emporter leur carte à puce et maintenir la protection d'une session.

Si vous sélectionnez Forcer la fermeture de session dans la boîte de dialogue Propriétés de ce paramètre de stratégie, l'utilisateur est automatiquement déconnecté lors du retrait de la carte à puce.

Impact potentiel

Les utilisateurs devront insérer à nouveau leur carte à puce et spécifier à nouveau leur PIN lorsqu'ils reviennent à leur station de travail.

Client et serveur réseau Microsoft : Signer numériquement les communications (quatre paramètres associés)

Il existe quatre paramètres distincts associés aux signatures numériques des communications par protocole SMB (Server Message Block) :

Client réseau Microsoft : Signer numériquement les communications (toujours)
Serveur réseau Microsoft : Signer numériquement les communications (toujours)
Client réseau Microsoft : Signer numériquement les communications (lorsque le serveur l'accepte)
Serveur réseau Microsoft : Signer numériquement les communications (lorsque le client l'accepte)

Les valeurs possibles pour chacun de ces paramètres de stratégie sont les suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

L'implémentation de signatures numériques dans les réseaux dont la sécurité est élevée permet d'éviter l'usurpation d'identité des clients et des serveurs. Ce type d'usurpation d'identité, également nommé piratage de session, utilise des outils qui permettent à un attaquant ayant accès au même réseau que le client ou le serveur, d'interrompre, de mettre un terme ou de voler une session en cours. Les attaquants peuvent potentiellement intercepter et modifier les paquets SMB non signés, puis modifier le trafic et l'acheminer de façon à ce que le serveur puisse exécuter des actions indésirables. Ils peuvent également se faire passer pour le serveur ou le client après une authentification légitime et obtenir un accès non autorisé aux données.

SMB est le protocole de partage des ressources pris en charge par de nombreux systèmes d'exploitation Microsoft. Il est à la base du système NetBIOS et de nombreux autres protocoles. Les signatures SMB authentifient à la fois les utilisateurs et les serveurs hébergeant les données. Si l'une ou l'autre partie échoue au processus d'authentification, la transmission des données n'a pas lieu.

Remarque : Une autre contre-mesure pouvant protéger tout le trafic réseau consisterait à mettre en œuvre les signatures numériques avec IPSec. Certains accélérateurs basés sur du matériel pour le chiffrement et la signature IPSec pourraient servir à réduire l'impact sur les performances des unités centrales des serveurs. Il n'existe pas d'accélérateurs de ce type pour la signature SMB.

Contre-mesures

Configurez les paramètres comme suit :

Client réseau Microsoft : Signer numériquement les communications (toujours) sur Désactivé
Serveur réseau Microsoft : Signer numériquement les communications (toujours) sur Désactivé
Client réseau Microsoft : Signer numériquement les communications (lorsque le serveur l'accepte) sur Activé
Serveur réseau Microsoft : Signer numériquement les communications (lorsque le client l'accepte) sur Activé

Il est recommandé pour certaines ressources de configurer tous ces paramètres sur Activé. Cependant, cette configuration peut entraîner une baisse des performances sur les ordinateurs clients et empêcher les communications avec les systèmes d'exploitation et les applications héritées SMB.

Impact potentiel

Les implémentations Windows 2000 Server, Windows 2000 Professionnel, Windows Server 2003 et Windows XP Professionnel du protocole SMB de partage de fichiers et d'impression prennent en charge une authentification mutuelle, ce qui empêche les attaques de piratage de session et assure l'authentification de message afin d'éviter les attaques « man-in-the-middle » (attaque de l'intercepteur). La signature SMB fournit cette authentification en plaçant une signature numérique dans chaque paquet SMB, qui est ensuite vérifiée par le client et le serveur. L'implémentation de la signature SMB peut avoir un impact négatif sur les performances car chaque paquet doit être signé et vérifié. Si vous configurez des ordinateurs afin qu'ils ignorent toutes les communications SMB non signées, les anciens systèmes d'exploitation et applications ne peuvent pas se connecter. Si vous désactivez complètement toute signature SMB, les ordinateurs seront vulnérables aux attaques de piratage de session.

Client réseau Microsoft : Envoyer un mot de passe non chiffré aux serveurs SMB tierce partie

Ce paramètre de stratégie permet au redirecteur SMB d'envoyer des mots de passe en clair aux serveurs, autres que SMB Microsoft, qui ne prennent pas en charge le cryptage de mots de passe au cours de l'authentification.

Le paramètre Client réseau Microsoft : Envoyer un mot de passe non chiffré aux serveurs SMB tierce partie admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si vous activez ce paramètre de stratégie, le serveur peut transmettre des mots de passe en clair sur le réseau à d'autres ordinateurs proposant des services SMB. Il est possible que ces autres ordinateurs n'utilisent aucun des mécanismes de sécurité SMB inclus avec Windows Server 2003.

Contre-mesures

Configurez le paramètre Client réseau Microsoft : Envoyer un mot de passe non chiffré aux serveurs SMB tierce partie sur Désactivé.

Impact potentiel

Il est possible que certains anciens systèmes d'exploitation et applications tels que MS-DOS, Windows for Workgroups 3.11 et Windows 95a ne puissent pas communiquer avec les serveurs de votre entreprise via le protocole SMB.

Serveur réseau Microsoft : Durée d'inactivité avant la suspension d'une session

Ce paramètre de stratégie détermine la durée d'inactivité d'une session SMB avant sa suspension. Les administrateurs peuvent utiliser ce paramètre de stratégie pour contrôler à quel moment un ordinateur suspend une session SMB inactive. La session se rétablit automatiquement à la reprise de l'activité du client. Une valeur de 0 déconnecte une session inactive aussi rapidement que possible. La valeur maximale est 99999, qui correspond à 208 jours ; concrètement, cette valeur désactive le paramètre.

Le paramètre Serveur réseau Microsoft : Durée d'inactivité avant la suspension d'une session peut prendre les valeurs suivantes :

Période de temps définie par l'utilisateur (en minutes)
Non défini

Vulnérabilité

Chaque session SMB consomme des ressources du serveur et de nombreuses sessions nulles ralentissent le serveur, voire entraînent sa panne. Un attaquant pourrait établir des sessions SMB de façon répétitive jusqu'à ce que les services SMB du serveur ralentissent ou ne répondent plus.

Contre-mesures

Configurez le paramètre Serveur réseau Microsoft : Durée d'inactivité avant la déconnexion d'une session sur 15 minutes.

Impact potentiel

L'impact sera minime car les sessions SMB seront automatiquement rétablies lorsque le client reprendra son activité.

Serveur réseau Microsoft : Déconnecter les clients à l'expiration du délai de connexion

Ce paramètre de stratégie détermine s'il est nécessaire de déconnecter l'utilisateur de l'ordinateur local hors des heures d'ouverture de session valides figurant dans le compte d'utilisateur. Il affecte le composant SMB. Si vous activez ce paramètre de stratégie, les sessions client établies avec le service SMB sont forcées de se déconnecter à l'expiration du délai de session des clients. Lorsque ce paramètre de stratégie est désactivé, la session en cours d'un client est conservée après l'expiration des horaires de connexion. Si vous activez ce paramètre de stratégie, vous devez activer également le paramètre Sécurité réseau : Forcer la fermeture de session à l'expiration du délai de connexion.

Le paramètre Serveur réseau Microsoft : Déconnecter les clients à l'expiration du délai de connexion admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si votre entreprise configure des heures de connexion pour les utilisateurs, cela a du sens d'activer ce paramètre de stratégie. Sinon, les utilisateurs qui ne sont pas autorisés à accéder aux ressources réseaux en dehors du temps imparti risqueraient de pouvoir continuer à accéder à ces dernières par l'intermédiaire de sessions établies pendant les heures autorisées.

Contre-mesures

Activez le paramètre Serveur réseau Microsoft : Déconnecter les clients à l'expiration du délai de connexion.

Impact potentiel

Si votre entreprise ne spécifie pas de délai de connexion, ce paramètre de stratégie n'aura aucun effet. Dans le cas contraire, le système mettra fin aux sessions utilisateur existantes à l'expiration du délai de connexion.

Accès réseau : Permettre la traduction de noms/SID anonymes

Ce paramètre de stratégie détermine si un utilisateur anonyme peut demander les attributs SID d'un autre utilisateur.

Le paramètre Accès réseau : Permettre la traduction de noms/SID anonymes admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si ce paramètre de stratégie est activé, un utilisateur avec l'accès local peut utiliser le SID du compte Administrateur bien connu pour obtenir le nom réel du compte Administrateur intégré, même s'il a été renommé. Cette personne pourra ensuite utiliser le nom de compte pour initier une attaque de recherche de mot de passe.

Contre-mesures

Configurez le paramètre Accès réseau : Permettre la traduction de noms/SID anonymes sur Désactivé.

Impact potentiel

Désactivé correspond à la configuration par défaut de ce paramètre de stratégie sur les ordinateurs membres ; elle n'a donc aucune influence sur eux. La configuration par défaut des contrôleurs de domaine est définie sur Activée. Si vous désactivez ce paramètre de stratégie sur les contrôleurs de domaine, les ordinateurs hérités ne pourront pas communiquer avec les domaines basés sur Windows Server 2003. Il est notamment possible que les ordinateurs suivants ne fonctionnent pas :

les serveurs de service d'accès à distance sous Windows NT 4.0
les serveurs Microsoft SQL Servers™ exécutés sur les ordinateurs Windows NT 3.x ou Windows NT 4.0
les serveurs de service d'accès à distance ou Microsoft SQL s'exécutant sur des ordinateurs Windows 2000 et situés dans des domaines Windows NT 3.x ou Windows NT 4.0.

Accès réseau : Ne pas autoriser l'énumération anonyme des comptes SAM

Ce paramètre de stratégie détermine les autorisations supplémentaires octroyées aux connexions anonymes à l'ordinateur. Windows autorise les utilisateurs anonymes à effectuer certaines activités, comme l'énumération des noms des comptes de domaine et des partages de réseau. Ceci est pratique, par exemple lorsqu'un administrateur veut accorder aux utilisateurs l'accès dans un domaine approuvé ne conservant pas une approbation réciproque. Toutefois, même si ce paramètre est activé, les utilisateurs anonymes ont toujours accès à des ressources dotées d'autorisations incluant explicitement le groupe intégré spécial ANONYMOUS LOGON.

Dans Windows 2000, un paramètre similaire appelé Additional Restrictions for Anonymous Connections gérait la valeur de registre RestrictAnonymous, située dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\LSA. Dans Windows Server 2003, les paramètres de stratégie Accès réseau : Ne pas autoriser l'énumération anonyme des comptes SAM et Accès réseau : Ne pas autoriser l'énumération anonyme des comptes et partages SAM remplacent le paramètre de stratégie Windows 2000. Ils gèrent les valeurs de registre respectivement appelées RestrictAnonymousSAM et RestrictAnonymous, situées toutes les deux dans la clé de registre HKLM\System\CurrentControlSet\Control\Lsa\.

Le paramètre Accès réseau : Ne pas autoriser l'énumération anonyme des comptes SAM admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un utilisateur non autorisé pourrait lister de façon anonyme les noms de compte, puis utiliser ces informations pour deviner les mots de passe ou réaliser des attaques de piratage par subversion psychologique (« social engineering »). (La manipulation consiste à utiliser différentes ruses pour tromper les utilisateurs afin d'obtenir leur mot de passe ou d'autres types de données de sécurité.)

Contre-mesures

Configurez le paramètre Accès réseau : Ne pas autoriser l'énumération anonyme des comptes SAM sur Activé.

Impact potentiel

Il sera impossible d'établir des relations de confiance avec des domaines Windows NT 4.0. De même, les ordinateurs clients qui exécutent d'anciennes versions du système d'exploitation Windows, telles que Windows NT 3.51 et Windows 95, rencontreront des problèmes lorsqu'ils tenteront d'utiliser des ressources sur le serveur.

Accès réseau : Ne pas autoriser l'énumération anonyme des comptes et partages SAM

Ce paramètre de stratégie détermine si l'énumération anonyme des comptes et des partages SAM est autorisée. Comme mentionné dans la section précédente, Windows autorise les utilisateurs anonymes à effectuer certaines activités, comme énumérer les noms des comptes de domaine et des partages de réseau. Ceci est pratique, par exemple lorsqu'un administrateur veut accorder aux utilisateurs l'accès dans un domaine approuvé ne conservant pas une approbation réciproque. Vous pouvez activer ce paramètre de stratégie si vous ne voulez pas autoriser l'énumération anonyme de comptes et partages SAM. Toutefois, même s'il est activé, les utilisateurs anonymes ont toujours accès à des ressources dotées d'autorisations incluant explicitement le groupe intégré spécial ANONYMOUS LOGON.

Dans Windows 2000, un paramètre similaire appelé Additional Restrictions for Anonymous Connections gérait la valeur de registre RestrictAnonymous, située dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\LSA. Dans Windows Server 2003, les paramètres de stratégie Accès réseau : Ne pas autoriser l'énumération anonyme des comptes SAM et Accès réseau : Ne pas autoriser l'énumération anonyme des comptes et partages SAM remplacent le paramètre de stratégie Windows 2000. Ils gèrent des valeurs de registre respectivement appelées RestrictAnonymousSAM et RestrictAnonymous, situées toutes les deux dans la clé de registre HKLM\System\CurrentControlSet\Control\Lsa\.

Le paramètre Accès réseau : Ne pas autoriser l'énumération anonyme des comptes et partages SAM admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un utilisateur non autorisé pourrait lister de façon anonyme les noms de compte et les ressources partagées, puis utiliser ces informations pour deviner les mots de passe ou réaliser des attaques de piratage par subversion psychologique (social engineering).

Contre-mesures

Configurez le paramètre Accès réseau : Ne pas autoriser l'énumération anonyme des comptes et partages SAM sur Activé.

Impact potentiel

Il sera impossible d'accorder l'accès aux utilisateurs d'un autre domaine par le biais d'une relation de confiance unilatérale, car les administrateurs du domaine d'approbation ne pourront pas énumérer les listes de comptes de l'autre domaine. Les utilisateurs qui accèdent de façon anonyme aux serveurs de fichiers et d'impression ne pourront pas lister les ressources réseau partagées sur ces serveurs. Les utilisateurs devront s'authentifier avant de pouvoir visualiser les listes des imprimantes et dossiers partagés.

Accès réseau : Ne pas autoriser le stockage d'informations d'identification ou des passeports .NET pour l'authentification du réseau

Ce paramètre de stratégie détermine si les paramètres Noms et mots de passe utilisateur enregistrés permettent d'enregistrer les mots de passe ou les informations d'identification pour une utilisation ultérieure après obtention de l'authentification au domaine. Si vous activez ce paramètre de stratégie, la fonction Noms et mots de passe utilisateur enregistrés de Windows n'enregistrera pas les mots de passe et les informations d'identification.

Le paramètre Accès réseau : Ne pas autoriser le stockage d'informations d'identification ou des passeports .NET pour l'authentification du réseau admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Il est possible pour l'utilisateur qui a ouvert une session sur l'ordinateur d'accéder aux mots de passe cachés. Cette information peut sembler évidente, mais un problème peut se poser si l'utilisateur exécute sans le savoir un code hostile qui lit les mots de passe et les transmet à un autre utilisateur non autorisé.

Remarque : Pour réduire vraiment ce type de risque impliquant un code hostile, les entreprises doivent implémenter et gérer de façon efficace une solution anti-virus pour l'entreprise combinée à des stratégies de restriction sur les logiciels sensibles. Pour plus d'informations sur les stratégies de restriction sur les logiciels, reportez-vous au chapitre 8, « Stratégies de restriction logicielle ».

Contre-mesures

Configurez le paramètre Accès réseau : Ne pas autoriser le stockage d'informations d'identification ou des passeports .NET pour l'authentification du réseau sur Activé.

Impact potentiel

Les utilisateurs seront forcés de saisir leur mot de passe dès qu'ils ouvrent une session sur leur compte Passeport ou sur d'autres ressources réseau non accessibles pour leur compte de domaine. Ce paramètre de stratégie ne devrait avoir aucun impact sur les utilisateurs accédant aux ressources réseau configurées pour autoriser l'accès avec leur compte de domaine Active Directory.

Accès réseau : Les autorisations Tout le monde s'appliquent aux utilisateurs anonymes

Ce paramètre de stratégie détermine les autorisations supplémentaires octroyées aux connexions anonymes à l'ordinateur. Si vous activez ce paramètre de stratégie, les utilisateurs anonymes peuvent énumérer les noms de comptes de domaine, les partages réseaux et exécuter certaines autres activités. Ceci est pratique, par exemple lorsqu'un administrateur veut accorder aux utilisateurs l'accès dans un domaine approuvé ne conservant pas une approbation réciproque.

Par défaut, le jeton créé pour les connexions anonymes n'inclut pas le SID Tout le monde. Par conséquent, les autorisations attribuées au groupe Tout le monde ne s'appliquent pas aux utilisateurs anonymes. Si vous activez ce paramètre de stratégie, le SID Tout le monde est ajouté au jeton créé pour les connexions anonymes. Les utilisateurs anonymes peuvent accéder à n'importe quelle ressource pour laquelle le groupe Tout le monde a reçu des autorisations.

Le paramètre Accès réseau : Les autorisations spécifiques des utilisateurs appartenant au groupe Tout le monde s'appliquent aux utilisateurs anonymes admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un utilisateur non autorisé pourrait lister de façon anonyme les noms de compte et les ressources partagées, puis utiliser ces informations pour deviner les mots de passe, réaliser des attaques par ingénierie sociale ou lancer des attaques par déni de service.

Contre-mesures

Configurez le paramètre Accès réseau : Les autorisations spécifiques des utilisateurs appartenant au groupe Tout le monde s'appliquent aux utilisateurs anonymes sur Désactivé.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Accès réseau : les canaux nommés qui sont accessibles de manière anonyme

Ce paramètre de stratégie détermine quelles sessions de communication (ou canaux) disposeront d'attributs et d'autorisations permettant un accès anonyme.

Le paramètre Accès réseau : Les canaux nommés qui sont accessibles de manière anonyme admet les valeurs suivantes :

Une liste de partages définie par l'utilisateur
Non défini

Pour que ce paramètre de stratégie prenne effet, vous devez également activer le paramètre Accès réseau : Limiter l'accès anonyme aux canaux nommés et aux partages.

Vulnérabilité

Vous pouvez limiter l'accès aux canaux nommés, tels que COMNAP et LOCATOR, pour empêcher un accès non autorisé au réseau. Vous trouverez dans le tableau suivant la liste par défaut des canaux nommés et leurs objectifs.

Tableau 5.1 : Canaux nommés par défaut et accessibles de manière anonyme

Canal nommé	Objet
COMNAP	Canal nommé de SNABase. L'architecture SNA (Systems Network Architecture) est un ensemble de protocoles réseau développés à l'origine pour les gros systèmes IBM.
COMNODE	Canal nommé de serveur SNA.
SQL\QUERY	Canal nommé par défaut pour SQL Server.
SPOOLSS	Canal nommé pour le service du spouleur d'impression.
EPMAPPER	Canal nommé du mappeur de point final.
LOCATOR	Canal nommé du service RPC Locator.
TrkWks	Canal nommé du service Client de suivi de lien distribué.
TrkSvr	Canal nommé du service Serveur de suivi de lien distribué.

Contre-mesures

Configurez le paramètre Accès réseau : Les canaux nommés qui sont accessibles de manière anonyme sur une valeur nulle (activez le paramètre sans spécifier de canaux nommés dans la zone de texte).

Impact potentiel

Cette configuration désactivera l'accès à une session nulle via des applications et des canaux nommés qui reposent sur cette fonction ou sur l'accès non authentifié à des canaux nommés ne fonctionnant plus. Par exemple, avec Microsoft Commercial Internet System 1.0, le service Internet Mail Service s'exécute sous le processus Inetinfo. Inetinfo démarre dans le contexte du compte Système. Lorsque Internet Mail Service doit interroger la base de données Microsoft SQL Server, il utilise le compte Système qui fait appel à des informations d'identification nulles pour accéder à un canal SQL sur l'ordinateur qui exécute SQL Server.

Pour éviter ce problème, reportez-vous à l'article de la Base de connaissances Microsoft « Comment faire pour accéder à des fichiers du réseau à partir d'applications IIS » situé à l'adresse https://support.microsoft.com/kb/207671/fr.

Accès réseau : Les chemins de registre accessibles à distance

Ce paramètre de stratégie détermine les chemins de registre accessibles lorsqu'une application ou un processus fait référence à la clé WinReg pour déterminer des autorisations d'accès.

Le paramètre Accès réseau : Chemins de Registre accessibles à distance admet les valeurs suivantes :

Une liste de chemins définie par l'utilisateur
Non défini

Vulnérabilité

Le registre est une base de données contenant les informations de configuration de l'ordinateur, pour la plupart confidentielles. Un attaquant pourrait utiliser ces informations pour faciliter des activités illicites. Pour réduire ce risque d'attaque, des listes ACL adaptées sont attribuées dans l'ensemble du registre pour assurer leur protection contre l'accès d'utilisateurs non autorisés.

Contre-mesures

Configurez le paramètre Accès réseau : Chemins de Registre accessibles à distance sur une valeur nulle (activez le paramètre sans spécifier de chemin dans la zone de texte).

Impact potentiel

Les outils de gestion à distance, comme Microsoft Baseline Security Analyzer et Microsoft Systems Management Server, ont besoin d'un accès distant au registre pour surveiller et gérer correctement ces systèmes. Si vous supprimez les chemins de registre par défaut de la liste des chemins accessibles, ces outils de gestion à distance pourraient échouer.

Remarque : Si vous voulez accorder l'accès à distance, vous devez également activer le service d'accès à distance au registre.

Accès réseau : Chemins et sous-chemins de Registre accessibles à distance

Ce paramètre de stratégie détermine les chemins et sous-chemins de registre accessibles lorsqu'une application ou un processus fait référence à la clé WinReg pour déterminer des autorisations d'accès.

Le paramètre Accès réseau : Chemins et sous-chemins de Registre accessibles à distance admet les valeurs suivantes :

Une liste de chemins définie par l'utilisateur
Non défini

Vulnérabilité

Comme mentionné précédemment, le registre contient des informations de configuration confidentielles de l'ordinateur, qui pourraient être utilisées par un attaquant pour faciliter des activités non autorisées. Les listes ACL par défaut attribuées dans l'ensemble du registre sont assez restrictives et contribuent à protéger le registre contre l'accès d'utilisateurs non autorisés, ce qui limite le risque de ce type d'attaque.

Contre-mesures

Configurez le paramètre Accès réseau : Chemins et sous-chemins de Registre accessibles à distance sur une valeur nulle (activez le paramètre sans spécifier de chemin dans la zone de texte).

Impact potentiel

Remarque : Si vous voulez accorder l'accès à distance, vous devez également activer le service d'accès à distance au registre.

Accès réseau : Limiter l'accès anonyme aux canaux nommés et aux partages

Lorsque ce paramètre de stratégie est activé, il limite l'accès anonyme aux partages et canaux nommés dans les paramètres Accès réseau : Les canaux nommés qui sont accessibles de manière anonyme et Accès réseau : Les partages accessibles de manière anonyme. Ce paramètre de stratégie contrôle l'accès des sessions nulles aux partages de vos ordinateurs en ajoutant RestrictNullSessAccess et la valeur 1 à la clé de registre HKLM\System\CurrentControlSet\Services\LanManServer\Parameters. Cette valeur de registre active ou désactive les partages de session nulles pour contrôler si le service du serveur limite l'accès aux ressources nommées aux clients non authentifiés.

Le paramètre Accès réseau : Limiter l'accès anonyme aux canaux nommés et aux partages admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les sessions NULL constituent un point faible susceptible d'être exploité par les partages (y compris les partages par défaut) se trouvant sur les ordinateurs de votre environnement.

Contre-mesures

Configurez le paramètre Accès réseau : Limiter l'accès anonyme aux canaux nommés et aux partages sur Activé.

Impact potentiel

Vous pouvez activer ce paramètre de stratégie pour limiter l'accès par sessions nulles aux utilisateurs non authentifiés à tous les canaux et partages du serveur, sauf ceux qui sont répertoriés dans les entrées NullSessionPipes et NullSessionShares.

Accès réseau : Les partages qui sont accessibles de manière anonyme

Ce paramètre de stratégie détermine les partages réseau accessibles aux utilisateurs anonymes.

Le paramètre Accès réseau : Les partages accessibles de manière anonyme admet les valeurs suivantes :

Une liste de partages définie par l'utilisateur
Non défini

Vulnérabilité

Il est très dangereux d'activer ce paramètre. Dans ce cas, tout utilisateur du réseau peut accéder à l'ensemble des partages répertoriés, ce qui peut conduire à l'exposition ou à la corruption des données sensibles.

Contre-mesures

Configurez le paramètre Accès réseau : Les partages accessibles de manière anonyme sur une valeur nulle.

Impact potentiel

L'impact devrait être minime, car il s'agit de la configuration par défaut. Seuls les utilisateurs authentifiés auront accès aux ressources partagées sur le serveur.

Accès réseau : Modèle de partage et de sécurité pour les comptes locaux

Ce paramètre de stratégie détermine le mode d'authentification des ouvertures de session réseau qui utilisent des comptes locaux. Si vous configurez ce paramètre de stratégie sur Classique, les ouvertures de session sur le réseau qui utilisent les informations d'identification du compte local s'authentifient grâce à celles-ci. Si ce paramètre de stratégie est configuré sur Invité seul, les ouvertures de session sur le réseau qui utilisent les comptes locaux sont automatiquement mappées sur le compte Invité. Le modèle Classique permet de contrôler précisément l'accès aux ressources et vous permet d'accorder à différents utilisateurs différents types d'accès à une même ressource. Inversement, le modèle Invité seul traite tous les utilisateurs comme pour le compte utilisateur Invité et ils reçoivent tous le même niveau d'accès à une ressource donnée, soit Lecture seule ou Modification.

La configuration par défaut des systèmes Windows XP Professionnel autonomes est Invité seulement. Le paramètre par défaut pour les ordinateurs Windows XP associés à un domaine et les ordinateurs Windows Server 2003 est Classique.

Remarque : Ce paramètre de stratégie n'a aucune incidence sur les ouvertures de session réseau qui utilisent des comptes de domaine. Il n'affecte pas non plus les ouvertures de session interactives qui sont effectuées à distance via des services tels que Telnet ou Terminal Server.

Lorsque l'ordinateur n'est pas joint à un domaine, ce paramètre de stratégie personnalise également les onglets Partage et Sécurité de l'Explorateur Windows pour qu'ils correspondent au modèle de partage et de sécurité adopté.

Ce paramètre n'a aucune incidence sur les ordinateurs équipés de Windows 2000.

Le paramètre Accès réseau : Modèle de partage et de sécurité pour les comptes locaux admet les valeurs suivantes :

Classique. Les utilisateurs locaux s'authentifient sous leur propre identité.
Invité seul. Les utilisateurs locaux s'authentifient en tant qu'Invité.
Non défini

Vulnérabilité

Avec le modèle Invité seul, tout utilisateur pouvant s'authentifier sur votre ordinateur du réseau est doté des privilèges d'invité. Cela signifie qu'il n'aura probablement pas d'accès en écriture aux ressources partagées de cet ordinateur. Cette restriction renforce la sécurité, mais les utilisateurs autorisés peuvent rencontrer davantage de difficultés pour accéder aux ressources partagées de ces ordinateurs, car les listes ACL sur ces ressources doivent inclure les entrées de contrôle d'accès (ACE) du compte Invité. Avec le modèle Classique, les comptes locaux doivent être protégés par mot de passe. Sinon, en cas d'activation de l'accès Invité, n'importe qui peut utiliser ces comptes utilisateur pour accéder aux ressources système partagées.

Contre-mesures

Pour les serveurs réseau, configurez le paramètre Accès réseau : Modèle de partage et de sécurité pour les comptes locaux sur Classique - les utilisateurs locaux s’authentifient eux-mêmes. Sur les ordinateurs d'utilisateurs finaux, configurez ce paramètre de stratégie sur Invité seulement – les utilisateurs locaux s'authentifient en tant qu'invité.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Sécurité réseau : ne pas stocker de valeurs de hachage de niveau Lan Manager sur la prochaine modification de mot de passe

Ce paramètre de stratégie détermine si LAN Manager peut stocker des valeurs de hachage pour le nouveau mot de passe lors de sa prochaine modification.

Le paramètre Sécurité réseau : Ne pas stocker de valeurs de hachage de LAN Manager lors de la modification suivante du mot de passe admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Le fichier SAM peut être visé par des attaquants qui cherchent à accéder au nom d'utilisateur et aux hachages de mot de passe. Ces attaques utilisent des outils spéciaux pour deviner les mots de passe, qui peuvent ensuite être utilisés pour usurper l'identité des utilisateurs et accéder aux ressources du réseau. L'activation de ce paramètre de stratégie n'empêchera pas ces types d'attaques, mais il leur sera difficile de réussir.

Contre-mesures

Configurez le paramètre Sécurité réseau : Ne pas stocker de valeurs de hachage de LAN Manager lors de la modification suivante du mot de passe sur Activé. Demandez à tous les utilisateurs de définir de nouveaux mots de passe lors de leur prochaine ouverture de session sur le domaine pour que les hachages de LAN Manager soient supprimés.

Impact potentiel

Les systèmes d'exploitation antérieurs, tels que Windows 95, Windows 98 et Windows ME échoueront, de même que certaines applications tierces.

Sécurité réseau : Forcer la fermeture de session quand les horaires de connexion expirent

Ce paramètre de stratégie détermine s'il est nécessaire de déconnecter l'utilisateur de l'ordinateur local hors des heures d'ouverture de session valides figurant dans le compte d'utilisateur. Il affecte le composant SMB. Si vous activez ce paramètre de stratégie, les sessions client établies avec le serveur SMB sont déconnectées à l'expiration du délai de session des clients. Lorsque ce paramètre de stratégie est désactivé, la session en cours d'un client est conservée après l'expiration des horaires de connexion.

Le paramètre Sécurité réseau : Forcer la fermeture de session à l'expiration du délai de connexion admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Si vous désactivez ce paramètre de stratégie, un utilisateur pourrait rester connecté à l'ordinateur en dehors de ses horaires de connexion alloués.

Contre-mesures

Configurez le paramètre Sécurité réseau : Forcer la fermeture de session à l'expiration du délai de connexion sur Activé. Ce paramètre de stratégie ne s'applique pas aux comptes Administrateur.

Impact potentiel

À l'expiration du délai de connexion d'un utilisateur, les sessions SMB prennent fin. L'utilisateur doit alors attendre le créneau horaire suivant pour ouvrir une nouvelle session.

Sécurité réseau : Niveau d'authentification LAN Manager

LAN Manager (LM) représente une ancienne famille de logiciels client/serveur Microsoft qui permet aux utilisateurs d'associer des ordinateurs personnels sur un seul réseau. Les capacités de réseau comprennent un partage de fichiers et d'impression transparent, des fonctions de sécurité pour l'utilisateur et des outils d'administration réseau. Dans les domaines Active Directory, Kerberos est le protocole d'authentification par défaut. Cependant, si le protocole Kerberos n'est pas négocié pour une raison quelconque, Active Directory utilisera LM, NTLM ou NTLMv2.

L'authentification de LAN Manager inclut les variantes LM, NTLM et NTLM version 2 (NTLMv2). Ce protocole est utilisé pour authentifier tous les clients Windows lorsqu'ils exécutent les opérations suivantes :

intégration d'un domaine ;
authentification entre les forêts Active Directory ;
authentification sur des domaines de niveau inférieur ;
authentification sur des ordinateurs qui n'exécutent pas Windows 2000, Windows Server 2003 ou Windows XP ;
authentification sur des ordinateurs qui ne sont pas dans le domaine.

Le paramètre Sécurité réseau : Niveau d'authentification de LAN Manager admet les valeurs suivantes :

Envoyer les réponses LM et NTLM
Envoyer LM et NTLM — utiliser la sécurité de session NTLM version 2 si négociée
Envoyer uniquement les réponses NTLM
Envoyer uniquement les réponses NTLMv2
Envoyer uniquement les réponses NTLMv2\refuser LM
Envoyer des réponses NTLM version 2 uniquement\refuser LM et NTLM
Non défini

Le paramètre Sécurité réseau : Niveau d'authentification de LAN Manager détermine le protocole d'authentification de stimulation/réponse des ouvertures de session réseau utilisé. Ce choix a une incidence sur le niveau du protocole d'authentification qu'utilisent les clients, le niveau de sécurité de session que négocient les ordinateurs et le niveau d'authentification qu'acceptent les serveurs, de la façon suivante :

Envoyer les réponses LM et NTLM. Les clients utilisent l'authentification LM et NTLM et n'ont jamais recours à la sécurité de session NTLMv2. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Envoyer LM et NTLM – utiliser la sécurité de session NTLM version 2 si négociée. les clients utilisent l'authentification LM et NTLM ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Envoyer uniquement les réponses NTLM. les clients utilisent l'authentification NTLM uniquement ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Envoyer uniquement les réponses NTLMv2. les clients utilisent l'authentification NTLMv2 uniquement ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Envoyer uniquement les réponses NTLMv2\refuser LM. les clients utilisent l'authentification NTLMv2 uniquement ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent l'authentification LM (acceptent uniquement l’authentification NTLM et NTLMv2).
Envoyer des réponses NTLM version 2 uniquement\refuser LM et NTLM. les clients utilisent l'authentification NTLMv2 uniquement ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent l'authentification LM et NTLM(acceptent uniquement l’authentification NTLMv2).

Ces paramètres correspondent aux niveaux traités dans d'autres documents Microsoft comme indiqué ci-après :

Niveau 0 – Envoyer les réponses LM et NTLM ; ne jamais utiliser la sécurité de session NTLM version 2. Les clients utilisent l'authentification LM et NTLM et n'ont jamais recours à la sécurité de session NTLMv2. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Niveau 1 – Utiliser la sécurité de session NTLM version 2 si négociée. Les clients utilisent l'authentification LM et NTLM ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Niveau 2 – Envoyer uniquement les réponses NTLM. Les clients utilisent l'authentification NTLM uniquement ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Niveau 3 – Envoyer uniquement les réponses NTLMv2. Les clients utilisent l'authentification NTLMv2 ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine acceptent l’authentification LM, NTLM et NTLMv2.
Niveau 4 – Les contrôleurs de domaine refusent les réponses LM. Les clients utilisent l'authentification NTLM ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent l'authentification LM, ils acceptent l’authentification NTLM et NTLMv2.
Niveau 5 – Les contrôleurs de domaine refusent les réponses LM et NTLM (acceptent uniquement NTLMv2). Les clients utilisent l'authentification NTLMv2 ainsi que la sécurité de session NTLMv2 si le serveur la prend en charge. Les contrôleurs de domaine refusent l'authentification LM et NTLM (acceptent uniquement l’authentification NTLMv2).

Vulnérabilité

Les clients Windows 2000, Windows Server 2003 et Windows XP sont configurés par défaut pour envoyer les réponses d'authentification LM et NTLM (les clients Windows 9x envoient uniquement des réponses LM). Le paramètre par défaut sur les serveurs permet à tous les clients de s'authentifier auprès des serveurs et d'utiliser leurs ressources. Toutefois, dans ce cas, les réponses LM — la forme la plus faible de réponse d'authentification — sont envoyées sur le réseau et il est potentiellement possible pour les attaquants de s'emparer de ce trafic pour reproduire plus facilement le mot de passe de l'utilisateur.

Les systèmes d'exploitation Windows 9x et Windows NT ne peuvent pas utiliser le protocole Kerberos version 5 pour l'authentification. C'est la raison pour laquelle, dans un domaine Windows Server 2003, ces ordinateurs s'authentifient par défaut auprès des protocoles LM et NTLM pour une authentification réseau. Vous pouvez mettre en place un protocole d'authentification plus sécurisé pour Windows 9x et Windows NT en utilisant NTLMv2. Pour le processus d'ouverture de session, NTLMv2 utilise un canal sécurisé pour protéger le processus d'authentification. Même si vous utilisez NTLMv2 pour les clients et serveurs hérités, les clients et serveurs Windows qui sont membres du domaine utiliseront le protocole Kerberos pour s'authentifier auprès des contrôleurs de domaine Windows Server 2003.

Pour plus d'informations sur le mode d'activation de NTLMv2, reportez-vous à l'article de la Base de Connaissances Microsoft « Comment faire pour activer l'authentification NTLM version 2 » situé à l'adresse https://support.microsoft.com/kb/239869/fr. Microsoft Windows NT 4.0 requiert le Service Pack 4 (SP4) pour prendre en charge NTLMv2. Les plates-formes Windows 9x doivent être équipées du client Directory Service pour prendre en charge NTLMv2.

Contre-mesures

Configurez le paramètre Sécurité réseau : Niveau d'authentification de LAN Manager sur Envoyer uniquement les réponses NTLMv2. Ce niveau d'authentification est fortement recommandé par Microsoft et un certain nombre d'organisations indépendantes lorsque tous les clients prennent en charge NTLMv2.

Impact potentiel

Les clients qui ne prennent pas en charge l'authentification NTLMv2 ne pourront pas s'authentifier dans le domaine ni accéder aux ressources du domaine en utilisant LM et NTLM.

Remarque : Pour toute information sur un correctif garantissant le bon fonctionnement de ce paramètre dans des réseaux comprenant des ordinateurs Windows NT 4.0 avec Windows 2000, Windows XP et des ordinateurs Windows Server 2003, reportez-vous à l'article de la Base de Connaissances Microsoft « Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain » à l'adresse https://support.microsoft.com/kb/305379/fr.

Sécurité réseau : Conditions requises pour la signature de client LDAP

Ce paramètre de stratégie détermine de la manière suivante le niveau de signature des données demandé pour le compte des clients émettant des requêtes LDAP BIND, de la manière suivante :

Aucune. la requête LDAP BIND est émise avec les options spécifiées par l'appelant.
Négociation des signatures. si TLS/SSL (Transport Layer Security/Secure Sockets Layer) n'a pas été démarré, la requête LDAP BIND est initiée avec l'option de signature des données LDAP définie en plus des options spécifiées par l'appelant. Si TLS/SSL a été démarré, la requête LDAP BIND est initiée avec les options spécifiées par l'appelant.
Nécessite la signature. Ce niveau est identique à Négociation des signatures. Toutefois, si la réponse saslBindInProgress intermédiaire du serveur LDAP n'indique pas que la signature du trafic LDAP est nécessaire, l'appelant reçoit un message lui apprenant l'échec de la requête de commande LDAP BIND.

Remarque : Ce paramètre de stratégie n'a pas d'impact sur ldap_simple_bind ou ldap_simple_bind_s. Aucun des clients Microsoft LDAP inclus avec Windows XP Professionnel n'utilise ldap_simple_bind ou ldap_simple_bind_s pour communiquer avec un contrôleur de domaine.

Le paramètre Sécurité réseau : Conditions requises pour la signature de client LDAP admet les valeurs suivantes :

Aucun
Négociation des signatures
Nécessite la signature
Non défini

Vulnérabilité

Le trafic réseau non signé pourrait être la cible d'attaques « man-in-the-middle » (attaque de l'intercepteur) par lesquelles un intrus capture les paquets entre le serveur et le client, les modifie avant de les transmettre au serveur. Dans le cas d'un serveur LDAP, cette faille signifie qu'un attaquant pourrait pousser un serveur à prendre des décisions sur la base de données erronées ou modifiées provenant des requêtes LDAP. Pour réduire ce risque dans votre réseau, vous pouvez implémenter des mesures de sécurité physiques fortes pour protéger l'infrastructure du réseau. Vous pouvez également rendre extrêmement difficiles tous les types d'attaque « man-in-the-middle » (attaque de l'intercepteur) si vous exigez des signatures numériques sur tous les paquets réseau au moyen d'en-têtes d'authentification IPSec.

Contre-mesures

Configurez le paramètre Sécurité réseau : Conditions requises pour la signature de serveur LDAP sur Nécessite la signature.

Impact potentiel

Si vous configurez le serveur de façon à ce qu'il exige des signatures LDAP, vous devez également configurer le client. Si vous ne configurez pas le client, celui-ci ne pourra pas communiquer avec le serveur et de nombreuses fonctions risquent d'échouer, notamment l'authentification utilisateur, la stratégie de groupe et les scripts d'ouverture de session.

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

Ce paramètre de stratégie permet à un ordinateur client de demander la négociation de la confidentialité des messages (cryptage), l'intégrité des messages, le cryptage 128 bits ou la sécurité de session NTLM version 2 (NTLMv2). Ces valeurs dépendent de la valeur du paramètre de stratégie Niveau d'authentification Lan Manager.

Le paramètre Sécurité réseau : Sécurité de session minimale pour les clients basés sur NTLM SSP (y compris RPC sécurisé) admet les valeurs suivantes :

Nécessite une confidentialité de message. La connexion échoue si le chiffrement n'est pas négocié. Le chiffrement convertit les données sous une forme illisible jusqu'à son déchiffrement.
Nécessite une intégrité de message. La connexion échoue si l'intégrité de message n'est pas négociée. La signature du message permet d'évaluer son intégrité. La fonction de signature prouve que le message n'a pas été modifié ; elle joint une signature cryptographique qui identifie l'expéditeur et qui constitue une représentation numérique du message.
Nécessite le cryptage 128 bits La connexion échoue si le chiffrement fort (128 bits) n'est pas négocié.
Nécessite une sécurité de session NTLMv2. La connexion échoue si le protocole NTLMv2 n'est pas négocié.
Non défini.

Vulnérabilité

L'activation de toutes ces options pour ce paramètre contribuera à protéger le trafic réseau qui utilise NTLM SSP (NTLM Security Support Provider) contre les risques d'exposition ou de piratage par un attaquant ayant obtenu l'accès au même réseau. En d'autres termes, ces options permettent de protéger le système contre des attaques « man-in-the-middle » (attaque de l'intercepteur).

Contre-mesures

Activez les quatre options disponibles pour le paramètre de stratégie Sécurité réseau : Sécurité de session minimale pour les clients basés sur NTLM SSP (y compris RPC sécurisé).

Impact potentiel

Les ordinateurs clients qui mettent en vigueur ces paramètres ne pourront pas communiquer avec les anciens serveurs qui ne les prennent pas en charge.

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

Ce paramètre de stratégie permet à un serveur de demander la négociation de la confidentialité des messages (chiffrement), l'intégrité des messages, le chiffrement 128 bits ou la sécurité de session NTLM version 2 (NTLMv2). Ces valeurs dépendent de la valeur du paramètre de sécurité Niveau d'authentification LAN Manager.

Le paramètre Sécurité réseau : Sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris RPC sécurisé) admet les valeurs suivantes :

Nécessite une confidentialité de message. La connexion échoue si le chiffrement n'est pas négocié. Le cryptage convertit les données sous une forme illisible jusqu'à son décryptage.
Nécessite une intégrité de message. La connexion échoue si l'intégrité de message n'est pas négociée. La signature du message permet d'évaluer son intégrité. La fonction de signature prouve que le message n'a pas été modifié ; elle joint une signature cryptographique qui identifie l'expéditeur et qui constitue une représentation numérique du message.
Nécessite le cryptage 128 bits La connexion échoue si le chiffrement fort (128 bits) n'est pas négocié.
Nécessite une sécurité de session NTLMv2. La connexion échoue si le protocole NTLMv2 n'est pas négocié.
Non défini.

Vulnérabilité

L'activation de toutes ces options pour ce paramètre contribuera à protéger le trafic réseau qui utilise NTLM SSP (NTLM Security Support Provider) contre les risques d'exposition ou de piratage par un attaquant ayant obtenu l'accès au même réseau. Autrement dit, ces options permettent de protéger le système contre des attaques « man-in-the-middle » (attaque de l'intercepteur).

Contre-mesures

Activez les quatre options disponibles pour le paramètre Sécurité réseau : Sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris RPC sécurisé).

Impact potentiel

Les anciens clients ne prenant pas en charge ces paramètres de sécurité ne pourront pas communiquer avec l'ordinateur.

Console de récupération : Autoriser l'ouverture de session d'administration automatique

Ce paramètre de stratégie détermine si le mot de passe du compte Administrateur doit être fourni avant que l'accès à l'ordinateur soit accordé. Si vous activez ce paramètre, le compte Administrateur se connecte automatiquement à la Console de récupération de l'ordinateur ; aucun mot de passe n'est requis.

Le paramètre Console de récupération : Autoriser l'ouverture de session d'administration automatique admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

La Console de récupération peut être très utile pour dépanner et réparer des ordinateurs qui ne démarrent pas. Cependant, il est dangereux d'autoriser des connexions automatiques à la console. En effet, quelqu'un peut accéder physiquement au serveur, le débrancher pour l'arrêter, le redémarrer, sélectionner Recover Console dans le menu Restart, puis prendre le contrôle total du serveur.

Contre-mesures

Configurez le paramètre Console de récupération : Autoriser l'ouverture de session d'administration automatique sur Désactivé.

Impact potentiel

Les utilisateurs devront saisir un nom d'utilisateur et un mot de passe pour accéder à la console de récupération.

Console de récupération : Autoriser la copie de disquettes et l'accès à tous les lecteurs et dossiers

Vous pouvez activer ce paramètre de stratégie pour rendre disponible la commande SET de la console de récupération, ce qui vous permet de définir les variables d'environnement correspondantes.

AllowWildCards. permet la prise en charge des caractères génériques pour certaines commandes (comme la commande SUPPR).
AllowAllPaths. permet d'accéder à tous les fichiers et dossiers de l'ordinateur.
AllowRemovableMedia. autorise la copie des fichiers sur un support amovible, comme une disquette.
NoCopyPrompt. supprime l'invite qui s'affiche généralement avant l'écrasement d'un fichier existant.

Le paramètre Console de récupération : Autoriser la copie de disquettes et l'accès à tous les lecteurs et dossiers admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Un attaquant à l'origine du redémarrage du système dans la Console de récupération pourrait voler des données sensibles et ne laisser aucun journal d'audit ou trace d'accès.

Contre-mesures

Configurez le paramètre Console de récupération : Autoriser la copie de disquettes et l'accès aux lecteurs et dossiers sur Désactivé.

Impact potentiel

Les utilisateurs ayant démarré un serveur via la console de récupération et connectés avec le compte Administrateur intégré ne pourront pas copier des fichiers et des dossiers sur une disquette.

Arrêt : Permet au système d'être arrêté sans avoir à se connecter

Ce paramètre de stratégie détermine si un ordinateur peut être arrêté sans avoir à se connecter à Windows. Si vous activez ce paramètre de stratégie, la commande Arrêter s'affiche à l'écran d'ouverture de session Windows. Si vous désactivez ce paramètre de stratégie, l'option Arrêter s'efface de l'écran d'ouverture de session Windows. Cette configuration nécessite que les utilisateurs puissent ouvrir avec succès une session sur l'ordinateur et disposer du droit d'utilisateur Arrêter le système avant de pouvoir arrêter l'ordinateur.

Le paramètre Arrêt : Permet au système d'être arrêté sans avoir à se connecter admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les utilisateurs qui peuvent accéder à la console en local pourraient arrêter l'ordinateur.

Les attaquants pourraient également accéder physiquement à la console locale et redémarrer le serveur, ce qui générerait une condition de refus de service temporaire. Les attaquants pourraient également arrêter le serveur et rendre indisponibles tous ses services et applications.

Contre-mesures

Configurez le paramètre Permet au système d'être arrêté sans avoir à se connecter sur Désactivé.

Impact potentiel

Les opérateurs devront ouvrir une session sur les serveurs pour les arrêter ou les redémarrer.

Arrêt : Efface le fichier d'échange de mémoire virtuelle

Ce paramètre de stratégie détermine si le fichier d'échange de mémoire virtuelle est effacé à l'arrêt de l'ordinateur. Le support de la mémoire virtuelle utilise un fichier d'échange système pour échanger des pages de la mémoire vers le disque lorsqu'elles ne sont pas utilisées. Sur un ordinateur en cours d'exécution, ce fichier est ouvert exclusivement par le système d'exploitation et est bien protégé. Cependant, les ordinateurs qui sont configurés pour permettre à d'autres systèmes d'exploitation de démarrer doivent s'assurer que le fichier d'échange système est nettoyé à l'arrêt de l'ordinateur. Cette confirmation garantit que les informations confidentielles provenant de la mémoire du processus risquant d'être placées dans le fichier d'échange ne sont pas accessibles à un utilisateur non autorisé cherchant à accéder directement à ce fichier après l'arrêt.

Si vous activez ce paramètre de stratégie, le fichier d'échange système est vidé lors d'un arrêt normal. Ce paramètre de stratégie forcera également l'ordinateur à effacer le fichier de mise en veille (Hiberfil.sys) lorsque la mise en veille est désactivée sur un ordinateur portable.

Le paramètre Arrêt : Efface le fichier d’échange de mémoire virtuelle admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Il arrive que les informations importantes conservées dans la mémoire réelle soient régulièrement consignées dans le fichier d'échange pour aider Windows Server 2003 à gérer les fonctions multi-tâches. Un pirate ayant un accès physique à un serveur ayant été arrêté pourrait visualiser le contenu du fichier d'échange. Il pourrait déplacer le volume système sur un autre ordinateur pour y analyser le contenu de ce fichier. Bien que ce processus soit long, il risque d'exposer les données mises en cache de la mémoire RAM dans le fichier d'échange.

Attention : Un attaquant ayant un accès physique au serveur peut contourner cette contre-mesure en débranchant simplement le serveur de sa source d'alimentation.

Contre-mesures

Configurez le paramètre Effacer le fichier d’échange de mémoire virtuelle à l’arrêt du système sur Activé. Cette configuration fait que Windows Server 2003 vide le fichier d'échange lors de l'arrêt de l'ordinateur. Le temps nécessaire à l'exécution de ce processus dépend de la taille du fichier d'échange. Cela peut prendre plusieurs minutes avant que l'ordinateur ne s'arrête complètement.

Impact potentiel

L'arrêt et le redémarrage du serveur prendront davantage de temps, surtout sur les serveurs avec des fichiers d'échange volumineux. Pour un serveur avec 2 Go de RAM et un fichier d'échange de 2 Go, ce paramètre de stratégie pourrait rallonger le processus d'arrêt de 20 à 30 minutes, voire plus. Dans certaines organisations, cet allongement de la durée viole les accords de niveau de service internes. Soyez donc extrêmement prudent avant de mettre en œuvre cette contre-mesure dans votre environnement.

Cryptographie système : Force une protection forte des clés utilisateur enregistrées sur l'ordinateur

Ce paramètre de stratégie détermine si l'utilisation des clés privées par des utilisateurs, comme les clés S-MIME, est assujettie à l'utilisation d'un mot de passe.

Le paramètre Cryptographie système : Force une protection forte des clés utilisateur enregistrées sur l'ordinateur admet les valeurs suivantes :

L'utilisateur n'a pas besoin d'entrer de mot de passe lorsque de nouvelles clés sont enregistrées et utilisées
L'utilisateur doit entrer un mot de passe à la première utilisation de la clé
L'utilisateur doit entrer un mot de passe à la première utilisation de la clé
Non défini

Vulnérabilité

Vous pouvez configurer ce paramètre de stratégie pour que les utilisateurs fournissent un mot de passe différent de celui du domaine, dès lors qu'ils utilisent une clé. Cette configuration complique la tâche d'un attaquant qui cherche à accéder à des clés utilisateur stockées localement, même s'il prend le contrôle de l'ordinateur de l'utilisateur et détermine le mot de passe d'ouverture de session.

Contre-mesures

Configurez le paramètre Cryptographie système : Force une protection forte des clés utilisateur enregistrées sur l'ordinateur sur L'utilisateur doit entrer un mot de passe à chaque utilisation de la clé.

Impact potentiel

Les utilisateurs devront saisir leur mot de passe à chaque fois qu'ils accèderont à une clé qui est enregistrée sur l'ordinateur. Par exemple, s'ils utilisent un certificat S-MIME pour signer numériquement leur courrier électronique, ils seront forcés d'entrer le mot de passe correspondant chaque fois qu'ils envoient un message électronique signé. Certaines entreprises trouveront trop importante la surcharge impliquée par cette configuration. Cependant, ce paramètre devrait au moins être configuré sur L'utilisateur doit entrer un mot de passe à la première utilisation de la clé.

Cryptographie système : Utilisez des algorithmes compatibles FIPS pour le chiffrement, le hachage et la signature

Ce paramètre de stratégie détermine si le fournisseur de sécurité TLS/SSL prend en charge uniquement la suite de chiffrement fort connue sous le nom TLS_RSA_WITH_3DES_EDE_CBC_SHA. Cela signifie que le fournisseur reconnaît exclusivement le protocole TLS en tant que client et en tant que serveur (le cas échéant). Il utilise uniquement l'algorithme de chiffrement Triple DES (Data Encryption Standard) pour le cryptage du trafic TLS, uniquement l'algorithme de clé publique RSA (Rivest-Shamir-Adleman) pour l'échange de clés et l'authentification TLS et uniquement l'algorithme de hachage SHA-1 (Secure Hash Algorithm version 1) pour les besoins en hachage TLS.

Si ce paramètre est activé, le service EFS (Encrypting File System) prend uniquement en charge l'algorithme de chiffrement Triple DES pour chiffrer des données de fichier. Par défaut, EFS dans Windows Server 2003 est configuré pour utiliser la norme AES (Advanced Encryption Standard) avec une clé de 256 bits. Dans Windows XP, il utilise DESX.

Le paramètre Cryptographie système : Utilisez des algorithmes compatibles FIPS pour le cryptage, le hachageet la signature admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Vous pouvez activer ce paramètre de stratégie pour garantir que l'ordinateur utilisera les algorithmes les plus puissants disponibles pour le chiffrement, le hachage et la signature numériques L'utilisation de ces algorithmes réduira les risques d’intervention de la part d'un utilisateur non autorisé en vue de compromettre des données chiffrées ou signées numériquement.

Contre-mesures

Configurez le paramètre Cryptographie système : Utilisez des algorithmes compatibles FIPS pour le chiffrement, le hachageet la signature sur Activé.

Impact potentiel

Les ordinateurs clients dont ce paramètre de stratégie est activé seront incapables de communiquer avec les serveurs qui ne prennent pas en charge ces algorithmes par le biais de protocoles chiffrés ou signés numériquement. Les clients du réseau qui ne prennent pas en charge ces algorithmes ne pourront pas utiliser les serveurs qui s’en servent pour les communications réseau. Par exemple, de nombreux serveurs Web Apache ne sont pas configurés pour prendre en charge le protocole TLS. Si vous activez ce paramètre, vous devrez également configurer Internet Explorer pour lui faire utiliser TLS. Ce paramètre de stratégie affecte également le niveau de chiffrement utilisé pour le protocole RDP (Remote Desktop Protocol). L'outil de Connexion Bureau à distance utilise le protocole RDP pour communiquer avec les serveurs qui exécutent des services Terminal Server et les ordinateurs clients configurés pour le contrôle à distance. Les connexions RDP échoueront si les deux ordinateurs ne sont pas configurés pour utiliser les mêmes algorithmes de chiffrement.

Pour activer Internet Explorer de façon à lui faire utiliser TLS

Dans le menu Outils de Internet Explorer, ouvrez la boîte de dialogue Options Internet.
Cliquez sur l'onglet Avancé.
Activez la case à cocher TLS 1.0.

Une autre solution consiste à passer par la stratégie de groupe ou encore à utiliser le kit IEAK (Internet Explorer Administrators Kit).

Objets système : Propriétaire par défaut pour les objets créés par les membres du groupe Administrateurs

Ce paramètre de stratégie détermine si le groupe Administrateurs ou si un créateur d'objet est le propriétaire par défaut des objets système qui sont créés.

Le paramètre Objets système : Propriétaire par défaut pour les objets créés par les membres du groupe Administrateurs admet les valeurs suivantes :

Groupe Administrateurs
Créateur d'objet
Non défini

Vulnérabilité

Si vous configurez ce paramètre de stratégie sur groupe Administrateurs,il sera impossible d'imputer la création de nouveaux objets système à des individus.

Contre-mesures

Configurez le paramètre Objets système : Propriétaire par défaut pour les objets créés par les membres du groupe Administrateurs sur Créateur d’objet.

Impact potentiel

Lorsque des objets système sont créés, leur appartenance indique quel compte les a créés de façon plus précise que le groupe Administrateurs plus générique. Cependant, avec ce paramètre de stratégie, les objets seront orphelins à la suppression des comptes utilisateur. Par exemple, lorsqu'un membre quitte le groupe informatique, les objets qu'il a créés n'importe où dans le domaine n'appartiennent à personne. Cette situation peut devenir un fardeau administratif, dans la mesure où les administrateurs devront prendre manuellement possession des objets orphelins pour mettre à jour leurs autorisations. Cette charge peut être réduite si vous pouvez garantir que Contrôle total sera toujours attribué aux nouveaux objets d'un groupe de domaine, tel que Admins du domaine.

Objets système : Les différences entre majuscules et minuscules ne doivent pas être prises en compte pour les sous-systèmes autres que Windows

Ce paramètre de stratégie détermine si le non-respect de la casse est activé pour tous les sous-systèmes. Le sous-système Microsoft Win32® ne fait pas la distinction entre les majuscules et les minuscules. Toutefois, le noyau prend en charge le respect des majuscules/minuscules pour les autres sous-systèmes, comme POSIX (Portable Operating System Interface for UNIX). Si vous activez ce paramètre, le non-respect de la casse est mis en vigueur pour tous les objets d'annuaire, les liens symboliques, les objets IO, ainsi que les objets fichier. Si vous désactivez ce paramètre, le sous-système Win32 ne peut pas effectuer la distinction entre les majuscules et minuscules.

Le paramètre Objets système : Les différences entre majuscules et minuscules ne doivent pas être prises en compte pour les sous-systèmes autres que Windows admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Étant donné que Windows ne fait pas la distinction majuscules/minuscules, mais que le sous-système POSIX la prend en charge, si ce paramètre de stratégie n'est pas activé, un utilisateur de ce sous-système pourrait créer un fichier portant le même nom qu'un autre fichier, mais en mélangeant les majuscules et les minuscules. Une telle situation risque de perturber les utilisateurs lorsqu'ils essaieront d'accéder à ces fichiers à partir d'outils Win32 normaux, car un seul de ces fichiers sera disponible.

Contre-mesures

Configurez le paramètre Objets système : Les différences entre majuscules et minuscules ne doivent pas être prises en compte pour les sous-systèmes autres que Windows sur Activé.

Impact potentiel

Tous les sous-systèmes seront forcés de ne pas respecter la distinction entre les majuscules et les minuscules, Cette configuration peut perturber les utilisateurs qui ont l'habitude de systèmes d'exploitation UNIX faisant la distinction entre les majuscules et les minuscules.

Objets système : Renforcer les autorisations par défaut des objets système internes (comme les liens de symboles)

Ce paramètre de stratégie détermine la force de la DACL par défaut pour les objets. Windows conserve une liste globale des ressources informatiques partagées (comme les noms de périphérique MS-DOS, les mutex et les sémaphores) pour que les objets puissent être localisés et partagés par les processus.

Le paramètre Objets système : Renforcer les autorisations par défaut des objets système internes (comme les liens de symboles) admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Ce paramètre détermine la force de la DACL par défaut pour les objets. Windows Server 2003 conserve une liste globale des ressources informatiques partagées pour que les objets puissent être localisés et partagés par les processus. Chaque type d'objet est créé avec une liste DACL par défaut qui spécifie l'identité des personnes susceptibles d'accéder aux objets et leurs droits. Si vous activez ce paramètre, la DACL par défaut est renforcée, car les utilisateurs qui ne sont pas administrateurs pourront lire les objets partagés, mais ne pourront pas modifier ceux qu'ils n'ont pas créés

Contre-mesures

Configurez le paramètre Objets système : Renforcer les autorisations par défaut des objets système globaux (comme, les liens de symboles) sur Activé.

Impact potentiel

Aucune. Il s'agit de la configuration par défaut.

Paramètres système : Sous-systèmes facultatifs

Ce paramètre de stratégie détermine les sous-systèmes qui prennent en charge vos applications. Vous pouvez utiliser ce paramètre de sécurité pour indiquer autant de sous-systèmes que l'exige votre environnement.

Le paramètre Paramètres système : Sous-systèmes facultatifs admet les valeurs suivantes :

Une liste de sous-systèmes définie par l'utilisateur
Non défini

Vulnérabilité

Le sous-système POSIX est un standard de l'IEEE (Institute of Electrical and Electronic Engineers) qui définit un ensemble de services du système d'exploitation. Il est requis si le serveur prend en charge des applications utilisant ce sous-système.

Le sous-système POSIX introduit un risque de sécurité lié aux processus pouvant potentiellement persister d'une connexion à l'autre. Si un utilisateur démarre un processus, puis se déconnecte, il est possible que l'utilisateur suivant qui se connecte à l'ordinateur puisse avoir accès au processus de l'utilisateur précédent. Ceci est dangereux, parce que toutes les actions du deuxième utilisateur avec ce processus seront exécutées avec les privilèges du premier utilisateur.

Contre-mesures

Configurez le paramètre Paramètres système : Sous-systèmes facultatifs sur une valeur nulle. La valeur par défaut est POSIX.

Impact potentiel

Les applications reposant sur le sous-système POSIX ne fonctionneront plus. Par exemple, Microsoft Services for Unix (SFU) installe une version actualisée du sous-système POSIX requis, vous devez alors reconfigurer ce paramètre dans une stratégie de groupe pour tous les serveurs utilisant SFU.

Paramètres systèmes : Appliquez les règles de certificat des exécutables Windows pour les stratégies de restriction logicielle

Ce paramètre de stratégie détermine si des certificats numériques sont traités lorsque des stratégies de restriction logicielle sont activées et qu'un utilisateur ou un processus tente d'exécuter un logiciel à l'aide de l'extension de nom de fichier .exe. Ce paramètre de sécurité active ou désactive les règles de certificat (un type de règle de stratégies de restriction logicielle). Grâce aux stratégies de restriction, vous pouvez créer une règle de certificat qui autorise ou non l'exécution de logiciels signés par la technologie Microsoft Authenticode® en fonction du certificat numérique qui leur est associé. Pour que les règles de certificat s'exécutent dans les stratégies de restriction logicielle, vous devez activer ce paramètre de sécurité.

Le paramètre Paramètres systèmes : Appliquez les règles de certificat des exécutables Windows pour les stratégies de restriction logicielle admet les valeurs suivantes :

Activé
Désactivé
Non défini

Vulnérabilité

Les stratégies de restriction logicielle contribuent à protéger les utilisateurs et les ordinateurs, car elles empêchent l'exécution de code non autorisé, comme les virus et les chevaux de Troie.

Contre-mesures

Configurez le paramètre Paramètres systèmes : Appliquez les règles de certificat des exécutables Windows pour les stratégies de restriction logicielle sur Activé.

Impact potentiel

Si vous activez les règles de certificat, les stratégies de restriction logicielle vérifient la validité du certificat et de la signature des logiciels dans une liste de révocation de certificats. Ce processus de vérification peut avoir une incidence négative sur les performances au démarrage des programmes signés. Pour désactiver cette fonction, vous pouvez éditer les stratégies de restriction logicielle dans l'objet de stratégie de groupe voulu. Dans la boîte de dialogue Propriétés des Éditeurs approuvés, désactivez les cases à cocher Éditeur et Horodateur.

Informations complémentaires

Les liens suivants fournissent des informations supplémentaires sur les options de sécurité dans Windows Server 2003 et Windows XP.

Pour plus d'informations sur les restrictions d'accès machine COM par défaut de Windows XP, reportez-vous au guide « Managing Windows XP Service Pack 2 Features Using Group Policy: Security-Related Policy Settings » disponible à l'adresse https://technet.microsoft.com/fr-fr/library/bb457148.aspx.
Pour toute information concernant les restrictions d'accès COM par défaut dans Windows Server 2003 avec SP1, reportez-vous à la section « DCOM Security Enhancements » (Améliorations de sécurité DCOM) du guide « Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1 » à l'adresse technet2.microsoft.com/windowsserver/fr/library/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f1036.mspx?mfr=true.
Pour plus d'informations sur le mode d'activation de NTLMv2, reportez-vous à l'article de la Base de Connaissances Microsoft « Comment faire pour activer l'authentification NTLM version 2 » à l'adresse https://support.microsoft.com/kb/239869/fr.
Pour plus d'informations sur la garantie que les paramètres de niveau d'authentification LAN Manager plus sécurisés fonctionnent sur les réseaux combinant des systèmes Windows 2000 et Windows NT® 4.0, voir l'article de la Base de Connaissances Microsoft « Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain » à l'adresse https://support.microsoft.com/kb/305379/fr.
Pour plus d'informations sur les niveaux de compatibilité LAN Manager, voir l'article de la Base de connaissances Microsoft « Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments » à l'adresse https://support.microsoft.com/kb/823659/fr.
Pour plus d'informations sur l'authentification de NTLMv2, voir l'article de la Base de Connaissances Microsoft « How to Enable NTLM 2 Authentication » à https://support.microsoft.com/kb/239869/fr.
Pour plus d'informations sur la manière de restaurer les paramètres de sécurité par défaut localement, voir l'article de la Base de Connaissances Microsoft « How to Reset Security Settings Back to the Defaults » à l'adresse https://support.microsoft.com/kb/313222/fr.
Pour plus d'informations sur la manière de restaurer les paramètres de sécurité par défaut dans les objets de stratégie de groupe intégrés, voir l'article de la Base de Connaissances Microsoft « How to Reset User Rights in the Default Domain Group Policy in Windows Server 2003 » à l'adresse https://support.microsoft.com/kb/324800/fr.

Téléchargement

Obtenir le Guide des menaces et des contre-mesures

Notifications de mise à jour

Inscrivez-vous pour en savoir plus sur les mises à jour et les nouvelles publications

Commentaires

Envoyez-nous vos commentaires ou vos suggestions