Chapitre 5 : Stratégie de base du contrôleur de domaine
Dernière mise à jour le 27 décembre 2005
Sur cette page
Présentation
Paramètres de stratégie d’audit
Paramètres d'attribution des droits de l'utilisateur
Options de sécurité
Paramètres du journal des événements
Groupes restreints
Paramètres de sécurité supplémentaires
Création de la stratégie recourant à l'Assistant Configuration de la sécurité (SCW)
Résumé
Présentation
Le rôle du serveur de contrôleur de domaine est l’un des rôles les plus importants à sécuriser dans n’importe quel environnement d’ordinateurs fonctionnant avec Microsoft® Windows Server™ 2003 avec le Service Pack 1 (SP1) et le service d'annuaire Active Directory®. Toute atteinte à l’intégrité d’un contrôleur de domaine ou la perte de ce dernier dans ce type d'environnement pourrait avoir des conséquences graves pour les ordinateurs clients, serveurs et applications s’appuyant sur les contrôleurs de domaine pour l’authentification, la stratégie de groupe et un annuaire LDAP (Lightweight Directory Access Protocol) central.
En raison de leur importance, les contrôleurs de domaine doivent toujours être stockés dans des emplacements physiques sécurisés et accessibles uniquement au personnel administratif qualifié. Lorsque les contrôleurs de domaine doivent être stockés dans des emplacements moins sûrs, dans une filiale par exemple, plusieurs paramètres de sécurité peuvent être réglés pour limiter les dommages éventuels résultant de menaces physiques.
Stratégie de base du contrôleur de domaine
À l’inverse des autres stratégies de rôle de serveur décrites en détails plus loin dans ce guide, la stratégie de groupe du rôle de serveur Contrôleurs de domaine est une stratégie de base, tout comme la stratégie de base du serveur membre (MSBP, Member Server Baseline Policy) définie dans le chapitre 4, « Stratégie de base des serveurs membres ». La stratégie de base des contrôleurs de domaine (DCBP, Domain Controllers Baseline Policy) est liée à l’unité d’organisation (OU) des contrôleurs de domaine et a priorité sur la stratégie des contrôleurs de domaine par défaut. Les paramètres inclus dans la stratégie DCBP viennent renforcer la sécurité globale de l'ensemble des contrôleurs de domaine d'un environnement donné.
La majeure partie de la stratégie DCBP est copiée à partir de la stratégie MSBP. Lisez attentivement le chapitre 4, « Stratégie de base des serveurs membres » afin de comprendre parfaitement les nombreux paramètres communs aux deux stratégies. Seuls les paramètres DCBP qui diffèrent de ceux de la stratégie MSBP sont décrits dans ce chapitre.
Les modèles de contrôleur de domaine sont uniquement destinés à répondre aux besoins en matière de sécurité des trois environnements définis dans ce guide. Le tableau suivant regroupe les fichiers .inf du contrôleur de domaine qui sont inclus avec ce guide pour les environnements Client hérité (LC), Client Entreprise (EC) et Sécurité spécialisée – Fonctionnalité limitée (SSLF). Par exemple, le fichier EC-Domain Controller.inf constitue le modèle de sécurité de l’environnement Client Entreprise.
Tableau 5.1 Modèles de sécurité de la stratégie de base des contrôleurs de domaine
| LC-Domain Controller.inf |
EC-Domain Controller.inf |
SSLF-Domain Controller.inf |
**Remarque** : Le fonctionnement des domaines risque d'être gravement compromis si un objet de stratégie de groupe (GPO) configuré de façon inexacte est lié à l'UO des contrôleurs de domaine. Soyez prudents lorsque vous importez ces modèles de sécurité et assurez-vous que tous les paramètres de stratégie importés sont corrects avant de lier un objet GPO à l'UO des contrôleurs de domaine.
[](#mainsection)[Haut de page](#mainsection)
### Paramètres de stratégie d’audit
Les paramètres de stratégie d’audit pour les contrôleurs de domaine correspondent à ceux qui sont spécifiés par la stratégie MSBP. Pour plus d'informations, consultez le chapitre 4, « Stratégie de base des serveurs membres ». Les paramètres DCBP permettent de s'assurer que toutes les informations d'audit de sécurité pertinentes figurent sur l'ensemble des contrôleurs de domaine.
**Tableau 5.2 Paramètres de stratégie d'audit recommandés**
| Auditer l'accès au service d'annuaire |
Pas d’audit |
Pas d’audit |
Échec |
#### Auditer l'accès au service d'annuaire
Ce paramètre de stratégie détermine si l'accès utilisateur à un objet Active Directory doit faire l'objet d'un audit lorsqu'il dispose de sa propre liste de contrôle d'accès système (SACL). Si vous activez le paramètre **Auditer l'accès au service d'annuaire**, vous pouvez faire porter l'audit sur les réussites, les échecs ou le désactiver pour ce type événement. Les audits des succès génèrent une entrée d'audit à chaque fois qu'un utilisateur réussit à accéder à un objet Active Directory pour lequel une liste SACL est définie. Les audits des échecs génèrent une entrée d'audit à chaque fois qu'un utilisateur échoue dans sa tentative d'accès à un objet Active Directory pour lequel une liste SACL est définie.
Si vous activez le paramètre **Auditer l'accès au service d'annuaire** dans la stratégie DCBP et configurez des listes SACL sur les objets d'annuaire, le nombre d'entrées dans les journaux de sécurité des contrôleurs de domaine risque d'augmenter de façon exponentielle. Vous devez activer ce paramètre uniquement si vous projetez d'utiliser les informations ainsi créées.
Le paramètre **Auditer l'accès au service d'annuaire** est configuré sur **Pas d’audit** dans les environnements LC et EC. Il est configuré pour enregistrer les événements **Défaillance** dans l'environnement SSLF.
Le tableau suivant regroupe les événements de sécurité importants qui sont enregistrés par le paramètre **Auditer l'accès au service d'annuaire** dans le journal de sécurité.
**Tableau 5.3 Événements d'accès au service d'annuaire**
| DI |
Description |
| 566 |
Une opération d'objet générique s'est produite. |
[](#mainsection)[Haut de page](#mainsection)
### Paramètres d'attribution des droits de l'utilisateur
La DCBP spécifie un certain nombre d’attributions des droits de l’utilisateur pour les contrôleurs de domaine. En complément de la configuration par défaut, plusieurs paramètres de droits d'utilisateur ont été modifiés pour renforcer la sécurité des contrôleurs de domaine dans les trois environnements définis dans ce guide.
Cette section fournit des informations détaillées sur les droits utilisateur recommandés pour la DCBP, qui diffèrent de ceux de la MSBP. Pour un résumé des paramètres recommandés dans cette section, consultez le classeur Microsoft Excel® « Windows Server 2003 Security Guide Settings » (Paramètres du guide de sécurité de Windows Server 2003) qui est inclus avec la version téléchargeable de ce guide.
Le tableau suivant résume les paramètres d'attribution de droits utilisateur recommandés pour la stratégie DCBP. Les informations supplémentaires relatives aux différents paramètres sont fournies dans les sections qui suivent le tableau.
**Tableau 5.4 Paramètres d'attribution de droits utilisateur recommandés**
| Accéder à cet ordinateur à partir du réseau |
Non défini |
Non défini |
Administrateurs, Utilisateurs authentifiés, ENTERPRISE DOMAIN CONTROLLERS |
| Ajouter des stations de travail au domaine |
Non défini |
Non défini |
Administrateurs |
| Permettre l’ouverture d’une session locale |
Administrateurs, opérateurs de serveur, opérateurs de sauvegarde |
Administrateurs, opérateurs de serveur, opérateurs de sauvegarde |
Administrateurs |
| Autoriser l'ouverture de session par les services Terminal Server |
Administrateurs |
Administrateurs |
Administrateurs |
| Modifier l'heure du système |
Administrateurs |
Administrateurs |
Administrateurs |
| Activation de l'approbation des comptes ordinateur et utilisateur pour la délégation |
Non défini |
Non défini |
Administrateurs |
| Télécharger les pilotes du périphérique |
Administrateurs |
Administrateurs |
Administrateurs |
| Restaurer des fichiers et des répertoires |
Administrateurs |
Administrateurs |
Administrateurs |
| Arrêter le système |
Administrateurs |
Administrateurs |
Administrateurs |
#### Accéder à cet ordinateur à partir du réseau
Ce paramètre de stratégie détermine les utilisateurs et les groupes qui sont autorisés à se connecter au contrôleur de domaine sur le réseau. Il est requis par plusieurs opérations de réseau, ce qui inclut la réplication d'Active Directory entre les contrôleurs de domaine, les requêtes d'authentification aux contrôleurs de domaine envoyées par des utilisateurs et des ordinateurs et pour l'accès aux dossiers et aux imprimantes partagées.
Bien que les autorisations qui sont assignées au groupe de sécurité **Tous les utilisateurs** ne permettent plus d'accéder aux utilisateurs anonymes dans Windows Server 2003 avec SP1, les groupes d'invité et les comptes peuvent toujours bénéficier d'un accès par l'intermédiaire du groupe de sécurité **Tous les utilisateurs**.
Par conséquent, le groupe de sécurité **Tous les utilisateurs** n'est pas inclus dans le droit utilisateur **Accéder à cet ordinateur à partir du réseau** du DCBP de l'environnement SSLF. Le retrait de ce groupe fournit une garantie supplémentaire contre les attaques qui ciblent l'accès invité du domaine. Ce paramètre de stratégie est configuré sur **Non défini** pour les environnements LC et EC.
#### Ajouter des stations de travail au domaine
Ces paramètres de stratégie désignent les utilisateurs qui peuvent ajouter des stations de travail à un domaine spécifique. Pour que cette stratégie puisse prendre effet, elle doit être attribuée à l'utilisateur en tant qu'élément de la stratégie par défaut des contrôleurs de domaine pour le domaine. Tout utilisateur disposant de ce droit peut ajouter jusqu'à 10 stations de travail au domaine. Les utilisateurs qui bénéficient d'une autorisation de type **Créer objets ordinateur** pour une UO ou le conteneur Ordinateurs dans Active Directory peuvent ajouter un nombre illimité d'ordinateurs au domaine, qu'ils disposent du droit **Ajouter des stations de travail au domaine** ou non.
Par défaut, tous les utilisateurs du groupe **Utilisateurs identifiés** ont la possibilité d'ajouter jusqu'à 10 comptes ordinateur dans un domaine Active Directory. Ces nouveaux comptes ordinateur sont créés dans le conteneur Ordinateurs.
Dans les réseaux Windows, le terme *entité de sécurité* désigne un utilisateur, un groupe ou un ordinateur qui se voit automatiquement attribuer un identificateur de sécurité pour contrôler l'accès aux ressources. Dans un domaine Active Directory, chaque compte d'ordinateur est une entité de sécurité complète, disposant de la capacité d'authentifier et d'accéder aux ressources du domaine. Cependant, certaines organisations préfèrent limiter le nombre d'ordinateurs dans un environnement Active Directory de manière à pouvoir assurer leur suivi, les développer et les gérer de manière cohérente. Le fait d'autoriser les utilisateurs à ajouter des ordinateurs au domaine entrave les tâches de suivi et de gestion. En outre, les utilisateurs pourraient exécuter des activités qui sont plus difficiles à suivre du fait de la multiplication des ordinateurs de domaine non autorisés.
Par conséquent, le droit utilisateur **Ajouter des stations de travail au domaine** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP pour l'environnement SSLF. Ce paramètre de stratégie est configuré sur **Non défini** pour les environnements LC et EC.
#### Permettre l’ouverture d’une session locale
Ce paramètre de stratégie désigne les utilisateurs qui peuvent lancer des sessions interactives sur le contrôleur de domaine. Les utilisateurs ne disposant pas de ce droit peuvent quand même démarrer une session interactive à distance sur le contrôleur de domaine s’ils disposent du droit **Autoriser l'ouverture de session par les services Terminal Server**.
Vous devez limiter le nombre de comptes qui peuvent ouvrir une session sur les consoles de contrôleur de domaine pour empêcher l'accès non autorisé aux systèmes de fichiers du contrôleur de domaine et aux services système. Un utilisateur qui pourrait se connecter à la console d’un contrôleur de domaine pourrait de manière mal intentionnée exploiter l'ordinateur et éventuellement compromettre la sécurité d’un domaine ou d’une forêt tout entiers.
Par défaut, les groupes **Opérateurs de compte**, **Opérateurs de sauvegarde**, **Opérateurs d'impression** et **Opérateurs de serveur** se voient attribuer le droit utilisateur **Permettre l'ouverture d'une session locale** directement sur les contrôleurs de domaine. Les utilisateurs appartenant à ces groupes ne doivent pas avoir à ouvrir une session sur un contrôleur de domaine pour exécuter leurs tâches de gestion et doivent pouvoir exécuter leurs tâches sur d'autres postes de travail. Seuls les utilisateurs du groupe **Administrateurs** doivent réaliser les tâches de maintenance sur les contrôleurs de domaine.
Si vous attribuez le droit utilisateur **Permettre l'ouverture d'une session locale** uniquement au groupe **Administrateurs**, l'accès physique et interactif au contrôleur de domaine est limité aux utilisateurs en qui vous avez toute confiance, ce qui accroît la sécurité. Par conséquent, le droit utilisateur **Permettre l'ouverture d'une session locale** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP de l'environnement SSLF. Ces paramètres de stratégie sont configurés pour inclure les groupes **Opérateurs de serveur** et **Opérateurs de sauvegarde** pour les environnements LC et EC.
#### Autoriser l'ouverture de session par les services Terminal Server
Ces paramètres de stratégie spécifient les utilisateurs qui peuvent ouvrir une session sur le contrôleur de domaine à l'aide d'une connexion Bureau à distance.
Vous devez limiter le nombre de comptes qui peuvent ouvrir une session sur les consoles de contrôleur de domaine via le service système Terminal Server pour prévenir l'accès non autorisé aux systèmes de fichiers du contrôleur de domaine et aux services système. Un utilisateur qui pourrait se connecter à la console d’un contrôleur de domaine via les services Terminal Server pourrait exploiter le système, voire compromettre la sécurité de tout un domaine ou de toute une forêt.
Si vous attribuez le droit utilisateur **Autoriser l'ouverture de session par les services Terminal Server** uniquement au groupe **Administrateurs**, l'accès interactif au contrôleur de domaine est limité aux utilisateurs en qui vous avez toute confiance, ce qui accroît la sécurité. Par conséquent, le droit d'utilisateur **Autoriser l'ouverture de session par les services Terminal Server** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP des trois environnements définis dans ce guide. Bien que l'ouverture de session sur un contrôleur de domaine par les services Terminal Server nécessite l'accès administratif par défaut, la configuration de ces paramètres de stratégie permet de se protéger contre les actions involontaires ou malveillantes qui pourraient compromettre le réseau.
Par mesure de sécurité supplémentaire, la stratégie DCBP refuse le droit **Autoriser l'ouverture de session par les services Terminal Server** au compte administrateur par défaut. Cette configuration protège les contrôleurs de domaine contre les tentatives d'accès à distance des utilisateurs malveillants à l'aide du compte administrateur par défaut. Pour plus de détails sur ce paramètre de stratégie, consultez le chapitre 4, « Stratégie de base des serveurs membres ».
#### Modifier l'heure du système
Ce paramètre de stratégie désigne les utilisateurs qui peuvent changer l'heure de l'horloge interne d'un ordinateur. Cependant, il n'est pas nécessaire de changer le fuseau horaire ou toute autre caractéristique d’affichage de l’heure système.
La synchronisation de l’heure système est essentielle au bon fonctionnement d’Active Directory. Pour que le processus de création de ticket d’authentification et de réplication d’Active Directory utilisé par le protocole d’authentification Kerberos version 5 fonctionne correctement, l’heure doit être synchronisée à tous les niveaux de l'environnement.
Tout contrôleur de domaine dont l'heure système ne serait pas synchronisée avec les autres contrôleurs de domaine de l’environnement pourrait interférer avec le fonctionnement des services de domaine. Lorsque seuls les administrateurs sont autorisés à modifier l'heure système, les risques de configuration incorrecte de l'heure système sur un contrôleur de domaine sont considérablement réduits.
Par défaut, le groupe **Opérateurs de serveur** est autorisé à modifier l'heure système sur les contrôleurs de domaine. En raison des problèmes qui pourraient être liés au réglage incorrect d'une horloge de contrôleur de domaine par les membres de ce groupe, le droit d'utilisateur **Modifier l'heure du système** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP pour les trois environnements qui sont définis dans ce guide.
Pour plus d'informations sur le service de temps (Time Service) de Microsoft Windows®, consultez la page [Windows Time Service Technical Reference](http://technet2.microsoft.com/windowsserver/en/library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx?mfr=true) à l'adresse http://technet2.microsoft.com/windowsserver/en/library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx?mfr=true.
#### Activation de l'approbation des comptes ordinateur et utilisateur pour la délégation
Ce paramètre de stratégie désigne les utilisateurs qui peuvent modifier le paramètre **Approuvé pour la délégation** d'un objet utilisateur ou ordinateur d'Active Directory. La délégation de l’authentification est une fonctionnalité utilisée par les applications client/serveur à plusieurs niveaux. Elle autorise un service frontal, tel qu'une application, à utiliser les informations d'authentification d'un client pour s’authentifier auprès d’un service principal, tel qu'une base de données. Pour que cette authentification soit possible, le client et le serveur doivent être exécutés dans le cadre de comptes approuvés pour la délégation.
Tout abus de ce droit d'utilisateur pourrait permettre à des utilisateurs non autorisés d'usurper les droits d'autres utilisateurs sur le réseau. Un utilisateur malveillant pourrait exploiter ce droit d'utilisateur pour accéder aux ressources réseau en se faisant passer pour un utilisateur différent, ce qui rendrait l’identification des événements après un incident de sécurité difficile à établir.
Le droit d'utilisateur **Activation de l'approbation des comptes ordinateur et utilisateur pour la délégation** est uniquement attribué au groupe **Administrateurs** sur les contrôleurs de domaine et de groupe de l'environnement SSLF. Ce paramètre de stratégie est configuré sur **Non défini** pour les environnements LC et EC.
**Remarque**: La stratégie par défaut des contrôleurs de domaine attribue ce droit au groupe **Administrateurs**. Toutefois, la stratégie DCBP l'applique dans l’environnement SSLF, car il repose initialement sur la stratégie MSBP. La stratégie MSBP attribue une valeur nulle (null) à ce droit.
#### Télécharger les pilotes du périphérique
Ce paramètre de stratégie désigne les utilisateurs qui peuvent télécharger des pilotes de périphérique. Il est indispensable pour télécharger les pilotes de périphériques Plug-and-Play.
La gestion négligente de pilotes de périphérique sur les contrôleurs de domaine pourrait entraîner des bogues ou un code malveillant et avoir ainsi un impact négatif sur l'exploitation des contrôleurs de domaine. Si les comptes qui peuvent télécharger des pilotes de périphérique sont limités dans la stratégie DCBP aux utilisateurs en qui vous avez toute confiance, vous protégez l'intégrité des contrôleurs de domaine contre les attaques utilisant les pilotes de périphérique comme vecteur.
Par défaut, le droit d'utilisateur **Télécharger les pilotes du périphérique** est attribué au groupe **Opérateurs d'impression**. Comme mentionné plus haut, la création de partages d'imprimante est déconseillée sur les contrôleurs de domaine. Par conséquent, les **Opérateurs d'impression** ne devraient pas avoir à télécharger de pilotes de périphérique. Ainsi, le droit d'utilisateur **Télécharger les pilotes du périphérique** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP pour les trois environnements qui sont définis dans ce guide.
#### Restaurer des fichiers et des répertoires
Ce paramètre de stratégie désigne les utilisateurs qui peuvent contourner les autorisations de fichier et de répertoire pendant le processus de restauration. Toute entité de sécurité valide peut être définie en tant que propriétaire d'un objet.
Tout compte pouvant restaurer des fichiers et des répertoires sur le système de fichiers d'un contrôleur de domaine peut facilement modifier des fichiers exécutables. Des utilisateurs malveillants pourraient exploiter l’accès offert par ce droit, non seulement pour rendre un contrôleur de domaine totalement inopérant, mais également pour compromettre la sécurité d’un domaine ou de toute une forêt.
Par défaut, le droit d'utilisateur **Restaurer des fichiers et des répertoires** est attribué aux groupes **Opérateurs de serveur** et **Opérateurs de sauvegarde**. Si vous supprimez ce droit utilisateur de ces groupes et le réservez au groupe **Administrateurs**, vous réduisez la probabilité d'endommagement du contrôleur de domaine du fait de modifications inappropriées du système de fichiers. Ainsi, le droit d'utilisateur **Restaurer des fichiers et des répertoires** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP pour les trois environnements qui sont définis dans ce guide.
#### Arrêter le système
Ce paramètre de stratégie désigne les utilisateurs qui peuvent arrêter l'ordinateur local.
Des utilisateurs malveillants qui auraient la possibilité d’arrêter des contrôleurs de domaine pourraient facilement lancer une attaque de déni de service (DoS) qui affecterait gravement tout le domaine ou toute la forêt. Un utilisateur malveillant pourrait exploiter ce droit d'utilisateur pour lancer une attaque d'élévation de privilèges sur un compte du contrôleur de domaine lors du redémarrage des services de ce dernier. En cas de réussite, une attaque de ce type sur un contrôleur de domaine porte atteinte à la sécurité de l’ensemble d’un domaine ou d’une forêt.
Par défaut, le droit d'utilisateur **Arrêter le système** est attribué aux groupes **Administrateurs**, **Opérateurs de serveur**, **Opérateurs d'impression** et **Opérateurs de sauvegarde**. Dans des environnements sécurisés, aucun de ces groupes, à l’exception du groupe **Administrateurs**, ne nécessite ce droit pour exécuter des tâches administratives. Par conséquent, le droit d'utilisateur **Arrêter le système** est attribué uniquement au groupe **Administrateurs** dans la stratégie DCBP des trois environnements définis dans ce guide.
[](#mainsection)[Haut de page](#mainsection)
### Options de sécurité
La plupart des paramètres relatifs aux options de sécurité pour les contrôleurs de domaine sont les mêmes que ceux qui sont indiqués pour la stratégie MSBP. Pour plus d'informations, consultez le chapitre 4, « Stratégie de base des serveurs membres ». Les différences entre les paramètres des stratégies MSBP et DCBP sont décrites dans les sections suivantes.
#### Paramètres du contrôleur de domaine
**Tableau 5.5 Options de sécurité : Recommandations relatives aux paramètres du contrôleur de domaine**
| permettre aux opérateurs du serveur de planifier des tâches |
Désactivé |
Désactivé |
Désactivé |
| conditions requises pour la signature de serveur LDAP |
Non défini |
Non défini |
Nécessite la signature |
| refuser les modifications de mot de passe du compte ordinateur |
Désactivé |
Désactivé |
Désactivé |
##### 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 membres du groupe **Opérateurs de serveur** sont autorisés à envoyer des tâches au moyen de la fonction de calendrier AT.
Le paramètre **Contrôleur de domaine : Permettre aux opérateurs du serveur de planifier des tâches** est configuré sur **Désactivé** dans la stratégie DCBP pour les trois environnements qui sont définis dans ce guide. L'impact de la configuration de ce paramètre de stratégie devrait être minimal dans la plupart des organisations. Les utilisateurs, y compris ceux du groupe **Opérateurs du serveur**, pourront toujours créer des travaux à l'aide de l'Assistant du Gestionnaire de tâches, mais ces travaux s'exécuteront dans le contexte du compte avec lequel l'utilisateur s'authentifie lors de la définition du travail.
**Remarque**: Il est possible de modifier le compte de service AT pour remplacer le compte SYSTEME LOCAL. Pour changer de compte, ouvrez Outils système, cliquez sur **Tâches planifiées**, puis sur le dossier **Accessoires**. Cliquez ensuite sur **Compte de service AT** dans le menu **Avancé**.
##### Contrôleur de domaine : Conditions requises pour la signature de serveur LDAP
Ce paramètre de stratégie détermine si le serveur LDAP nécessite une signature avant de négocier avec les clients LDAP. Le trafic réseau qui n'est ni signé ni chiffré est susceptible de faire l'objet d'agressions au cours desquelles un intrus capture des paquets entre le serveur et le client, et les modifie avant de les acheminer au client. Pour un serveur LDAP, un utilisateur malveillant pourrait pousser un client à prendre des décisions sur la base d'enregistrements erronés provenant du répertoire LDAP.
Si tous les contrôleurs de domaine exécutent Windows 2000 ou Windows Server 2003, configurez le paramètre **Contrôleur de domaine : Conditions requises pour la signature de serveur LDAP** sur **Nécessite la signature**. Sinon, conservez la valeur **Non défini** pour ce paramètre de stratégie, ce qui correspond à la configuration de la stratégie DCBP pour les environnements LC et EC. Ces paramètres de stratégie sont configurés sur **Nécessite la signature** dans la stratégie DCBP de l'environnement SSLF, car tous les ordinateurs de cet environnement exécutent Windows 2000 ou Windows Server 2003.
##### Contrôleur de domaine : Refuser les modifications de mot de passe du compte ordinateur
Ce paramètre de stratégie détermine si les contrôleurs de domaine doivent refuser les demandes des ordinateurs membres relatives aux changements de mot de passe des comptes ordinateur. Si vous activez ce paramètre de stratégie sur tous les contrôleurs de domaine d'un domaine, les mots de passe du compte de l'ordinateur des membres de domaine ne pourront pas être modifiés et seront plus vulnérables.
Par conséquent, le paramètre **Contrôleur de domaine : Refuser les modifications de mot de passe du compte ordinateur** est configuré sur **Désactivé** dans la stratégie DCBP des trois environnements qui sont définis dans ce guide.
#### Paramètres de sécurité réseau
**Tableau 5.6 Options de sécurité : Recommandations relatives aux paramètres de sécurité réseau**
| ne pas stocker de valeurs de hachage de niveau Lan Manager sur la prochaine modification de mot de passe |
Activé |
Activé |
Activé |
#### 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 la valeur de hachage de LAN Manager (LM) pour le nouveau mot de passe est enregistrée lorsque le mot de passe est modifié. Le hachage LAN Manager est relativement faible et sujet aux attaques, comparé à celui de Windows NT®, qui est plus fort d'un point de vue cryptographique.
Par conséquent, la stratégie DCBP active le paramètre **Sécurité réseau : Ne pas stocker de valeurs de hachage de niveau LAN Manager sur la prochaine modification de mot de passe** dans les trois environnements qui sont définis dans ce guide.
**Remarque** : Lorsque ce paramètre est activé, certains systèmes d'exploitation plus anciens et certaines applications d'autres éditeurs risquent d'échouer. Par exemple, Windows 95 et Windows 98 échouent si les extensions client Active Directory ne sont pas installées. D'autre part, tous les comptes devront modifier leur mot de passe si vous activez ce paramètre de stratégie.
[](#mainsection)[Haut de page](#mainsection)
### Paramètres du journal des événements
Les paramètres des journaux d’événements relatifs aux contrôleurs de domaine sont identiques à ceux qui sont indiqués dans la stratégie MSBP. Pour plus d'informations, consultez le chapitre 4, « Stratégie de base des serveurs membres ». Les paramètres de base de la stratégie DCBP permettent de s'assurer que toutes les informations d'audit de sécurité pertinentes figurent sur l'ensemble des contrôleurs de domaine.
[](#mainsection)[Haut de page](#mainsection)
### Groupes restreints
Comme décrit dans le chapitre précédent, le paramètre **Groupes restreints** permet de gérer les membres des groupes dans Windows Server 2003 avec SP1 via la stratégie de groupe Active Directory. Tout d'abord, identifiez les besoins de votre organisation pour déterminer les groupes à limiter. Pour les contrôleurs de domaine, les groupes **Opérateurs de serveur** et **Opérateurs de sauvegarde** sont limités aux trois environnements qui sont définis dans ce guide. L'accès des membres des groupes **Opérateurs de serveur** et **Opérateur de sauvegarde** est plus limité que celui du groupe **Administrateurs** tout en bénéficiant de fonctionnalités puissantes.
**Remarque :** Si votre organisation utilise l'un de ces groupes, contrôlez ensuite soigneusement leur adhésion et n'appliquez pas les instructions relatives au paramètre **Groupes restreints**. Si votre organisation ajoute des utilisateurs au groupe Utilisateurs de serveur, il peut être nécessaire de mettre en œuvre les autorisations facultatives du système de fichiers qui sont décrites dans la section « Sécurisation du système de fichiers » du chapitre précédent.
**Tableau 5.7 Recommandations relatives aux groupes limités**
| Opérateurs de sauvegarde |
Aucun membre |
Aucun membre |
Aucun membre |
| Opérateurs de serveur |
Aucun membre |
Aucun membre |
Aucun membre |
Le paramètre **Groupes restreints** peut être configuré dans Windows Server 2003 avec SP1 à l'emplacement suivant dans l'Éditeur d'objets Stratégie de groupe :
**Configuration ordinateur\\Paramètres Windows\\Paramètres de sécurité\\Groupes restreints\\**
Les administrateurs peuvent configurer des groupes restreints pour un objet Stratégie de groupe en ajoutant directement le groupe souhaité au nœud **Groupes restreints** de l'espace de noms des objets Stratégie de groupe.
Quand un groupe est limité, vous pouvez définir ses membres et tout autre groupe auquel il appartient. Si vous ne spécifiez pas ces membres, le groupe reste totalement limité. Seuls les modèles de sécurité permettent de limiter les groupes.
**Pour afficher ou modifier le paramètre Groupes restreints**
1. Ouvrez la console Gestion des modèles de sécurité.
**Remarque**: La console Gestion des modèles de sécurité n'est pas ajoutée au menu Outils d'administration par défaut. Pour l'ajouter, démarrez la console MMC (Microsoft Management Console) (mmc.exe) puis ajoutez le Complément des modèles de sécurité.
2. Double–cliquez sur le répertoire du fichier de configuration, puis sur le fichier de configuration.
3. Double–cliquez sur l'élément **Groupes restreints**.
4. Cliquez avec le bouton droit sur l'élément **Groupes restreints**.
5. Sélectionnez **Ajouter un groupe**.
6. Cliquez sur le bouton **Parcourir**, puis sur **Emplacements**. Choisissez les emplacements à parcourir, puis cliquez sur **OK**.
**Remarque**: Normalement, cette action place l'ordinateur local en tête de liste.
7. Tapez le nom du groupe dans la zone de texte **Entrez les noms des objets à sélectionner**, puis cliquez sur le bouton **Vérifier les noms**.
– ou –
Cliquez sur le bouton **Avancé**, puis sur le bouton **Rechercher maintenant** pour répertorier tous les groupes disponibles.
8. Sélectionnez les groupes que vous voulez restreindre, puis cliquez sur **OK**.
9. Cliquez sur **OK** pour fermer la boîte de dialogue **Ajouter des groupes**.
Dans ces instructions, tous les membres—utilisateurs et groupes—des groupes **Opérateurs de serveur** et **Opérateurs de sauvegarde** ont été supprimés pour leur imposer des restrictions totales dans les deux environnements. D'autre part, pour l'environnement SSLF, tous les membres ont été supprimés du groupe **Utilisateurs du Bureau à distance**. Microsoft recommande de restreindre les groupes intégrés que vous n'avez pas l'intention d'utiliser dans votre organisation.
**Remarque** : La configuration de groupes restreints qui est décrite dans cette section est très simple. Les versions de Windows XP avec SP1 et SP2 de même que Windows Server 2003 prennent en charge des configurations plus complexes. Pour plus d'informations, consultez l'article suivant dans la base de connaissances Microsoft « [Mises à jour du comportement de Groupes restreints (« Membre de ») des groupes locaux définis par l'utilisateur](http://support.microsoft.com/kb/810076/fr) » à http://support.microsoft.com/kb/810076/fr.
[](#mainsection)[Haut de page](#mainsection)
### Paramètres de sécurité supplémentaires
Cette section décrit les modifications manuelles qui doivent être apportées à la stratégie DCBP, ainsi que les paramètres et contre-mesures supplémentaires qui ne peuvent pas être mis en œuvre via la stratégie de groupe.
#### Ajout manuel de groupes de sécurité spécifiques à des attributions de droits de l’utilisateur
La plupart des attributions de droits utilisateur qui sont appliquées via la stratégie DCBP sont indiquées correctement dans les modèles de sécurité qui accompagnent ce guide. Cependant, il existe un petit nombre de comptes et de groupes de sécurité qu’il est impossible d’inclure dans les modèles, car leur identificateur de sécurité (SID) est propre à un domaine Windows Server 2003 spécifique. Les attributions des droits de l'utilisateur devant être configurées manuellement figurent dans le tableau suivant.
**Avertissement **: Le tableau ci-après présente des valeurs se rapportant au compte Administrateur intégré. Veillez à ne pas confondre ce compte avec le groupe de sécurité **Administrateurs** intégré. Si vous ajoutez le groupe de sécurité **Administrateurs** à l’un des droits utilisateur d’accès refusé ci-dessous, vous devrez vous connecter localement pour corriger l’erreur.
D'autre part, si vous avez renommé le compte administrateur intégré conformément aux recommandations du chapitre 4, « Stratégie de base des serveurs membres », vous devez sélectionner le compte administrateur qui vient d'être renommé lorsque vous l'ajoutez à l’un des droits utilisateur d’accès refusé.
**Tableau 5.8 Ajout manuel d’attributions de droits utilisateur**
| Interdire l’accès à cet ordinateur à partir du réseau |
Administrateur intégré ; Support_388945a0 ;
Invité ; tout compte de service hors système d'exploitation |
Administrateur intégré ; Support_388945a0 ;
Invité ; tout compte de service hors système d'exploitation |
Administrateur intégré ; Support_388945a0 ;
Invité ; tout compte de service hors système d'exploitation |
| Interdire l'ouverture de session en tant que tâche |
Support_388945a0 et Invité |
Support_388945a0 et Invité |
Support_388945a0 et Invité |
| Interdire l'ouverture de session par les services Terminal Server |
Compte Administrateur intégré ; tous les comptes de services hors système d'exploitation |
Compte Administrateur intégré ; tous les comptes de services hors système d'exploitation |
Compte Administrateur intégré ; tous les comptes de services hors système d'exploitation |
**Important** : L'expression « tous les comptes de services hors système d'exploitation » recouvre les comptes de service utilisés pour des applications spécifiques à l'échelle d'une entreprise, mais n'inclut PAS les comptes SYSTÈME LOCAL, SERVICE LOCAL ou SERVICE RÉSEAU (i.e. les comptes incorporés que le système d'exploitation utilise).
#### Services d'annuaire
Les contrôleurs de domaine exécutés sur Windows Server 2003 avec SP1 stockent les données d’annuaire et gèrent les interactions d’utilisateur et de domaine, y compris les processus d’ouverture de session utilisateur, l’authentification et les recherches dans l’annuaire.
##### Nouvelle localisation des données : Base de données d'Active Directory et fichiers journaux
Pour préserver l’intégrité et la fiabilité de l’annuaire, il est essentiel de sauvegarder la base de données Active Directory et ses fichiers journaux.
Le fait de déplacer les fichiers ntds.dit, edb.log et temp.edb de leur emplacement par défaut contribue à les protéger d’une attaque si un contrôleur de domaine est atteint. Le fait de déplacer les fichiers hors du volume système vers un disque physique séparé permet d'améliorer les performances du contrôleur de domaine.
Par conséquent, ce guide recommande de déplacer la base de données et les journaux Active Directory, pour les contrôleurs de domaine, sur un volume de disque agrégé par bandes ou agrégé par bandes/miroir qui ne contiennent pas le système d'exploitation. Ces fichiers doivent être déplacés pour les trois environnements qui sont définis dans ce guide.
##### Redimensionnement des fichiers journaux Active Directory
Une quantité suffisante d'informations doit être consignée pour contrôler et maintenir l'intégrité, la fiabilité et la disponibilité d'Active Directory. Vous devez disposer d'informations provenant de tous les contrôleurs de domaine de l'environnement.
Vous pouvez augmenter la taille maximale des fichiers journaux à cet effet. Ce supplément d'informations permet aux administrateurs de procéder à des audits significatifs en cas d'attaques.
Ce guide recommande d’augmenter la taille maximale des fichiers journaux du service d’annuaire et du service de réplication de fichiers de 512 Ko, par défaut, à 16 Mo sur les contrôleurs de domaine dans les trois environnements définis dans ce guide.
##### Utilisation de Syskey
Sur les contrôleurs de domaine, les informations de mot de passe sont stockées dans Active Directory. Les logiciels de décodage de mots de passe ciblent souvent la base de données du Gestionnaire des comptes de sécurité (SAM, Security Accounts Manager) ou les services d’annuaire pour accéder aux mots de passe des comptes utilisateur.
L’utilitaire Clé système (Syskey) fournit une ligne de défense supplémentaire contre les logiciels de décodage de mots de passe hors ligne. Syskey applique des techniques de chiffrement robustes pour obtenir les informations relatives au mot de passe de compte qui sont stockées dans le gestionnaire SAM du contrôleur de domaine.
**Tableau 5.9 Modes Syskey**
| Mode 1 : Mot de passe généré par le système, enregistre la clé de démarrage localement |
Sécurisation |
Utilise une clé aléatoire générée par le système en tant que clé système et stocke une version chiffrée de la clé sur l’ordinateur local. Cette option offre un chiffrement solide des informations de mot de passe dans le Registre et permet à l’utilisateur de redémarrer l’ordinateur sans que l’administrateur ait besoin de saisir un mot de passe ou d’insérer une disquette. |
| Mode 2 : Mot de passe généré par l'administrateur, mot de passe de démarrage |
Plus sûr |
Utilise une clé aléatoire générée par le système en tant que clé système et stocke une version chiffrée de la clé sur l’ordinateur local. La clé est en outre protégée par un mot de passe choisi par l’administrateur. Les utilisateurs sont invités à saisir le mot de passe de la clé système lorsque l’ordinateur se trouve dans la phase de démarrage initial. Le mot de passe de la clé système n’est stocké nulle part sur l’ordinateur. |
| Mode 3 : Mot de passe généré par le système, enregistre la clé de démarrage sur disquette |
Le plus sûr |
Utilise une clé aléatoire générée par l’ordinateur et la stocke sur une disquette. La disquette qui contient la clé système est obligatoire pour pouvoir démarrer l'ordinateur et doit être insérée suite à une invite lors de la phase de démarrage initial. La clé système n’est stockée nulle part sur l’ordinateur. |
Syskey est activé sur tous les serveurs Windows Server 2003 avec SP1 (clé masquée). Du point de vue de la sécurité, cette configuration semble raisonnable, de prime abord. Toutefois, Syskey en Mode 1 permet à une personne mal intentionnée de lire et de modifier le contenu de l’annuaire. Cela rendrait le contrôleur de domaine particulièrement vulnérable pour un utilisateur malveillant disposant d'un accès physique.
Il existe de nombreuses raisons de recommander Syskey en Mode 2 (mot de passe par console) ou en Mode 3 (stockage sur disquette du mot de passe Syskey) pour tout contrôleur de domaine exposé à des risques en termes de sécurité physique. Cependant, le fait d'avoir à redémarrer les contrôleurs de domaine tend à rendre les modes 2 et 3 de Syskey difficiles à prendre en charge. Pour bénéficier de la protection supplémentaire offerte par ces modes Syskey, les processus de fonctionnement appropriés doivent être mis en œuvre dans votre environnement afin de répondre aux besoins spécifiques relatifs à la disponibilité pour les contrôleurs de domaine.
La logistique découlant de la gestion du mot de passe ou de la disquette Syskey peut être assez complexe, particulièrement dans les filiales. Par exemple, il serait très onéreux de faire intervenir l'un des responsables de branche ou administrateurs locaux à 3 heures du matin pour entrer des mots de passe ou insérer une disquette afin d'activer l'accès utilisateur. Il serait par conséquent très difficile de remplir les objectifs des accords sur les niveaux de service (SLA, Service Level Agreements).
Une autre solution consiste à autoriser le personnel responsable des opérations informatiques centralisées à fournir le mot de passe Syskey à distance, ce qui requiert du matériel supplémentaire. Certains fournisseurs de matériel offrent des solutions enfichables qui permettent d’accéder à distance aux consoles de serveur.
Enfin, la perte de votre mot de passe ou disquette Syskey laisserait votre contrôleur de domaine dans un état où il ne pourrait pas être redémarré. Il n’existe aucune méthode vous permettant de récupérer un contrôleur de domaine en cas de perte du mot de passe ou de la disquette Syskey. Dans cette situation, le contrôleur de domaine doit être recréé.
Une fois les procédures de fonctionnement appropriées en place, Syskey peut fournir un niveau de sécurité supplémentaire qui permet de protéger les informations d’annuaire confidentielles qui se trouvent sur les contrôleurs de domaine. C'est pourquoi le Mode 2 ou le Mode 3 de Syskey est recommandé pour les contrôleurs de domaine dans les lieux sans sécurité de stockage physique importante. Cette configuration s'applique aux contrôleurs de domaine des trois environnements qui sont décrits dans ce guide.
**Pour créer ou mettre à jour une clé système, procédez comme suit :**
1. Cliquez sur **Démarrer** puis sur **Exécuter**, tapez **syskey**. Cliquez ensuite sur **OK**.
2. Cliquez sur **Cryptage activé**, puis sur **Mettre à jour**.
3. Cliquez sur l**’option souhaitée, puis sur** OK.
#### DNS intégré d’Active Directory
Microsoft recommande d'utiliser le DNS intégré d’Active Directory dans les trois environnements qui sont définis dans ce guide. Cette recommandation est en partie due au fait que l'intégration de zone d'Active Directory facilite la sécurisation de l'infrastructure DNS dans un environnement qui utilise le DNS intégré d’Active Directory, par opposition à ceux qui ne l'utilisent pas.
##### Protection des serveurs DNS
Il est essentiel de protéger les serveurs DNS dans tout environnement Active Directory. Les sections suivantes fournissent plusieurs recommandations et des explications sur la manière de sauvegarder des serveurs DNS.
Lorsqu’un serveur DNS fait l’objet d’une attaque, l’un des objectifs de l'utilisateur malveillant serait de contrôler les informations de DNS renvoyées en réponse aux requêtes des clients DNS. Si un utilisateur malveillant contrôle ces informations, les clients risquent d'être redirigés à leur insu vers des ordinateurs non autorisés. L’usurpation d’adresse IP et l’empoisonnement de mémoire cache sont des exemples de ce type d’attaque.
Dans le cas de l’usurpation d’IP, l’adresse IP d’un utilisateur non autorisé est communiquée à une transmission pour obtenir l’accès à un ordinateur ou un réseau. Lors d'une attaque de type « empoisonnement de mémoire cache », un hôte non autorisé place des informations falsifiées sur un autre hôte dans la mémoire cache d’un serveur DNS. Cette attaque redirige les clients vers des ordinateurs non autorisés.
Si les ordinateurs clients sont autorisés à communiquer avec les ordinateurs non autorisés, les ordinateurs non autorisés pourraient tenter d'accéder aux informations des ordinateurs clients.
Les attaques ne sont pas toutes ciblées sur l’usurpation de serveurs DNS. Certaines attaques de déni de service (DoS) peuvent altérer les enregistrements DNS dans des serveurs DNS légitimes afin de fournir des adresses non valides en réponse aux requêtes client. Si un serveur DNS renvoie des adresses non valides, les clients et serveurs ne peuvent plus localiser les ressources nécessaires à leur fonctionnement, telles que les contrôleurs de domaine, les serveurs Web ou les partages de fichiers.
Par conséquent, les routeurs qui sont utilisés dans les trois environnements définis dans ce guide sont configurés pour ignorer les paquets IP usurpés. Cela permet de s'assurer que les adresses IP des serveurs DNS ne sont pas usurpées par les autres ordinateurs.
##### Configuration des mises à jour dynamiques sécurisées
Le service **Client DNS** de Windows Server 2003 avec SP1 prend en charge les mises à jour de DNS dynamiques. Cela permet aux ordinateurs clients d'ajouter des enregistrements DNS directement dans la base de données. Si un serveur DNS dynamique est configuré pour accepter des mises à jour non sécurisées, un utilisateur malveillant pourrait transmettre des mises à jour malveillantes ou non autorisées à partir d'un ordinateur client prenant en charge le protocole DNS de mise à jour dynamique.
Au mieux, un utilisateur malveillant pourrait ajouter des entrées falsifiées dans la base de données DNS. Au pire, il pourrait écraser ou effacer des entrées de la base de données DNS. Cet personne malveillante pourrait accomplir l'une des actions suivantes :
- **Rediriger les clients vers des contrôleurs de domaine non autorisés**. Lorsqu’un client envoie une requête DNS recherchant l’adresse d’un contrôleur de domaine, tout serveur DNS compromis pourrait recevoir une instruction consistant à renvoyer l’adresse d’un serveur non autorisé. Puis, en conjonction avec d'autres attaques non liées à DNS, le client pourrait transmettre à son insu des informations sécurisées au serveur non autorisé.
- **Répondre aux requêtes DNS contenant des adresses incorrectes**. Les clients et les serveurs seraient alors incapables de se reconnaître mutuellement. Si les clients ne peuvent pas localiser les serveurs, ils ne peuvent alors pas accéder à l’annuaire. Lorsque les contrôleurs de domaine ne peuvent pas se reconnaître, la réplication d’annuaires s’arrête. Cela crée une condition d’erreur DoS susceptible d’affecter les utilisateurs sur l’ensemble d’une forêt.
- **Création d'une erreur DoS**. L'espace disque d’un serveur peut être épuisé par un fichier de zone démesuré, rempli d’enregistrements fictifs ou par un grand nombre d’entrées qui ralentissent la réplication.
L’utilisation de mises à jour DNS dynamiques et sécurisées garantit que les demandes d’enregistrement sont traitées uniquement si elles proviennent de clients valides dans une forêt Active Directory. Cette méthode limite considérablement la vulnérabilité d’un serveur DNS.
Par conséquent, les serveurs DNS d'Active Directory des trois environnements qui sont définis dans ce guide sont configurés pour accepter uniquement les mises à jour dynamiques sécurisées.
##### Restriction des transferts de zone aux systèmes autorisés
En raison du rôle important que jouent les zones dans le DNS, elles doivent être disponibles sur plusieurs des serveurs DNS du réseau afin d'offrir la disponibilité et la tolérance de panne nécessaires lors de la résolution de requêtes de nom. Lorsque des serveurs supplémentaires hébergent une zone, des transferts de zone sont requis pour répliquer et synchroniser toutes les copies de la zone utilisées sur chaque serveur configuré pour héberger la zone.
En outre, tout serveur DNS, qui ne limiterait pas les utilisateurs pouvant demander des transferts de zone, offrirait la possibilité de transférer l’ensemble de la zone DNS à quiconque en fait la demande. Ce transfert peut être accompli facilement avec des outils, tels que Nslookup.exe. Ces outils peuvent exposer l’ensemble de données DNS de tout un domaine, y compris des éléments tels que les hôtes qui servent de contrôleurs de domaine, de serveurs Web intégrés à l’annuaire ou de bases de données Microsoft SQL Server™.
Par conséquent, les serveurs DNS intégrés d’Active Directory dans les trois environnements définis dans ce guide sont configurés de sorte à autoriser les transferts de zone tout en restreignant le nombre d'ordinateurs pouvant émettre des demandes de transfert.
##### Redimensionnement du journal des événements et du journal du service DNS
La quantité d'informations consignées doit être conséquente de façon à autoriser un contrôle et une gestion efficaces du service DNS. Vous devez disposer d'informations provenant de tous les contrôleurs de domaine de l'environnement.
Vous pouvez augmenter la taille maximale du fichier journal de service DNS, ce qui permettra aux administrateurs de procéder à des audits significatifs en cas d'attaque.
Ce guide recommande de faire passer la taille maximale du fichier journal de service DNS à au moins 16 Mo sur les contrôleurs de domaine dans les trois environnements qui sont définis dans ce guide. Assurez-vous également que l'option **Remplacer les événements si nécessaire** du service DNS est sélectionnée pour optimiser le nombre d'entrées de journal conservées.
#### Sécurisation de comptes bien connus
Windows Server 2003 avec SP1 comprend un certain nombre de comptes d’utilisateurs intégrés qu’il est impossible de supprimer, mais qui peuvent être renommés. Parmi les comptes intégrés les plus connus de Windows Server 2003, citons les deux suivants : Invité et Administrateur.
Par défaut, le compte Invité est désactivé sur les serveurs membres et les contrôleurs de domaine. Il est déconseillé de modifier cette configuration. De nombreuses variations de code malveillant font appel au compte Administrateur intégré dans une tentative initiale de compromettre un serveur. Vous devez donc renommer le compte Administrateur intégré et modifier sa description pour protéger les serveurs distants contre les attaques qui portent sur ce compte facile à identifier.
L’impact de ce changement de configuration s’est réduit au cours des dernières années avec l’apparition d’outils d’attaque qui ciblent l’identificateur de sécurité (SID) du compte administrateur intégré, afin de déterminer son véritable nom et d'accéder ainsi au serveur. L'identificateur de sécurité correspond à la valeur qui définit de manière unique un compte d'utilisateur, de groupe ou d'ordinateur et une session en cours sur un réseau. Il est impossible de modifier l'identificateur de sécurité de ce compte intégré. Cependant, vos groupes d'opérations peuvent contrôler facilement les attaques tentées contre ce compte Administrateur si vous lui donnez un nom unique.
Pour sécuriser les comptes connus sur les domaines et serveurs, procédez comme suit :
- Renommez les comptes Administrateur et Invité, et modifiez leurs mots de passe en leur attribuant une valeur longue et complexe sur chaque domaine et serveur.
- Choisissez des noms et mots de passe différents sur tous les serveurs. Si vous utilisez un seul nom et un seul mot de passe de compte pour l’ensemble des domaines et des serveurs, un pirate qui parvient à accéder à un serveur membre sera en mesure d’accéder à tous les autres serveurs grâce à ces nom et mot de passe identiques.
- Modifiez les descriptions des comptes en remplaçant les valeurs définies par défaut afin de rendre l’identification des comptes plus difficile.
- Enregistrez les modifications apportées dans un emplacement sécurisé.
**Remarque**: Vous pouvez renommer le compte administrateur intégré par le biais de la stratégie de groupe. Ce paramètre de stratégie n'a pas été implémenté dans les modèles de sécurité fournis avec ce guide, car chaque organisation doit choisir un nom unique pour ce compte. Cependant, vous pouvez configurer le paramètre **Comptes : Renommer le compte administrateur** pour renommer des comptes administrateur dans les trois environnements définis dans ce guide. Ce paramètre de stratégie fait partie de la section des options de sécurité d’un GPO.
#### Sécurisation des comptes de service
À moins que cela ne s’avère absolument nécessaire, évitez de configurer un service pour qu’il fonctionne dans le contexte de sécurité d’un compte de domaine. Si le serveur est endommagé physiquement, les mots de passe de comptes de domaine risquent d'être facilement obtenus en vidant les secrets LSA. Pour plus d'informations sur la sécurisation des comptes de service, voir le [Guide de planification de la sécurité des services et comptes de service](http://www.microsoft.com/france/technet/security/guidance/serversecurity/serviceaccount/default.mspx) à l'adresse www.microsoft.com/france/technet/security/guidance/serversecurity/serviceaccount/default.mspx.
#### Paramètres des services Terminal Server
**Tableau 5.10 Paramètres de services Terminal Server recommandés**
| Définir le niveau de cryptage de la connexion client |
Élevée |
Élevée |
Élevée |
Le paramètre **Définir le niveau de cryptage de la connexion client** détermine le niveau de cryptage des connexions client des services Terminal Server dans votre environnement. L'option **Niveau haut**, qui applique un chiffrement de 128 bits, empêche tout utilisateur malveillant potentiel d’écouter les sessions des services Terminal Server à l’aide d’un analyseur de paquet. Certaines anciennes versions des services Terminal Server ne prennent pas en charge ce niveau de cryptage élevé. Si votre réseau contient de tels clients, définissez le niveau de cryptage de la connexion de sorte que les données soient envoyées et reçues avec le niveau de cryptage le plus élevé possible et pris en charge par le client en question.
Le paramètre **Définir le niveau de cryptage de la connexion client** est configuré sur **Activé** et le chiffrement **Niveau haut** est sélectionné dans la stratégie DCBP pour les trois environnements de sécurité qui sont définis dans ce guide.
Vous pouvez configurer ce paramètre de stratégie dans Windows Server 2003 à l’emplacement suivant, dans l’Éditeur d’objets Stratégie de groupe :
**Configuration ordinateur\\Modèles d'administration\\Composants Windows\\**
**Terminal Services\\Cryptage et Sécurité**
Les trois niveaux disponibles de cryptage sont décrits dans le tableau suivant :
**Tableau 5.11 Niveaux de chiffrement des services Terminal Server**
| Niveau haut |
Crypte les données envoyées par les clients au serveur et par le serveur au client au moyen d’un cryptage fort à 128 bits. Utilisez ce niveau quand le serveur Terminal Server s’exécute dans un environnement contenant uniquement des clients 128 bits, tels que des clients Connexion Bureau à distance. Les clients qui ne prennent pas en charge ce niveau de cryptage ne peuvent pas se connecter. |
| Compatible avec le client |
Crypte les données transmises entre le client et le serveur à la puissance maximale de clé prise en charge par le client. Utilisez ce niveau lorsque le serveur Terminal Server s'exécute dans un environnement comportant des clients mixtes ou des clients hérités. |
| Niveau bas |
Crypte les données qui sont envoyées du client vers le serveur avec un cryptage de 56 bits.
Important : Les données transmises du serveur vers le client ne sont pas cryptées. |
Signalement d’erreurs
Tableau 5.12 Paramètres de signalement d’erreurs recommandés
| Désactiver le signalement d'erreurs de Windows |
Activé |
Activé |
Activé |
Ce service permet à Microsoft de détecter les erreurs et de les corriger. Vous pouvez configurer ce service en vue de générer des rapports relatifs aux erreurs du système d’exploitation, aux erreurs des composants Windows ou encore aux erreurs des applications. Ceci est uniquement disponible sous Windows XP Professionnel et Windows Server 2003.
Le service de **rapport d'erreurs** peut signaler ces erreurs à Microsoft par l'intermédiaire d'Internet ou d'un fichier interne de partage. Les rapports d'erreur peuvent contenir des données sensibles, voire confidentielles ; cependant, la stratégie de confidentialité de Microsoft concernant le signalement d'erreurs garantit que Microsoft n'utilisera pas ces données de façon inconsidérée. Les données sont toutefois envoyées en texte simple au format HTTP, et peuvent donc être interceptées sur Internet et visualisées par des tiers.
Le paramètre **Désactiver le signalement** **d'erreurs de Windows** détermine si le service de **signalement d'erreurs** doit transmettre des données.
Vous pouvez configurer ce paramètre de stratégie dans Windows Server 2003 à l’emplacement suivant, dans l’Éditeur d’objets Stratégie de groupe :
**Configuration ordinateur\\Modèles d’administration\\Système\\Gestion des communications Internet\\Paramètres de communication Internet**
Configurez le paramètre **Désactiver le signalement d'erreurs de Windows** sur **Activé** dans le DCBP pour les trois environnements définis dans ce guide.
[](#mainsection)[Haut de page](#mainsection)
### Création de la stratégie recourant à l'Assistant Configuration de la sécurité (SCW)
Pour déployer les paramètres de sécurité requis, vous devez utiliser l'Assistant Configuration de la sécurité (SCW) et les modèles de sécurité qui sont inclus avec la version téléchargeable de ce guide pour créer une stratégie de base de contrôleur de domaine.
Lorsque vous créez votre propre stratégie, ignorez les sections « Paramètres de Registre » et « Stratégie d'audit ». Ces paramètres de stratégie sont fournis par les modèles de sécurité pour l'environnement choisi. Cette approche permet de s'assurer que les éléments de stratégie fournis par les modèles sont prioritaires par rapport à ceux qui sont configurés par l'Assistant SCW.
Vous devez utiliser une nouvelle installation du système d'exploitation pour commencer votre travail de configuration, ce qui permet de s'assurer qu'il ne subsiste aucun paramètre ou logiciel provenant des configurations précédentes. Vous devez installer un système d'exploitation et utiliser un matériel aussi proche que possible de l'environnement de déploiement, afin d'assurer la compatibilité. La nouvelle installation est appelée *ordinateur de référence.*
**Pour créer la stratégie de base de contrôleur de domaine (DCBP) :**
Vous devez utiliser un ordinateur configuré en tant que contrôleur de domaine pour créer la stratégie de base du contrôleur de domaine. Vous pouvez utiliser un contrôleur de domaine existant ou créer un ordinateur de référence et utiliser l'outil Dcpromo pour transformer l'ordinateur en contrôleur de domaine. Cependant, la plupart des organisations ne veulent pas ajouter un contrôleur de domaine à leur environnement de production dans la mesure où il risque d'enfreindre leur stratégie de sécurité. Si vous utilisez un contrôleur de domaine existant, ne lui appliquez pas de paramètres par l'intermédiaire de l'Assistant de configuration de la sécurité ou ne modifiez pas sa configuration.
1. Installez le composant Assistant Configuration de la sécurité sur l'ordinateur en cliquant sur Panneau de configuration, Ajouter ou supprimer des programmes, Ajouter/Supprimer des composants Windows.
2. Lancez l'interface graphique utilisateur (GUI) de l'Assistant de configuration de la sécurité, sélectionnez **Créer une nouvelle stratégie**, et dirigez-la vers l'ordinateur de référence.
3. Assurez-vous que les rôles serveur détectés correspondent à votre environnement. Ne supprimez pas le rôle de serveur de fichiers, car il est requis pour l'exploitation des contrôleurs de domaine.
4. Assurez-vous que les fonctionnalités détectées du client correspondent à votre environnement.
5. Assurez-vous que les options d'administration détectées correspondent à votre environnement.
**Remarque** : Si votre environnement contient les contrôleurs de domaine dans des sites multiples, assurez-vous que l'option de **réplication Active Directory de type message électronique** est sélectionnée.
6. Assurez-vous que les services supplémentaires requis par votre base, tels que les agents de sauvegarde ou les logiciels antivirus, sont détectés.
7. Décidez comment traiter les services non spécifiés dans votre environnement. Pour plus de sécurité, vous pouvez définir ce paramètre de stratégie sur **Désactiver**. Vous devez tester cette configuration avant de la déployer sur votre réseau de production, afin de prévenir les problèmes liés aux serveurs de production exécutant des services supplémentaires qui ne sont pas dupliqués sur votre ordinateur de référence.
8. Assurez-vous que la case **Ignorer cette section** est désactivée dans la section « Sécurité réseau », puis cliquez sur **Suivant**. Les ports et les applications identifiés plus haut sont configurés en tant qu'exceptions pour le pare-feu Windows.
**Remarque :** Assurez-vous que l'option **Ports pour applications RPC système** est sélectionnée.
9. Dans la section « Paramètres de Registre », cliquez sur la case **Ignorer cette section**, puis sur **Suivant**. Ces paramètres de stratégie sont importés à partir du fichier INF fourni.
10. Dans la section « Stratégie d'audit », cliquez sur la case **Ignorer cette section**, puis sur **Suivant**. Ces paramètres de stratégie sont importés à partir du fichier INF fourni.
11. Incluez le modèle de sécurité approprié (par exemple, EC-Domain Controller.inf).
12. Enregistrez la stratégie sous un nom approprié (par exemple, Domain Controller.xml**)**.
#### Testez la stratégie recourant à l'Assistant Configuration de la sécurité (SCW)
Après avoir créé et enregistré la stratégie, Microsoft recommande fortement de la déployer dans votre environnement de test. Dans l'idéal, vos serveurs de test reproduisent le matériel et la configuration logicielle des serveurs de production. Cette approche permet de trouver et réparer les problèmes potentiels, tels que la présence de services imprévus, requis par des périphériques matériels spécifiques.
Deux options sont disponibles pour tester la stratégie. Vous pouvez utiliser les fonctionnalités natives de déploiement de l'Assistant Configuration de la sécurité, ou déployer les stratégies avec un GPO.
Lorsque vous mettez en place vos stratégies, envisagez d'utiliser les fonctionnalités natives de déploiement de l'Assistant Configuration de la sécurité. Vous pouvez utiliser l'Assistant Configuration de la sécurité (SCW) pour pousser une stratégie de serveur en serveur, ou utiliser Scwcmd pour la pousser vers un groupe de serveurs. La méthode native de déploiement a pour avantage de simplifier la restauration des stratégies déployées à l'aide de l'Assistant Configuration de la sécurité. Cette capacité peut être très utile lorsque vous apportez plusieurs modifications à vos stratégies pendant le processus de test.
La stratégie est testée pour s'assurer que l'application de cette stratégie aux serveurs cibles ne nuira pas à leurs fonctions essentielles. Après avoir appliqué les modifications de configuration, vous devez vérifier les principales fonctionnalités de l'ordinateur. Par exemple, si le serveur est configuré en tant qu'autorité de certification, assurez-vous que les clients peuvent demander et obtenir des certificats, télécharger une liste de révocation de certificats, et ainsi de suite.
Lorsque vos configurations de stratégie sont fiables, vous pouvez utiliser Scwcmd comme indiqué dans la procédure suivante afin de convertir les stratégies en objet de stratégie de groupe (GPO).
Pour plus de détails sur la manière de tester les stratégies SCW, voir le [Guide de déploiement pour l'Assistant de configuration de la sécurité](http://technet2.microsoft.com/windowsserver/fr/library/5254f8cd-143e-4559-a299-9c723b3669461036.mspx?mfr=true) à l'adresse technet2.microsoft.com/windowsserver/en/
library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx?mfr=true* *et la [Documentation de l'Assistant Configuration de la sécurité](http://go.microsoft.com/fwlink/?linkid=43450) à http://go.microsoft.com/fwlink/?linkid=43450.
#### Convertissez et déployez la stratégie
Après avoir testé la stratégie de façon exhaustive, procédez comme suit pour la convertir en GPO et la déployer :
1. Suite à l'invite de commande, tapez la commande suivante :
```
scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
```
puis appuyez sur ENTREE. Exemple :
```
scwcmd transform /p:"C:\\Windows\\Security\\msscw\\Policies\\Domain Controller.xml" /g:"Domain Controller Policy"
```
**Remarque** : Les informations à entrer sur la ligne de commande sont présentées ici sur plusieurs lignes pour des raisons de limitation de l'affichage. Ces informations doivent être tapées sur une seule ligne.
2. Utilisez la console de gestion des stratégies de groupes pour lier l'objet GPO que vous venez de créer à l'UO de contrôleurs de domaine appropriée et placez cette stratégie au-dessus de la stratégie contrôleurs de domaine par défaut pour lui donner la priorité.
Si le fichier de stratégie de sécurité de l'Assistant Configuration de la sécurité (SCW) contient des paramètres de pare-feu Windows, ce dernier doit être actif sur l'ordinateur local pour que cette procédure aboutisse. Pour s'assurer que le pare-feu Windows est actif, ouvrez le Panneau de configuration et double-cliquez ensuite sur **Pare-feu Windows**.
Tenez compte du fait que la réplication de l'objet GPO qui vient d'être créé sur l'ensemble des contrôleurs de domaine peut prendre du temps, surtout dans les environnements avec les contrôleurs de domaine dans plusieurs sites. Après avoir vérifié la réplication des objets GPO, vous devez procéder à un test final pour vous assurer que l'objet GPO applique les paramètres de stratégie voulus. Pour compléter cette procédure, assurez-vous que les paramètres appropriés ont été appliqués et que les fonctionnalités ne sont pas affectées.
[](#mainsection)[Haut de page](#mainsection)
### Résumé
Ce chapitre a indiqué comment renforcer les serveurs de contrôleur de domaine qui exécutent Windows Server 2003 avec SP1 dans les trois environnements définis dans ce guide. La plupart des paramètres de stratégie qui ont été abordés ont été configurés et appliqués via la stratégie de groupe. La stratégie de base du contrôleur de domaine (DCBP) qui vient compléter la stratégie de contrôleur de domaine par défaut a été liée à l'UO de contrôleurs de domaine.
Les paramètres DCBP amélioreront la sécurité globale des contrôleurs de domaine quel que soit l'environnement. L’utilisation de deux objets GPO pour sécuriser les contrôleurs de domaine permet de préserver l’environnement par défaut et de simplifier le dépannage.
Certains des paramètres de renforcement de serveur traités dans ce guide ne peuvent pas être appliqués via la stratégie de groupe. Des instructions détaillées de configuration manuelle ont été fournies pour ces paramètres.
Une fois les contrôleurs de domaine configurés pour la sécurité, vous pouvez procéder au renforcement de la sécurité des autres rôles de serveur. Les chapitres suivants de ce guide portent sur la sécurisation de rôles de serveur spécifiques.
#### Informations complémentaires
Les liens suivants fournissent des informations supplémentaires sur les rubriques relatives au renforcement des contrôleurs de domaine qui exécutent Windows Server 2003 avec SP1.
- Pour plus d'informations sur les guides prescriptifs d'architecture Microsoft Systems Architecture : Enterprise Data Center, consultez la page [MSA EDC Prescriptive Architecture Guide](http://www.microsoft.com/resources/documentation/msa/edc/all/solution/en-us/pak/pag/default.mspx) à www.microsoft.com/resources/documentation/msa/edc/all/solution/
en-us/pak/pag/default.mspx.
- Pour plus d'informations l'activation de l'accès anonyme à Active Directory, consultez l'article suivant dans la base de connaissances Microsoft « [Description de choix Dcpromo d'autorisations](http://support.microsoft.com/kb/257988/fr) » à l'adresse http://support.microsoft.com/kb/257988/fr.
- Pour plus d'informations sur DNS dans Windows 2000, consultez le document « [Windows 2000 DNS](http://www.microsoft.com/windows2000/techinfo/howitworks/communications/nameadrmgmt/w2kdns.asp) » à l'adresse http://technet.microsoft.com/en-us/library/Bb742582.aspx
.
- Pour plus d'informations sur DNS dans Windows 2000, consultez le chapitre 6 de la version en ligne du document « [TCP/IP Core Networking Guide](http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/corenetwork.mspx?mfr=true) » dans le Kit de ressources Windows 2000 Server à l'adresse www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/CoreNetwork.mspx?mfr=true.
- Pour plus d'informations sur DNS dans Windows 2003, consultez la page « [Changes to DNS in Windows Server 2003](http://www.microsoft.com/windows2000/technologies/communications/dns/dns2003.asp) » à http://support.microsoft.com/kb/843582/fr.
- Pour plus d'informations sur la limitation du trafic Active Directory, consultez l'article suivant dans la base de connaissances Microsoft « [Limiter le trafic de réplication Active Directory à un port spécifique](http://support.microsoft.com/kb/224196/fr) » à l'adresse http://support.microsoft.com/kb/224196/fr.
- Pour plus d’informations sur la restriction de trafic de réplication FRS, consultez l'article suivant dans la base de connaissances Microsoft « [Comment limiter le trafic de réplication FRS à un port spécifique statique](http://support.microsoft.com/kb/319553/fr) » à l'adresse http://support.microsoft.com/kb/319553/fr.
- Pour plus d'informations sur le service de temps de Windows, consultez le document [Windows Time Service Technical Reference](http://technet2.microsoft.com/windowsserver/en/library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx?mfr=true) à l'adresse http://technet2.microsoft.com/windowsserver/en/library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx?mfr=true.
- Pour plus d'informations sur l'usurpation d'adresse IP, consultez l'article « [Introduction to IP Spoofing](http://www.giac.org/practical/gsec/victor_velasco_gsec.pdf) » à l'adresse www.giac.org/practical/gsec/Victor\_Velasco\_GSEC.pdf.
**Téléchargement**
[Obtenir le Guide de sécurité Windows Server 2003](http://go.microsoft.com/fwlink/?linkid=14846)
**Notifications de mise à jour**
[Inscrivez-vous pour en savoir plus sur les mises à jour et les nouvelles publications](http://go.microsoft.com/fwlink/?linkid=54982)
**Commentaires**
[Envoyez-nous vos commentaires ou vos suggestions](mailto:secwish@microsoft.com?subject=guide%20de%20sécurité%20windows%C2%A0server%202003)
[](#mainsection)[Haut de page](#mainsection)