Vous êtes sur la page 1sur 40

Qu’est-ce

qu’Active Directory ?
Brian Svidergol
MCITP, MCSE, RHEL3, VCP, NCIE-SAN, MCT, MCSA,

Expert en solutions certifié par Microsoft

1
Table des matières

Introduction 3

Chapitre I Présentation d’Active Directory Services Technologies 4

Chapitre II Outils d'administration 5

Chapitre III Présentation d’AD 6

Contrôleurs de domaine 6

SYSVOL 9

Chapitre IV Forêts, Domains, Trusts 10

Forêts 10

Domaines 11

Approbations 13

Chapitre V Stratégie de groupe 17

Chapitre VI Présentation de la base de données d’AD DS 19

Chapitre VII Réplication 21

Chapitre VIII DNS et DHCP 25

Chapitre IX Sécurité 29

Chapitre X Audit 32

Chapitre XI Données de journalisation peu conviviales 36

Références utiles 38

À propos de l’auteur 40

À propos de Netwrix 40

2
Introduction

Les administrateurs informatiques travaillent avec Active Directory depuis


l’introduction de cette technologie dans Windows 2000 Server. Windows 2000 Server a
été lancé le 17 février 2000, mais de nombreux administrateurs ont commencé à
travailler avec Active Directory fin 1999, à sa sortie en version RTM, le 15 décembre
1999.

Cet e-book s’adresse non seulement aux SysAdmins débutants qui veulent se
familiariser avec la structure, la terminologie et les configurations d’Active Directory,
mais aussi aux administrateurs systèmes expérimentés, qui y trouveront des bonnes
pratiques de gestion d’Active Directory et découvriront des domaines moins connus
des professionnels de l’informatique.

Introduction 3
I. Présentation d’Active
Directory Services Technologies

Comme beaucoup d’autres domaines informatiques, les services d’annuaires se


sont rapidement développés, avec de nouvelles fonctions et fonctionnalités,
et une complexité accrue. La catégorie des services d’annuaire comprend de
nombreux services.

De nombreux fournisseurs tiers créent des produits autonomes ou


complémentaires à l’offre Microsoft. À l’heure actuelle, les technologies de
services d’annuaire de Microsoft comprennent les produits suivants :

Active Directory Domain Services (AD DS). AD DS est le thème même du présent
e-book et ne nécessite donc pas d’être présenté. Mais que diriez-vous, à la
place, d’un fait intéressant ? Selon Takeshi Numoto, vice-président de
groupe chez Microsoft, Active Directory est utilisé par 93 % des entreprises du
Fortune 1000.

Active Directory Lightweight Directory Services (AD LDS). AD LDS est un


annuaire léger, optimisé pour les développeurs, qui peut être déployé sur un
ordinateur client et un système d’exploitation client ainsi que sur un serveur. Il
n’est pas aussi complet qu’AD DS (par exemple, il ne comprend pas la stratégie de
groupe) mais il peut être utile aux développeurs et aux testeurs comme
répertoire décentralisé.

Active Directory Federation Services (AD FS). AD FS est une solution de gestion
des identités basée sur les réclamations, qui permet aux organisations
indépendantes de connecter leurs technologies de services d’annuaire afin
de faciliter les ouvertures de session uniques et les accès trans-
organisationnels aux ressources. Elle est aujourd’hui devenue assez courante
car elle permet aux organisations de se connecter à des services Cloud comme
Microsoft Azure.

Par ailleurs, vous vous posez peut-être des questions à propos de deux autres rôles.
Active Directory Certificate Services (AD CS) et Active Directory Rights Management
Services (AD RMS) sont souvent groupés avec les autres technologies énumérées ci-
dessus afin de former la suite technologique proposée par Microsoft pour les
déploiements relatifs à Active Directory sur site. Ajoutons à cela des produits qui ne
font pas partie de la famille immédiate d’Active Directory, comme Microsoft Forefront
Identity Manager (FIM). Hormis les technologies sur site, plusieurs solutions Cloud,
comme Azure Active Directory et Azure Multi-Factor Authentication, offrent des
services dans le Cloud. Ce livre blanc se concentre sur AD DS déployé sur site.

Chapitre I | Présentation d’Active Directory Services Technologies 4


II. Outils d'administration

De nombreux outils sont proposés pour Active Directory. L’outil que nous
allons présenter aujourd’hui, Utilisateurs et ordinateurs Active Directory (ADUC), a
été lancé avec Windows 2000 Server. ADUC est un composant logiciel
enfichable MMC qui permet aux administrateurs de gérer les objets Active
Directory, notamment les utilisateurs, les ordinateurs, les groupes, les unités
organisationnelles et les attributs. Même si les fonctionnalités d’ADUC et de
nombreuses autres fonctionnalités ont été ajoutées à un nouvel outil appelé Centre
d’administration Active Directory, ADUC reste un outil populaire que les
administrateurs utilisent pour gérer leur environnement.

En plus de la gestion des objets, ADUC permet également de gérer les opérations
de domaine. Vous pouvez par exemple augmenter le niveau fonctionnel du
domaine à partir d’ADUC. Vous pouvez également transférer les rôles FSMO
Maître des ID relatifs, Émulateur PDC et Infrastructure à un contrôleur de domaine
différent à l’aide d’ADUC.

La gestion d’un objet consiste en des tâches évidentes comme la réinitialisation


du mot de passe d’un utilisateur (Netwrix dispose d’un logiciel gratuit pour
réinitialiser les mots de passe en masse), l’ajout d’utilisateurs aux groupes
de sécurité et le déplacement d’objets d’ordinateur. Le paramètre
Fonctionnalités avancées d’ADUC vous permet également de gérer le conteneur
LostAndFound, les quotas NTDS, les données du programme et les informations
système. Cette vue n’est pas activée par défaut mais vous pouvez l’activer via le
menu Affichage. L’option Fonctionnalités avancées ajoute de nombreux onglets à
la page des propriétés d’un objet, y compris les certificats publiés, un éditeur
d’attributs, une fonction de réplication de mot de passe, etc.

Le menu Affichage vous permet également de filtrer l’affichage selon le type


d’objet, par exemple : utilisateur, ordinateur, imprimante ou autres. Des
colonnes individuelles peuvent être ajoutées ou supprimées afin de personnaliser la
vue en vue d’inclure d’autres attributs qui ont été affectés à l’objet, par
exemple la date de dernière modification, la ville, le pays, l’adresse e-mail, et
plus. Enfin, ADUC vous permet de déléguer le contrôle des objets via l’assistant
Délégation de contrôle ou en modifiant manuellement les autorisations pour un
objet.

Chapitre II | Outils d'administration 5


III. Présentation d’AD
Un déploiement d’AD DS comporte de nombreux aspects. Dans ce livre blanc, nous
aborderons les contrôleurs de domaine, la base de données d’AD DS et SYSVOL. Nous
nous concentrerons sur certaines parties de ces trois composantes, mais d’autres
parties et composantes sont également importantes.

Contrôleurs de domaine
Le contrôleur de domaine est la colonne vertébrale d’Active Directory. Sans contrôleur
de domaine, il n’y a pas d’annuaire ! Vous pouvez utiliser jusqu’à 1 200 contrôleurs de
domaine dans un seul domaine. Mais ne jugez pas l’environnement d’un autre
administrateur par son ampleur ! Penchons-nous sur l’évolution des contrôleurs de
domaine :

Windows NT 3.1 lance le premier domaine Microsoft. Windows NT 3.1 (et


ensuite 3.5 puis 3.51) ne doit pas être confondu avec Windows 3.1 qui était un
système d’exploitation client 16 bits. La fonctionnalité de domaine incluse dans
Windows NT n’était pas un modèle multimaître comme AD DS. Il y avait un
contrôleur de domaine principal et des contrôleurs de domaine
secondaires. Toutes les modifications étaient prises en charge par le contrôleur
de domaine principal. Dans une situation de reprise après sinistre, un
contrôleur de domaine secondaire pouvait être promu contrôleur de domaine
principal. Le rôle FSMO émulateur de contrôleur de domaine principal que nous
avons aujourd’hui est directement lié au contrôleur de domaine principal
d’origine.

Avec Windows 2000 Server est arrivé Active Directory. En lançant Windows
2000 Server, Microsoft a réorganisé une grande partie du domaine
traditionnel et commercialisé le service sous le nom d’Active Directory.
Une caractéristique majeure d’Active Directory était le modèle multimaître, qui
permettait à la plupart des fonctionnalités d’Active Directory, y compris les
modifications, d’être appliquées sur n’importe quel contrôleur du domaine.

De nouvelles fonctionnalités ont été introduites dans Windows Server 2003.


Avec Windows Server 2003, des améliorations administratives ont été apportées à
Active Directory (notamment la sélection multiple d’objets dans ADUC), ainsi
que la possibilité de créer des approbations de forêt et la fonction de mise en
cache des appartenances aux groupes universels. D’autres fonctionnalités ont été
ajoutées ou étendues, en particulier en ce qui concerne l’administration en ligne
de commande.

Windows Server 2003 R2 a été doté d’AD FS et d’Active Directory Application Mode
(ADAM). AD FS et ADAM ont constitué des améliorations importantes, lorsqu’on
y pense aujourd’hui. Mais à l’époque, ils n’étaient pas très utilisés. ADAM est plus
tard devenu AD LDS tandis que AD FS a été actualisé pour l’intégration Cloud.

Chapitre III | Présentation d’AD 6


Windows Server 2008 : lancement des contrôleurs de domaine en lecture
seule (RODC) et des politiques de mots de passe affinées. Avec Windows Server
2008, les RODC sont devenus une option permettant, entre autres, aux
administrateurs de déployer des contrôleurs de domaine dans des
armoires informatiques non sécurisées dans les succursales. Par ailleurs,
des politiques de mots de passe affinées ont été intégrées, assorties de
quelques défis administratifs tels que l’absence d’une interface utilisateur
graphique pour gérer ces politiques.

Windows Server 2008 R2 a apporté la corbeille Active Directory et le


module PowerShell. Dans Windows Server 2008 R2, certaines fonctionnalités
introduites dans Windows Server 2008 ont encore été affinées, et la corbeille
Active Directory a vu le jour, ainsi qu’un module PowerShell permettant aux
administrateurs de gérer efficacement AD DS depuis PowerShell.

Windows Server 2012 : gestion simplifiée et prise en charge améliorée de


la virtualisation. L’interface utilisateur graphique a bénéficié d’outils très
attendus pour gérer la corbeille et les politiques de mots de passe affinées.
De plus, la virtualisation a été améliorée et la prise en charge de la
virtualisation des contrôleurs de domaine est devenue la norme. Pour
tout savoir sur ces modifications, consultez https://
technet.microsoft.com/en-us/library/hh831477.aspx.

Windows Server 2012 R2 s’est concentré sur les améliorations de sécurité.


Les nouvelles fonctionnalités ont compris l’authentification
multifactorielle, l’authentification unique à partir des périphériques connectés et
le contrôle d’accès multifactoriel. Pour tout savoir sur ces modifications,
consultez https://technet.microsoft.com/en-us/library/dn268294.aspx.

Pour déployer des contrôleurs de domaine, il convient de respecter certaines


bonnes pratiques. Un grand nombre de ces pratiques sont documentées.
Mais peu d’organisations les adoptent. Nous passerons sur les bonnes pratiques
bien connues telles que la maintenance de la base de données d’Active Directory
sur un ensemble de broches de disque, les fichiers journaux sur des broches de
disque distinctes, et le système d’exploitation sur son propre ensemble de broches
de disque. Voici certaines bonnes pratiques peu adoptées pour les contrôleurs de
Exécutez l’installation domaine :
Server Core du système
d’exploitation De nombreux administrateurs évitent les changements, en particulier
pour les systèmes comme AD DS qui sont incroyablement stables. Par
conséquent, lorsqu’un nouvel administrateur propose de passer à l’installation
Server Core, il se heurte souvent à des regards de réprobation. Mais en
réalité, la plupart des administrateurs gèrent AD DS à distance en lançant
ADUC ou PowerShell sur leur ordinateur client ou d’administration. Tous les
outils de gestion de base, y compris le centre d’administration
d’Active Directory (ADAC) et Windows PowerShell, fonctionnent de
manière presque identique lorsqu’ils sont utilisés localement sur un
contrôleur de domaine ou à distance depuis un ordinateur client ou un ordinateur
d’administration. Par conséquent, en optant pour l’installation Server Core,
l’expérience d’administration n’est pas dégradée. De plus, la sécurité est
renforcée et les performances sont légèrement améliorées.

Chapitre III | Présentation d’AD 7


Ne lancez pas d’autres Il y a dix ans, la plupart des organisations utilisaient des serveurs physiques,
logiciels ni d’autres car la virtualisation n’en était qu’à ses débuts. Lorsque le moment était venu de
services sur un contrôleur mettre en service un nouveau serveur de fichiers, un serveur DHCP ou un
de domaine serveur d’impression, les administrateurs se contentaient souvent de tirer parti
d’un serveur existant. Ou d’un contrôleur de domaine. En 2015, la virtualisation
devient de facto la norme et le déploiement automatisé permet de créer une
nouvelle machine virtuelle en quelques minutes, l’ancienne méthode étant loin
d’être aussi efficace.

Aujourd’hui, lorsque vous avez besoin d’un emplacement pour un serveur de


fichiers, un serveur DHCP, un serveur d’impression ou un autre serveur
d’application, vous pouvez mettre en service une nouvelle machine virtuelle.
Ou mieux encore, vous pouvez mettre en service une nouvelle machine virtuelle
en tant que serveur utilitaire. Un serveur utilitaire est un serveur qui héberge les
applications et les services trop petits pour justifier un serveur dédié. Ceci
permet à vos contrôleurs de domaine de bénéficier d’un service dédié qui
apporte plus de stabilité.

Bien que tous vos contrôleurs de données en lecture-écriture doivent se trouver


Ajustez l’ordre de
dans un centre de données sécurisé, de nombreuses personnes, et pas seulement
démarrage et définissez
du service informatique, y ont accès. Par exemple, les électriciens sous-traitants qui
un mot de passe pour
travaillent sur le système de refroidissement ont accès au centre de données. Il
le BIOS
est aussi probable que des spécialistes réseau, des techniciens de câblage
et des responsables informatiques aient accès aux centres de données. Toute
personne disposant d’un accès physique à un contrôleur de domaine peut y
accéder en quelques minutes seulement depuis une console située dans le
centre de données. Il existe des images de démarrage logiciel gratuites et
spécialisées que vous pouvez utiliser pour démarrer et réinitialiser des mots de
passe, installer des logiciels malveillants ou accéder aux données du disque, à
condition que celui-ci ne soit pas chiffré. Pour éviter cela, effectuez les
configurations suivantes :
Assurez-vous que tous les supports amovibles ne sont pas inclus dans l’ordre
de démarrage du BIOS. Seul le disque dur sur lequel le système
d’exploitation est installé doit faire partie de l’ordre de démarrage. Cela vaut
également pour vos serveurs hôtes de virtualisation, si vous avez des
contrôleurs de domaine virtuels.

Définissez un mot de passe fort pour le BIOS. En l’absence de mot de passe


pour le BIOS, n’importe qui peut mettre à jour l’ordre de démarrage, démarrer
depuis le support d’installation de Windows Server ou d’un des
nombreux kits de ressources gratuits et effectuer une réparation pour
accéder à une invite de commande. Arrivé à l’invite de commande, il est
possible de faire des ravages et de réinitialiser rapidement les mots de passe
des comptes de domaine.

Conservez les contrôleurs de domaine dans une armoire fermée à clé. Si un


mot de passe pour le BIOS constitue une couche de sécurité, un pirate
moyennement compétent saura probablement comment réinitialiser le
BIOS pour que la configuration se réinitialise et que le mot de passe soit
supprimé. Cela exige souvent de pouvoir accéder à la carte mère. Vous pouvez
réduire le risque d’une attaque de ce type en conservant les contrôleurs de
domaine dans une armoire fermée à clé. Certains serveurs disposent
également de châssis verrouillables. Dans les environnements de haute
sécurité, optez pour les deux.
Chapitre III | Présentation d’AD 8
Standardisez la You should try to match the configuration settings for each DC. You can
configuration de tous les accomplish some of this by using build automation through deployment tools
contrôleurs de domaine such as System Center Configuration Manager. Items of interest for DCs are the
event log size settings to ensure that you have large sizes to capture
auditing and security related information, boot settings such as the timeout
waiting for OS selection on physical servers, firmware and BIOS versions and
settings, and hardware configuration. Of course, there are many other
configuration items to standardize by using Group Policy. The primary goal is
to configure the DCs identically.

SYSVOL
Le volume système (SYSVOL) est un répertoire spécial de chaque contrôleur
de domaine. Il est composé de plusieurs dossiers, dont l’un est partagé et
appelé « partage SYSVOL ». L’emplacement par défaut de ce dossier
partagé est %SYSTEMROOT%\SYSVOL\sysvol, mais vous pouvez le modifier au
cours du processus de promotion du contrôleur de domaine ou à tout moment
par la suite. SYSVOL est composé de :

Dossiers. Les dossiers servent à stocker des :

Modèles de stratégie de groupe (GPT), qui sont répliqués via la réplication de


SYSVOL. Le conteneur de stratégie de groupe (GPC) est répliqué via la
réplication d’Active Directory

Scripts, par exemple les scripts de démarrage qui sont référencés dans un
objet de stratégie de groupe.

Points de jonction. Les points de jonction fonctionnent comme des raccourcis.


Un répertoire peut pointer vers un autre répertoire. Dans l’Explorateur de
fichiers, un point de jonction et un répertoire se ressemblent et fonctionnent de
manière similaire. Vous pouvez afficher les points de jonction en exécutant la
commande dir /AL /S.

Réplication de SYSVOL par DFSR. Autrefois, sous Windows 2000 Server,


Windows Server 2003 et Windows Server 2003 R2, la réplication était assurée
par le service de réplication des fichiers (FRS). Depuis la création de domaines
sous Windows Server 2008, DFSR est devenue la méthode de réplication SYSVOL
par défaut. FRS n’était pas très efficace. Chaque fois qu’un fichier était modifié
dans SYSVOL, FRS répliquait la totalité du fichier vers tous les contrôleurs de
domaine. Avec DFSR, seule la partie modifiée du fichier est répliquée, mais
uniquement pour les fichiers de plus de 64 Ko. DFSR utilise la compression
différentielle à distance (RDC). La RDC permet de ne répliquer que les
données modifiées. Certains administrateurs se rappellent peut-être avoir migré
de FRS vers DFSR à la sortie de Windows Server 2008. Sans réplication fiable
et opportune, l’un des effets secondaires que les utilisateurs peuvent subir est
l’incohérence de l’application des objets de stratégie de groupe, puisque les
données SYSVOL peuvent ne pas être synchronisées dans toutes les plateformes.

Chapitre III | Présentation d’AD 9


IV. Forêts, Domains, Trusts
Les administrateurs connaissent relativement bien les forêts et les domaines. Mais
les approbations, moins. Dans cette section, nous allons examiner certaines parties
des forêts, des domaines et des approbations et discuter de certaines bonnes
pratiques qui les concernent.

Forêts
La forêt est le conteneur logique le plus élevé d’un environnement AD DS. Elles
ont été introduites pour la première fois avec Active Directory dans Windows
Server 2000. Une forêt est constituée d’un ou plusieurs domaines et de tous
les objets qui s’y trouvent. Dans une base de données, une forêt n’est qu’un
conteneur, comme beaucoup d’objets en dessous d’elle, par exemple les
domaines et les unités d’organisation (OU). La forêt est la frontière de sécurité
d’un environnement AD DS. Aux premiers temps d’Active Directory, le
domaine était défini comme la frontière de sécurité. À la différence de
nombreux autres éléments dont nous parlons dans ce livre blanc, le nombre
de forêts que vous pouvez déployer n’est pas limité. Comme elles sont les
objets les plus élevés dans la hiérarchie, vous pouvez en créer autant que
vous le souhaitez, en supposant que vous ayez suffisamment de serveurs
physiques ou de machines virtuelles (ne considérez pas cela comme une
recommandation !). Une forêt comporte trois partitions de répertoire :

Schéma. La partition schéma définit toutes les classes, tous les objets et
attributs qui peuvent être utilisés. Le schéma est partagé entre tous les
domaines de la forêt. Les objets tels que les utilisateurs, les groupes et les OU
sont définis dans le schéma.

Configuration. La partition configuration sert à gérer la topologie de la forêt,


ses paramètres et ceux du domaine. La partition configuration contient une
liste de tous les domaines, contrôleurs de domaine et catalogues globaux.
Vous pouvez visualiser la partition configuration d’un domaine nommé
contoso.com en consultant cn=configuration,dc=contoso,dc=com dans ADSIEdit.

Application. La partition application sert à stocker les données d’application.


Un exemple courant de données contenues dans la partition application est le
DNS.

Sur les cinq rôles FSMO, deux sont spécifiques à la forêt :

Contrôleur de schéma. Ce rôle sert à mettre à jour le schéma. Le titulaire de ce


rôle doit être connecté et disponible pour pouvoir actualiser le schéma.

Maître d’opérations des noms de domaine. Ce rôle sert à ajouter et à supprimer


des domaines à la forêt. Le titulaire de ce rôle doit être connecté et disponible
pour pouvoir effectuer des ajouts et des suppressions de domaines.

Chapitre IV | Forêts, Domaines, Approbations 10


On trouve sur Internet une bonne quantité de recommandations à propos des
forêts d’Active Directory. Voici quelques pratiques recommandées :

Commencez toujours par une forêt unique. Par la suite, si certaines


exigences ne peuvent être satisfaites par une seule forêt, ajoutez-en selon les
besoins. Ou mieux encore, commencez par valider ces exigences. Le fait
d’utiliser plusieurs forêts dans un environnement de production est
souvent inutile et ajoute une charge administrative et une complexité
inutile. Avec une technologie dorsale supposée fonctionner en permanence,
il convient d’opter pour une implémentation simple reposant sur de bonnes
pratiques, par opposition à une implémentation multiforêt assortie d’un
grand nombre de contrôleurs de domaine. Dans de nombreux
environnements, une forêt de production unique satisfait les exigences
ou les dépasse. De plus, il est recommandé de disposer d’une deuxième
forêt hors production pour le développement, les essais et l’assurance
qualité.

Évitez les domaines racines de forêt vides. Lors du lancement d’Active


Directory, Microsoft recommandait d’utiliser un domaine racine vide qui
constituerait une frontière de sécurité pour les objets d’entreprise stockés
dans le domaine racine, par exemple le groupe Administrateurs de
l’entreprise. Cependant, peu après, les directives ont changé et la racine de
forêt vide n’a plus été recommandée par défaut. Les administrateurs ont
constaté que le maintien du domaine racine de forêt vide ajoutait une
charge administrative à leur environnement sans apporter beaucoup de
valeur. Aujourd’hui, la tendance est à la réduction des forêts.
Minimisez le nombre total de forêts.

Si vous utilisez des approbations de forêt à double sens, consolidez les


forêts. Chaque forêt que vous entretenez entraîne des charges
administratives. De plus, chaque forêt augmente la complexité de votre
environnement, ce qui le rend plus difficile à sécuriser, à entretenir et à
restaurer en cas de sinistre. Si vous utilisez des approbations à double sens
entre les forêts, envisagez de consolider les forêts, car une approbation à
double sens entre les forêts correspond en fait à une seule forêt avec charges
supplémentaires.

Domaines
Un domaine est le conteneur logique qui se trouve directement sous le
conteneur forêt. Historiquement, les origines du domaine tel que nous le
connaissons remontent à X.400, une norme de télécommunications
recommandée pour la première fois en 1984 ! Chaque domaine est contenu
dans un seul conteneur forêt. Un domaine abrite d’autres conteneurs et objets en
dessous de lui. Aux premiers temps d’Active Directory, le domaine était défini
comme une frontière de sécurité. Mais cette définition a été actualisée, et c’est
désormais la forêt qui définit la frontière de sécurité. Il s’agit d’un changement
majeur que certains administrateurs n’ont pas remarqué.

Chapitre IV | Forêts, Domaines, Approbations 11


Du point de vue de l’évolutivité, vous pouvez avoir un très grand nombre de
domaines dans une seule forêt, comme ceci :

Windows 2000 Server. Lors de son lancement, Active Directory prenait en


charge jusqu’à 800 domaines dans une seule forêt.

Windows Server 2003 and later. Si vous utilisez le niveau fonctionnel forêt
de Windows Server 2003 ou un niveau supérieur, une seule forêt peut
prendre en charge jusqu’à 1200 domaines.

Dans un domaine, plusieurs composants fonctionnent ensemble. Un


domaine comprend les éléments suivants :

Schéma

Catalogue global

Service de réplication

Rôles de maître d’opérations

Le schéma, décrit précédemment dans la section Forêt, définit les objets utilisés
dans un domaine. Il peut s’agir d’objets physiques ou logiques. Par exemple, un
ordinateur physique est représenté par un objet compte d’ordinateur, tandis
qu’un sous-réseau est représenté par un objet sous-réseau. Les objets ont de
nombreux attributs. Les attributs définissent les propriétés, les limites et le
format des objets. Les attributs peuvent avoir plusieurs valeurs, ils peuvent
être des chaînes de caractères, des entiers, des booléens (vrai ou faux) ou
bien d’autres types. Les attributs spécifiques d’un objet sont définis par le
schéma. Un serveur de catalogue global stocke des informations sur chaque
objet d’un domaine. Les administrateurs et les utilisateurs interrogent un
serveur de catalogue global pour trouver des informations sur des objets. Par
exemple, si un administrateur doit rechercher des informations sur un compte
d’utilisateur, par exemple une adresse, un numéro de téléphone ou
l’emplacement d’un bureau, il interrogera le serveur de catalogue global pour
trouver ces informations.

Les rôles d’opérations à maître unique flottant (FSMO) effectuent chacun des
tâches spécifiques au sein d’un domaine. Les 5 rôles FSMO sont les suivants :

Contrôleur de schéma

Maître d’opérations des noms de domaine

Maître d’infrastructure

Maître des ID relatifs

Émulateur PDC

Chapitre IV | Forêts, Domaines, Approbations 12


Dans chaque forêt, il y a un unique matre d’opérations des noms de domaine
et contrôleur de schéma (décrits dans la section Forêt de cet e-book). In each
domain, there is 1 Infrastructure Master, 1 RID Master, and 1 PDC Emulator. At
any given time, there can only be one DC performing the functions of each role.
Therefore, a single DC could be running all five FSMO roles, however, there can be
no more than five servers in a single-domain environment that run the roles.
For additional domains, each domain will contain its own Infrastructure Master,
RID Master, and PDC Emulator.

Le maître des ID relatifs fournit des ID relatifs à chaque contrôleur


d’un domaine. Les nouveaux objets apportés à un domaine, par
exemple un utilisateur ou un ordinateur, reçoivent un identifiant de
sécurité (SID) unique. Ce SID inclut un identifiant de domaine (unique
pour chaque domaine) et un ID relatif spécifique pour chaque objet. La
combinaison des deux garantit que chaque objet du domaine dispose d’un
identifiant unique, et qu’il contient à la fois l’identifiant de sécurité (SID) et l’ID
relatif (RID) du domaine. L’émulateur PDC contrôle l’authentification au sein
d’un domaine : Kerberos v5 ou NTLM. Lorsqu’un utilisateur change de mot
de passe, cette modification est traitée par l’émulateur PDC. Enfin,
le maître d’infrastructure synchronise les objets avec les serveurs de
catalogue global. Le maître d’infrastructure compare ses données à celles
d’un serveur de catalogue global et reçoit de celui-ci les données non
trouvées dans sa propre base de données. Si tous les contrôleurs d’un
domaine sont également des serveurs de catalogue global, ils disposeront
tous d’informations actualisées, en supposant que la réplication fonctionne.
Dans un tel scénario, peu importe l’emplacement du rôle de maître
d’infrastructure, qui n’a aucun travail à accomplir.

Approbations
Une approbation est une relation entre des forêts et/ou des domaines.
Dans une forêt AD, tous les domaines s’approuvent entre eux car une
approbation transitive à double sens est créée lorsqu’un domaine est ajouté.
Cela permet la transmission de l’authentification d’un domaine à n’importe
quel autre dans la même forêt. Vous pouvez également créer des
approbations en dehors de la forêt avec d’autres forêts et domaines AD DS ou
des royaumes Kerberos v5. Du temps de Windows NT 4.0, il n’existait pas
de forêt ni de structure hiérarchique. Si vous aviez plusieurs
domaines, vous deviez créer manuellement des approbations entre eux.
Avec Active Directory, vous disposez automatiquement
d’approbations transitives bidirectionnelles entre les domaines d’une
même forêt. Avec Windows NT 4.0, il fallait aussi utiliser NetBIOS pour
établir des approbations ! Heureusement, les choses ont bien évolué
et nous disposons désormais de fonctionnalités d’approbation
supplémentaires, notamment en matière de sécurisation des
approbations, grâce à l’authentification sélective et au filtrage des SID
(identificateurs de sécurité). Chaque approbation d’un domaine est stockée
comme un objet domaine approuvé (TDO) dans le conteneur système. Pour
trouver et répertorier toutes les approbations et tous les
types d’approbation dans un domaine nommé contoso.com, exécutez la
commande Windows PowerShell:

Chapitre IV | Forêts, Domaines, Approbations 13


Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –
Filter * -Properties trustType | where {$_.objectClass –eq
“trustedDomain”} | select Name,trustType

Quatre valeurs sont valides pour l’attribut trustType (Type d’approbation).


Cependant, seules la valeur 1 (indiquant une approbation avec un domaine
NT) et la valeur 2 (indiquant une approbation avec un domaine Active
Directory) sont courantes. De nombreuses autres informations utiles sur les
approbations sont stockées dans l’objet domaine approuvé. Dans un domaine
nommé contoso.com, pour examiner toutes les propriétés d’approbation,
exécutez la commande:

Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –


Filter * -Properties * | where {$_.objectClass –eq
“trustedDomain”} |FL

Vous pouvez également consulter de nombreuses propriétés fondamentales


d’une approbation en exécutant la commande Get-ADTrust -Filter *.
Propriétés des approbations. Le tableau ci-dessous présente les propriétés des
approbations et une description de chaque propriété.

Chapitre IV | Forêts, Domaines, Approbations 14


Propriété d’approbation Description de la propriété

Les valeurs valides sont bidirectionnelles, entrantes ou sortantes. Remarquez que


Direction la direction dépend du domaine dans lequel vous effectuez la requête.

Il s’agit vraisemblablement d’une coquille de la part de Microsoft, il faudrait lire


DisallowTransivity « DisallowTransitivity » (Interdire la transitivité). Elle peut être définie comme True (Vrai)
ou False (Faux) selon que l’on souhaite que l’approbation interdise ou non la transitivité.

DistinguishedName Le nom unique d’un objet domaine approuvé.

Transitive dans la forêt : défini comme True (Vrai) lorsqu’une approbation de forêt
ForestTransitive
est transitive et False (Faux) lorsqu’une approbation de forêt n’est pas transitive.

Intraforêts : défini comme True (Vrai) dans le cas d’une approbation entre des
IntraForest domaines d’une même forêt et False (Faux) dans le cas d’une approbation entre des
domaines de différentes forêts.

IsTreeParent Est racine d’arborescence : les valeurs valides sont True (Vrai) et False (Faux).

IsTreeRoot Est racine d’arborescence : les valeurs valides sont True (Vrai) et False (Faux).

Le nom du domaine faisant partie de l’approbation, et non le domaine dans lequel la


Name
requête est exécutée.

ObjectClass Classe d’objets : définie comme trustedDomain (Domaine approuvé) pour les approbations.

Identificateurs globaux uniques de l’approbation. Exemple :


ObjectGUID
de207451-51ed-44cd-4248-85ad9fcb2d50.

Authentification sélective : définie comme True (Vrai) si l’approbation est configurée pour
SelectiveAuthentication
une authentification sélective ou sur False (Faux) si elle ne l’est pas.

SIDFilteringForestAware Défini comme True (Vrai) si l’approbation est configurée pour une authentification sélective.

Défini comme True (Vrai) lorsque le filtrage SID avec mise en quarantaine est utilisé
SIDFilteringQuarantined
pour une approbation. Utilisé uniquement pour les approbations externes.

Chapitre IV | Forêts, Domaines, Approbations 15


Définie comme le nom de domaine de la racine d’approbation. Dans une approbation de
Source
forêt, le nom du domaine racine de la forêt est la source.

Target Cible : définie comme le nom du domaine de l’autre côté de l’approbation.

Définie comme True (Vrai) si la délégation complète Kerberos est activée sur les
TGTDelegation
approbations de forêt sortantes. Par défaut : False (Faux).

TrustAttributes Attributs d’approbation : une valeur numérique indiquant la configuration de l’approbation.

TrustedPolicy Non renseigné

TrustingPolicy Non renseigné

Type d’approbation : défini comme Uplevel (Niveau supérieur) pour les approbations avec
des forêts et des domaines Active Directory, DownLevel (Niveau inférieur) pour les
TrustType
approbations pré-domaine Active Directory, comme les domaines NT 4, Kerberos realm
(Royaume Kerberos) pour les approbations avec des domaines Unix/Linux.

UplevelOnly Niveau supérieur uniquement : défini comme True (Vrai) si seuls les systèmes d’exploitation
Windows 2000 et ultérieurs peuvent utiliser le lien d’approbation.

UsesAESKeys Utilise les clés AES : défini comme True (Vrai) pour les approbations de royaume qui utilisent
des clés de chiffrement AES.

UsesRC4Encryption Utilise le le chiffrement RC4 : défini comme True (Vrai) pour les approbations de royaume
qui utilisent des clés de chiffrement RC4.

Du point de vue de l’évolutivité, vous devez savoir certaines choses sur


les approbations :

Nombre maximal d’approbations pour l’authentification Kerberos. Si un client


dans un domaine approuvé tente d’accéder à une ressource dans un domaine
approuvant, le client ne peut pas s’authentifier si le chemin d’approbation
comporte plus de 10 liens. Dans les environnements qui comptent un grand
nombre d’approbations et de longs chemins d’approbation, il est recommandé
de mettre en place des approbations de raccourcis pour améliorer les
performances et garantir le fonctionnement de l’authentification Kerberos.

Les performances se détériorent au-delà de 2400 approbations. Les


environnements très vastes et complexes peuvent comporter un très grand
nombre d’approbations. Au-delà de 2400 approbations, toute approbation
supplémentaire ajoutée à votre environnement peut avoir un impact significatif
sur les performances des approbations, notamment en ce qui concerne
l’authentification.

Chapitre IV | Forêts, Domaines, Approbations 16


V. Stratégie de groupe

La stratégie de groupe centralise les paramètres de configuration et de gestion


des systèmes d’exploitation, des paramètres d’ordinateur et d’utilisateur
dans un environnement donné. Bien que ces paramètres soient gérés à l’aide
d’objets de stratégie de groupe (GPO pour Group Policy Objects), ces derniers ne
peuvent pas être appliqués directement aux objets utilisateurs ou ordinateurs.
Un GPO doit être appliqué à un domaine, un site ou une unité d’organisation
(OU pour Organizational Unit). Par défaut, tous les objets se trouvant dans le
conteneur auquel le GPO a été appliqué reçoivent les paramètres de ce GPO.
Les objets et conteneurs enfants reçoivent également par héritage les
paramètres configurés, sauf en cas de blocage de l’héritage. Le blocage de
l’héritage complique les configurations et peut entraîner des résultats inattendus.
De plus, il est possible d’appliquer de force des GPO, ce qui garantit leur
application systématique, indépendamment des paramètres d’héritage. Les
paramètres appliqués de force doivent être utilisés avec prudence.

La stratégie de groupe traite les paramètres des stratégies dans l’ordre suivant :

1. Stratégie de groupe locale

2. Stratégies liées à des sites

3. Stratégies liées à des domaines

4. Stratégies liées à des OU

Toute politique configurée par deux GPO ou plus est remplacée ou modifiée
par le dernier GPO traité. Si, par exemple, une stratégie de site modifie les
paramètres système et qu’une stratégie d’OU modifie les mêmes paramètres
système, la stratégie d’OU prévaut car elle est traitée en dernier. De plus, lorsqu’une
stratégie est appliquée, les paramètres qu’elle définit ne peuvent pas être écrasés
par un GPO ultérieur, même si l’autre GPO est traité en dernier.

Les GPO qui modifient les paramètres d’ordinateur sont appliqués au démarrage
de l’ordinateur. Les paramètres concernant les utilisateurs sont appliqués au
moment où l’utilisateur se connecte. Par défaut, les GPO sont traités de manière
synchrone. Le traitement synchrone permet d’appliquer tous les paramètres
avant que l’utilisateur n’achève le processus de connexion. Il est également
possible de configurer un traitement asynchrone pour permettre
l’exécution de plusieurs opérations. Le traitement asynchrone peut toutefois
avoir des effets indésirables. Si, par exemple, une stratégie est configurée pour
supprimer les options du menu de démarrage pour un utilisateur, celui-ci peut se
connecter (et avoir accès au menu de démarrage) avant l’application de la stratégie.
Par défaut, les GPO sont également réappliqués toutes les 90 minutes, avec un
décalage aléatoire pouvant aller jusqu’à 30 minutes. Pour les contrôleurs de
domaine, les stratégies sont actualisées toutes les 5 minutes. Ces paramètres
d’actualisation peuvent être configurés via la stratégie de groupe.
Chapitre V | Stratégie de groupe 17
Si vous ne souhaitez pas attendre l’actualisation automatique d’une stratégie,
vous pouvez utiliser la commande gpupdate.exe localement, ou à distance
avec des commutateurs. La commande gpupdate.exe traite les stratégies et
n’applique que les paramètres qui ont été modifiés depuis la dernière
actualisation. De plus, d’autres commutateurs de commande permettent de
forcer l’application de tous les paramètres, de spécifier uniquement les
paramètres d’utilisateur ou d’ordinateur, de se déconnecter ou de redémarrer un
ordinateur après avoir appliqué les paramètres.

Pour résoudre un problème ou visualiser les stratégies appliquées, vous pouvez


utiliser la commande gpresult.exe. La commande gpresult.exe est également
assortie de commutateurs, ce qui vous permet de visualiser la stratégie finale
appliquée au format HTML. La commande gpresult.exe peut également être
exécutée à distance sur les ordinateurs ciblés par leur nom ou leur adresse IP.
Vous pouvez également spécifier des comptes d’utilisateur spécifiques pour
consulter les paramètres qui seraient appliqués si cet utilisateur devait se
connecter.

Chapitre V | Stratégie de groupe 18


VI. Présentation de la base
de données d’AD DS
La base de données d’Active Directory consiste en un unique fichier nommé
ntds.dit. Par défaut, celui-ci est stocké dans le dossier %SYSTEMROOT%
\NTDS. Ce dossier contient également les fichiers connexes suivants :

Edb.chk. Il s’agit d’un fichier de points de contrôle. Les fichiers de points de


contrôle servent habituellement, dans les systèmes de bases de données
transactionnelles, à garder la trace des entrées de fichiers journaux
enregistrées dans la base de données. Cela est utile en cas de plantage du
système, pour éviter de perdre des données.

Edb.log. Il existe généralement plusieurs fichiers journaux commençant par «


edb », par exemple edb0013A.log et edb0013B.log. S’ajoutant à ceux-ci, le fichier
edb.log est le fichier journal actif. Ces fichiers sont les journaux de
transactions utilisés pour enregistrer les modifications apportées à AD DS.
Toutes les modifications sont d’abord inscrites dans un journal de
transactions, puis sont rapidement enregistrées dans la base de données.

Temp.edb. Comme son nom l’indique, ce fichier est un fichier temporaire qui
assure le suivi des transactions en cours. Il est également utile lors du
compactage de la base de données.

Res1.log et res2.log ou edbres00001.jrs et edbres00002.jrs. Ces fichiers


journaux occupent chacun 10 Mo et sont utilisés lorsqu’il reste très peu
d’espace disque sur le volume système. Dans les anciennes versions de
Windows Server, les fichiers res1.log et res2.log sont utilisés. Depuis
Windows Server 2008, l’appellation « edbres » est employée, ainsi qu’une
nouvelle extension de fichier.jrs.

Chapitre VI | Présentation de la base de données d’AD DS 19


La base de données d’Active Directory s’appuie sur le moteur de base de
données Microsoft JET développé en 1992. Microsoft Access s’appuie
également sur la technologie JET. Depuis des années, des rumeurs ont
circulé selon lesquelles la base de données d’Active Directory serait
transférée vers SQL Server (des rumeurs similaires ont concerné Microsoft
Exchange) mais pour le moment, cela ne semble pas probable. J’ai entendu
dire de source indirecte que SQL avait été testé comme moteur de la base
de données d’AD DS, mais que des problèmes de performance
l’empêchaient de devenir la référence en la matière. AD DS étant une
base de données à usage unique, elle peut fonctionner efficacement avec la
technologie JET (alors que cette dernière n’est pas forcément adaptée à la
plupart des bases de données transactionnelles, qui ont souvent des usages
multiples). Microsoft a choisi d’utiliser le modèle ISAM (méthode d’accès
séquentiel indexé) pour l’indexation des données dans la base de données
d’AD DS. Pour travailler avec les données, y compris transférer des
données vers et hors de la base de données, le moteur de stockage
extensible (ESE) est utilisé. L’ESE contribue à maintenir une base de
données cohérente et donc optimale, en particulier en cas de plantage du
système. L’ESE, parfois appelé JET Blue, est utilisé par d’autres
technologies qu’Active Directory, notamment Microsoft Exchange,
BranchCache de Windows Server et Microsoft Desktop Search. Les
technologies de base de données pour Active Directory existent depuis
longtemps. Il faudrait plusieurs pages de texte pour expliquer le
fonctionnement de chacune de ces technologies.

Architecture de moteur de stockage extensible :


https://technet.microsoft.com/en- us/library/aa998171(v=exchg.65).aspx

Comment fonctionne vraiment le magasin de données d’Active Directory


(dans NTDS.dit) – un blog de Christoffer Andersson :
https://technet.microsoft.com/en- us/library/aa998171(v=exchg.65).aspx

Chapitre VI | Présentation de la base de données d’AD DS 20


VII. Réplication
La réplication d’Active Directory est la méthode de transfert et de mise à jour des
objets Active Directory d’un contrôleur de domaine à un autre. Les connexions
entre les contrôleurs de domaine sont établies en fonction de leur emplacement
dans une forêt et un site. Chaque site d’Active Directory contient un ou plusieurs
sous-réseaux, qui identifient la plage des adresses IP associées à ce site.
En établissant une correspondance entre l’adresse IP d’un contrôleur de
domaine et un sous-réseau, Active Directory sait quels contrôleurs de domaine
se trouvent dans quel site. Des connexions sont configurées entre les
différents sites pour garantir que les objets Active Directory sont répliqués d’un
site à l’autre. Pour bien fonctionner, la réplication d’Active Directory repose sur les
technologies suivantes :

DNS

Appel de procédure distante (RPC pour Remote procedure call)

SMTP (optional)

Kerberos

LDAP

La réplication d’Active Directory comporte quatre principaux composants :

Réplication à maîtres multiples. La réplication à maîtres multiples, par


opposition à la réplication à maître unique utilisée dans Windows NT 4.0,
garantit que chaque contrôleur de domaine peut recevoir des mises à jour pour
les objets sur lesquels il fait autorité. Cela assure une tolérance aux
défaillances dans un environnement Active Directory.

Réplication par réception. La réplication par réception garantit que les


contrôleurs de domaine demandent des modifications d’objets, plutôt que
les modifications soient transmises en mode Push (surtout si cela est
inutile). La réplication par réception réduit légèrement le trafic de
réplication entre les contrôleurs de domaine.

Réplication différée. La réplication différée garantit que chaque contrôleur


de domaine communique avec un sous-ensemble de contrôleurs de
domaine pour transférer les modifications apportées aux objets. En mode
Stocker et transférer, chaque contrôleur de domaine communique avec tous
les autres contrôleurs de domaine, ce qui est inefficace. La réplication différée
permet d’équilibrer la charge de réplication entre les contrôleurs de domaine
dans un environnement Active Directory.

Réplication basée sur l’état. La réplication basée sur l’état garantit que
chaque contrôleur de domaine assure le suivi de l’état d’actualisation de la
réplication, ce qui élimine les conflits et les réplications inutiles.
Chapitre VII | Réplication 21
Le KCC gère la réplication entre contrôleurs de domaine au sein d’un
même site en utilisant des connexions créées automatiquement. Le
KCC lit les données de configuration, et lit et écrit les objets de
connexion pour les contrôleurs de domaine. Le KCC utilise uniquement le
RPC pour communiquer avec le service d’annuaire.

La réplication intrasite n’utilise pas de compression, les


modifications sont envoyées immédiatement aux contrôleurs de domaine.
La réplication intersite repose sur des liens définis par l’utilisateur qui
doivent être créés. Le KCC utilise ces liens pour créer une topologie, de
manière à ce que la réplication soit gérée via les liens de site à site. Les
connexions aux sites peuvent être régulées selon un planning et les
données de réplication sont compressées pour minimiser l’utilisation de bande
passante. La durée de réplication par défaut pour les connexions de site à
site est de 180 minutes, ce qui est généralement beaucoup trop long
pour la grande majorité des organisations. Une durée minimale de 15
minutes peut être configurée dans l’interface graphique, et une durée encore
plus courte peut être obtenue en modifiant le registre. La taille d’un
paquet de réplication est calculée d’après la quantité de RAM dans le
contrôleur de domaine. Par défaut, la limite de taille des paquets est de
1/100ème de la RAM, avec un minimum de 1 Mo et un maximum de 10
Mo. De plus, le nombre maximum d’objets dans un paquet est de 1/1 000
000ème de la taille de la RAM système, avec un minimum de 100 objets
et un maximum de 1000 objets. Par conséquent, pour les serveurs
modernes disposant de plus de 1 Go de RAM, les paquets de réplication
peuvent contenir jusqu’à 10 Mo de données ou jusqu’à 1000 objets. La
taille maximale des paquets et la limite des objets peuvent être
configurées en modifiant le registre à l’emplacement suivant :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Les principaux composants de réplication sont :

Vérificateur de cohérence des données (KCC – Knowledge Consistency


Checker). Le KCC est un processus qui s’exécute sur chaque
contrôleur de domaine et communique directement avec Ntdsa.dll pour lire
et écrire les objets de réplication.

Agent de système d’annuaire (DSA – Directory System Agent). Le DSA est un


service d’annuaire qui s’exécute sous la forme Ntdsa.dll sur chaque
contrôleur de domaine. Il offre une interface permettant aux services et aux
processus de lire la base de données de l’annuaire.

Moteur de stockage extensible (ESE – Extensible Storage Engine). L’ESE


gère les enregistrements de la base de données de l’annuaire, qui peut
contenir une ou plusieurs colonnes.

Appel de procédure distante (RPC – Remote Procedure Call).


La réplication d’annuaire est communiquée via le protocole RPC. RPC
est un protocole de communication qui permet aux développeurs
d’exécuter du code sur un système local ou distant sans avoir à
développer un code spécifique pour l’exécution à distance. Le KCC utilise
également RPC pour communiquer avec les contrôleurs de domaine afin
de demander des informations lors de l’élaboration d’une topologie de
réplication.
Chapitre VII | Réplication 22
Générateur de topologie intersite (ISTG – Intersite Topology Generator).
L’ISTG gère les objets de connexion de réplication intersite entrants
pour un site spécifique. Chaque site dispose d’un serveur ISTG. Par
défaut, le premier contrôleur de domaine de chaque site est l’ISTG. Pour
trouver l’ISTG dans un site nommé HQ dans un domaine nommé
tailspintoys.com, exécutez la commande Windows PowerShell :

Get- ADObject –Identity "cn=NTDS Site Settings,


cn=HQ,cn=sites,cn=configuration,dc=tailspintoys,dc=com" -
Properties interSiteTopologyGenerator | Select
interSiteTopologyGenerator

Les objets Active Directory utilisés par le KCC et ses composants comprennent :

Sites. Les sites sont des objets Active Directory de la classe site, ils
correspondent aux sous-réseaux d’un site donné.

Sous-réseaux. Les objets sous-réseaux font partie de la classe subnet,


ils définissent le sous-réseau IP du réseau correspondant à un site.

Serveurs. Un objet serveur, dans la classe server, représente


les ordinateurs serveurs, y compris les contrôleurs de domaine. Les
objets serveurs sont traités comme des entités de sécurité, ils sont
stockés sur une partition de répertoire distincte et ont des identificateurs
globaux uniques (GUID) distincts.

Paramètres NTDS. Les objets paramètres NTDS font partie de la


classe nTDSDSA, ils représentent une instance d’Active Directory sur un
contrôleur de domaine spécifique.

Connexions. Les objets connexions font partie de la classe


nTDSConnection, ils définissent un itinéraire à sens unique entrant d’un
contrôleur de domaine source vers le contrôleur de domaine qui stocke
l’objet connexion.

Liens de sites. Les objets liens de sites font partie de la classe


siteLink, ils identifient le protocole et le planning de réplication des données
entre deux ou plusieurs sites.

Paramètres de site NTDS. Les objets paramètres de site NTDS font partie
de la classe nTDSSiteSettings et identifient les paramètres des sites
pour Active Directory. Il n’y a qu’un seul objet paramètres de site NTDS
par site dans le conteneur Sites.

Référence croisée. Les objets référence croisée appartiennent à la classe


crossRef et stockent l’emplacement des partitions Active
Directory dans le conteneur Partitions.

Chapitre VII | Réplication 23


Le diagramme ci-dessous représente un environnement Active Directory typique
à deux sites avec certains composants de réplication.

Figure 7.1
Site A Site B
Environnement Active RPC connections
Directory typique Intra-site Intra-site
Replication Replication

DC1 DC3 DC4D C5

DC2 Intersite Replication


RPC or SMTP
connections
Subnets: 192.168.20.0/23 Subnets: 192.168.30.0/23

25 cmdlets PowerShell (depuis Windows Server 2012)


permettent de gérer spécifiquement la réplication d’Active Directory.
Ces cmdlets permettent de consulter des informations sur la réplication,
de configurer les sites, de gérer les liens des sites et de forcer
la réplication. L’outil de ligne de commande RepAdmin.exe fournit
également des informations et permet de configurer la réplication
d’Active Directory. Un autre outil de réplication est Active Directory
Replication Status Tool. Il est disponible sur http://
www.microsoft.com/en-us/download/details.aspx?id=30005. Vous pouvez vous
en servir pour analyser et résoudre les problèmes de réplication d’Active
Directory.

Chapitre VII | Réplication 24


VIII. DNS et DHCP
AD DS offre une méthode intégrée de stockage et de réplication des enregistrements
DNS par le biais de zones DNS intégrées à Active Directory. Tous les enregistrements et
les données stockés dans cette zone sont répliqués vers d’autres serveurs DNS via le
service de réplication natif d’AD DS. Chaque contrôleur de domaine stocke une copie
inscriptible des données de la zone DNS pour les espaces de noms pour lesquels ils
font autorité. Les zones intégrées à Active Directory permettent également d’utiliser
des mises à jour dynamiques sécurisées, et ainsi de déterminer quels ordinateurs
peuvent effectuer des mises à jour et d’empêcher les modifications non autorisées.

Les données de la zone DNS sont stockées dans une partition du répertoire des
applications. Une partition couvrant l’ensemble de la forêt, appelée ForestDnsZones,
est utilisée pour les données de la zone. Pour chaque domaine AD DS, une partition de
domaine est créée, appelée DomainDnsZones. En général, les implémentations DNS
sont utilisées avec un espace de noms contigu. Par exemple, le nom de domaine
complet (FQDN) d’un domaine AD DS pourrait être corp.contoso.com, et le FQDN d’un
client dans ce domaine serait client.corp.contoso.com. Cependant, AD DS et les zones
DNS intégrées à Active Directory prennent en charge les espaces de noms disjoints.
Dans un tel scénario, le FQDN du domaine AD DS pourrait être na.corp.contoso.com,
tandis que le FQDN d’un client pourrait être client.corp.contoso.com. Remarquez que
la partie « na » du FQDN n’est pas présente dans le FQDN du client. Plusieurs
conditions et considérations doivent être prises en compte lors de l’utilisation d’un
espace de noms disjoint. Pour en savoir plus : https://technet.microsoft.com/en-us/
library/cc731125%28v=ws.10%29.aspx.

AD DS a besoin du DNS pour fonctionner, et l’infrastructure AD DS utilise trois


composants spécifiques :

Localisateur de contrôleur de domaine. Le localisateur est implémenté dans le


service Net Logon, il fournit les noms des contrôleurs de domaine d’un
environnement AD DS. Le localisateur utilise les enregistrements de ressources
DNS adresses (A) et services (SRV) pour identifier les contrôleurs de domaine dans
un environnement AD DS.

Noms de domaine Active Directory dans le DNS. Les noms de domaine AD DS dans
le DNS sont les FQDN dont nous avons parlé précédemment.

Objets DNS Active Directory. Alors que les domaines DNS et AD DS ont
généralement le même nom, ils sont deux objets distincts avec des rôles différents.
Le DNS stocke des zones et des données de zone requises par AD DS et répond aux
requêtes DNS des clients. AD DS stocke les noms et les enregistrements d’objets, et
utilise les requêtes LDAP pour récupérer ou modifier des données. Les zones DNS
stockées dans AD DS ont un objet conteneur dans la classe dnsZone. L’objet
dnsZone comporte un nœud DNS qui utilise la classe dnsNode. Chaque nom unique
dans une zone DNS a un objet dnsNode unique. Pour AD DS, cela inclut également
les fonctions individuelles. Par conséquent, un contrôleur de domaine peut avoir
plusieurs rôles, comme celui de serveur de catalogue global, ce qui est indiqué dans
l’objet dnsNode.
Chapitre VIII | DNS et DHCP 25
Comme nous l’avons vu précédemment, les contrôleurs de domaine sont identifiés
par les enregistrements SRV dans une zone DNS. Les composants d’AD DS sont
stockés dans le DNS dans le sous-domaine _msdcs au format suivant :
_Service.Protocol.DcType._msdsc.DnsDomainName. Par exemple, le service LDAP
(Lightweight Directory Access Protocol) du contrôleur de domaine principal (PDC) du
domaine AD DS contoso.com serait _ldap._tcp.pdc.contoso.com. Les chaînes de
service et de protocole utilisent le caractère de soulignement « _ » comme préfixe
pour éviter les collisions potentielles avec les ressources ou les enregistrements
existants dans l’espace de noms. Le service Net Logon requiert 17 enregistrements
SRV différents pour effectuer des recherches. Vous trouverez une liste complète des
enregistrements SRV à l’adresse suivante : https://technet.microsoft.com/en-us/
library/cc759550%28v=ws.10%29.aspx.

En plus des enregistrements SRV, le service Net Logon requiert également deux
enregistrements A pour les clients qui peuvent ne pas être compatibles SRV. Cela
inclut un enregistrement pour le DnsDomainName, et un enregistrement pour
gc._msdsc.DnsForestName. Cela permet aux clients non compatibles SRV de
rechercher un contrôleur de domaine ou un serveur de catalogue global en utilisant
un enregistrement A. Le DNS est vulnérable aux menaces de sécurité, comme
l’empreinte au sol, les attaques par déni de service, les modifications de données et
la redirection. Pour atténuer ces menaces, les zones DNS peuvent être protégées au
moyen de mises à jour dynamiques sécurisées, en limitant les transferts de zones, et
en appliquant la délégation de zones et les extensions de sécurité DNS (DNSSEC).
Grâce aux mises à jour dynamiques sécurisées, les ordinateurs seront authentifiés
par Active Directory et les paramètres de sécurité seront appliqués lors des
transferts de zones. De plus, les transferts de zones peuvent également être
restreints à des adresses IP spécifiques au sein du réseau. La délégation de zone
peut être abordée selon deux méthodes. La première consiste à réserver les
modifications du DNS à une seule équipe ou entité, toutes les modifications étant
suivies et approuvées. Cette méthode permet de réduire le nombre de personnes
qui apportent des modifications, mais elle offre un point de défaillance unique. Avec
la deuxième méthode, les zones peuvent être déléguées à des personnes qui
géreront chaque composant d’un réseau ou d’un domaine. Même si les
modifications doivent encore être approuvées et suivies, cela répartit les risques
entre plusieurs personnes et vise à limiter les dommages si un seul élément est
compromis. DNSSEC valide les réponses DNS en fournissant l’autorité d’origine,
l’intégrité des données et un déni d’existence authentifié. L’implémentation de
DNSSEC par Windows Server 2012 satisfait les normes RFC 4033, 4034 et 4035.

Six types d’enregistrement de ressources sont utilisés spécifiquement avec DNSSEC :

Resource record signature (RRSIG)

Next Secure (NSEC)

Next Secure 3 (NSEC3)

Next Secure 3 Parameter (NSEC3PARAM)

DNS Key (DNSKEY)

Delegation Signer (DS)

Chapitre VIII | DNS et DHCP 26


Pour en savoir plus sur chacun des types d’enregistrement et leur utilisation, voir
https://technet.microsoft.com/en-us/library/jj200221.aspx.

DHCP est un autre service réseau utilisé par Windows Server. Dans un
environnement AD DS, les serveurs DHCP doivent être autorisés avant de
pouvoir louer des adresses IP à des clients sur un réseau. Les serveurs DHCP
sont autorisés en fonction de leur adresse IP et sont vérifiés par rapport à AD DS
pour confirmer qu’ils sont autorisés à louer des adresses IP. Si un serveur DHCP
non autorisé détecte un serveur DHCP autorisé, le serveur DHCP non autorisé
cesse de louer des adresses aux clients. Dans un environnement AD DS, le
service DHCP doit être installé sur un serveur membre du domaine, sinon il ne
pourra pas être autorisé. Il est possible d’installer et d’exécuter le service DHCP
sur un serveur autonome, mais cela doit se faire sur un réseau ou un VLAN
distinct de celui de tout serveur DHCP autorisé. Pour autoriser un serveur DHCP,
l’administrateur doit être membre du groupe de sécurité intégré Administrateurs
de l’entreprise. Cependant, le droit d’autoriser un serveur DHCP peut être
délégué à d’autres administrateurs du domaine. Pour autoriser un DHCP en
utilisant son FQDN, ce dernier ne doit pas dépasser 64 caractères. Si le FQDN
comporte plus de 64 caractères, il doit être autorisé au moyen d’une adresse IP.

DHCP peut être intégré au DNS pour assurer des mises à jour dynamiques des
enregistrements PTR et A dans une zone DNS. Cette capacité permet à un
serveur DHCP de servir de proxy à tout client DHCP exécutant un système
d’exploitation qui n’actualise pas automatiquement son inscription DNS.

Dans Windows Server 2012, DHCP peut être configuré avec un basculement. Le
basculement DHCP permet de configurer le serveur DHCP en mode serveur de
secours, pour assurer une redondance, ou en mode d’équilibrage de charge,
pour répartir les baux clients entre deux serveurs DHCP. Il est possible de
changer de mode à tout moment, mais une étendue de DHCP ne permet
d’utiliser qu’un seul mode à la fois. Les adresses IPv4 louées ou réservées, y
compris les options et les paramètres de chaque étendue, sont partagées entre
deux serveurs DHCP. Un unique serveur DHCP prend en charge jusqu’à 31
relations de basculement. Les relations de basculement peuvent être réutilisées
pour des étendues supplémentaires afin d’éviter de dépasser la limite.

Lorsque le mode serveur de secours DHCP est utilisé, deux serveurs exploitent le
service DHCP, mais un seul serveur fournit toutes les requêtes DHCP et y répond.
Le serveur secondaire ne fournit des baux que si le serveur principal
est injoignable. Pour fournir des baux, une partie du pool d’adresses IP doit
être réservée au serveur secondaire. Par défaut, cette partie est définie à 5 %.
Si le serveur secondaire loue toutes les adresses IP dans l’espace réservé, il
n’émettra pas d’adresses IP supplémentaires depuis l’étendue du serveur
principal. Les baux existants sont renouvelés lorsqu’un client DHCP en fait la
demande. Par ailleurs, lorsque le serveur secondaire loue une adresse IP, la
durée de la location correspond au délai de transition maximal du client
(MCLT) et non à la durée totale de la location. Une fois le délai MCLT écoulé,
le serveur secondaire utilise l’ensemble du pool d’adresses de l’étendue, en
partant du principe que le serveur principal a repris.

Chapitre VIII | DNS et DHCP 27


L’utilisation de DHCP en mode équilibrage de charge est la méthode de
déploiement par défaut. Selon cette méthode, deux serveurs fournissent
simultanément les services DHCP pour une étendue DHCP. La méthode
d’équilibrage de charge définit un pourcentage d’adresses IP pour chaque
serveur, par défaut 50/50. Cette proportion peut être configurée à n’importe
quelle valeur entre les deux serveurs. L’équilibre de charge des serveurs DHCP
est basé sur un hachage de l’adresse MAC du client demandeur. L’adresse MAC
détermine donc quel serveur DHCP répondra à une requête DHCP d’un client.

Comme pour le mode serveur de secours, si le serveur partenaire n’est pas


disponible, le serveur restant loue et renouvelle les adresses IP pour le délai de
transition maximal du client (MCLT). Une fois ce délai écoulé, si le serveur
partenaire n’est pas connecté, le serveur restant loue les adresses de l’ensemble
du pool pour l’étendue.

Chapitre VIII | DNS et DHCP 28


IX. Sécurité

La sécurité est un thème majeur, car elle recouvre un nombre impressionnant de


domaines. Même pour une technologie aussi spécifique que la base de données AD,
la sécurité demeure un vaste sujet. Dans ce livre, nous allons nous concentrer sur
trois domaines précis de la sécurité dans AD DS :

Sécurisation du trafic LDAP avec SSL/TLS

Modification de la liste de contrôle d’accès des comptes administratifs

Mise en place d’une authentification de domaine forte

Pour sécuriser le trafic LDAP avec SSL/TLS, la première étape consiste à installer AD
CS. Il est recommandé d’installer ce rôle sur un serveur membre. Avant de mettre en
œuvre une ICP, passez du temps à recueillir des informations, à concevoir cette ICP
et à planifier. Une fois que vous disposez d’une ICP opérationnelle, vous pouvez
fournir un certificat à chaque contrôleur de domaine.

Vous pouvez également faire appel à une autorité de certification tierce pour
sécuriser les communications LDAP. La clé privée du certificat ne doit pas être
assortie d’une forte protection. De plus, le nom de domaine complet du contrôleur
de domaine doit apparaître soit dans le champ Nom commun du champ Objet, soit
comme entrée DNS dans l’extension Autre nom de l’objet. L’utilisation améliorée de
la clé doit également inclure l’authentification serveur en option, identificateur
d’objet 1.3.6.1.5.5.7.3.1. En activant LDAP sur SSL, la communication LDAP peut se
faire sur les ports 389 (LDAP) et 636 (LDAP/SSL). Les requêtes au catalogue global
sont effectuées via le port SSL 3269.

La commande certreq.exe permet de créer une nouvelle requête de certificat. Pour


créer une requête, exécutez la commande suivante :

certreq -new request.inf request.req

Le fichier request.inf doit contenir le nom de domaine complet du contrôleur


de domaine, ainsi que des informations sur la longueur de la clé et l’heure de la
requête. Pour voir un exemple complet du fichier request.inf :
http://support.microsoft.com/kb/321051. Le fichier request.req est alors créé
et doit être soumis à l’autorité de certification. Après avoir reçu le certificat,
traitez la requête avec la commande certreq.exe.

certreq -accept certnew.cer

Chapitre IX | Sécurité 29
Pour vérifier que SSL a bien été activé, l’outil d’administration d’Active Directory
ldp.exe vous permet de vous connecter manuellement à l’environnement AD DS.
Lancez l’outil ldp.exe et effectuez une nouvelle connexion. Dans le champ Port,
spécifiez 636. Si les informations RootDSE s’affichent, LDAP sur SSL a été configuré
avec succès.

Une autre façon de sécuriser AD DS consiste à modifier la liste de contrôle d’accès


des comptes d’utilisateur dotés de privilèges d’administration. Les listes de contrôle
d’accès des comptes d’utilisateur des groupes administratifs sont remplacées toutes
les heures par un processus de l’émulateur de contrôleur de domaine principal. Ce
processus compare les listes de contrôle d’accès de chaque compte des groupes
administratifs et les groupes eux-mêmes à l’objet AdminSDHolder. Dans un domaine
appelé contoso.com, l’objet se trouve à l’emplacement suivant :
CN=AdminSDHolder,CN=System,DC=Contoso,DC=Com. Toute différence entre le
compte et l’objet AdminSDHolder est alors remplacée sur le compte. Les groupes
suivants et les membres de ces groupes sont contrôlés par le processus
AdminSDHolder :

Administrateurs Opérateurs de sauvegarde Opérateurs d’impression

Opérateurs de compte Administrateurs du domaine Administrateurs du schéma

Éditeurs de certificats Administrateurs de l’entreprise Opérateurs de serveur

De plus, les comptes d’administrateur et d’utilisateur krbtgt sont également contrôlés


indépendamment de leur appartenance à un groupe. Les comptes protégés par le
processus AdminSDHolder peuvent être identifiés par l’attribut de compte
adminCount. Si le compte est protégé, cet attribut prend la valeur 1.

Pour modifier la liste de contrôle d’accès d’un compte protégé par le processus
AdminSDHolder, trois étapes doivent être accomplies pour vérifier que la liste n’est
pas remplacée.

1. Supprimez l’objet de compte de tous les groupes protégés.

2. Fixez l’attribut adminCount à 0.

3. Activez l’héritage de l’objet de compte.

Remarquez que le fait de mettre adminCount à 0 sans supprimer l’objet des groupes
protégés n’empêche pas le processus de remplacer les listes de contrôle d’accès. Le
fait de supprimer l’objet des groupes sans modifier l’attribut adminCount ne résout
pas la situation.

Une autre solution consiste à modifier l’objet AdminSDHolder de manière à inclure les
listes de contrôle d’accès que vous souhaitez appliquer aux comptes d’utilisateur. Si
vous incluez les entrées de contrôle d’accès supplémentaires dans l’objet
AdminSDHolder, celles-ci seront également incluses lorsque les listes de contrôle
d’accès de chaque objet de compte seront comparées. Ceci est utile pour modifier les
autorisations de tous les objets des comptes utilisateur d’administration.

Chapitre IX | Sécurité 30
Un autre aspect de la sécurité d’AD DS consiste à instaurer une authentification
de domaine forte dans votre environnement. Ainsi, les utilisateurs
pourront s’authentifier auprès d’Active Directory en utilisant uniquement des
protocoles d’authentification solides. Par défaut, Windows Server 2012 accepte
les requêtes d’authentification basées sur NTLM et NTLMv2, mais ne répond
qu’avec NTLMv2. Ce paramètre peut être restreint en modifiant le paramètre «
Network Security: LAM Manager Authentication Level » (Sécurité réseau :
niveau d’authentification Gestionnaire de compte LDAP) dans la stratégie de
groupe. Ce paramètre s’applique aux contrôleurs de domaine et peut être réglé
sur « Send NTLMv2 response only. Refuse LM and NTLM » (Envoyer une réponse
NTLMv2 uniquement. Refuser LM et NTLM). En configurant ainsi ce paramètre, les
contrôleurs de domaine ne répondront pas, à moins de recevoir une requête
NTLMv2.

Chapitre IX | Sécurité 31
X. Audit
Avant Windows Server 2008 R2 et Windows 7, les audits sous Windows étaient assez
simples. Il suffisait de naviguer vers les politiques d’audit d’un objet de stratégie de
groupe, d’activer l’audit et de choisir Réussite, Échec, ou les deux. Plusieurs articles
publiés sur Internet décrivaient chacune des politiques d’audit et de nombreux
administrateurs ont tôt fait d’éviter tout ce qui n’apportait pas beaucoup de valeur.
La capture d’écran ci-dessous montre les paramètres de politique d’audit
disponibles.
Figure 10.1
Audit policy settings

Dans Windows Server 2008 R2, une nouvelle fonctionnalité permettant de mettre en
place des stratégies d’audit avancées dans la stratégie de groupe a été introduite.
Officiellement, 53 nouveaux paramètres de politique ont été proposés pour
remplacer les neuf paramètres initiaux présentés ci-dessus. Peu de gens savent que
ces 53 nouveaux paramètres étaient en fait disponibles dans Windows Server 2008.
Toutefois, pour tirer parti des nouveaux paramètres, il fallait utiliser des scripts de
connexion et auditpol.exe. Par conséquent, la plupart des administrateurs ne s’en
servaient pas.

Un aspect crée souvent de la confusion : le chevauchement apparent des neuf


paramètres de politique initiaux (que nous appellerons les paramètres élémentaires
de politique d’audit) et des paramètres avancés de politique d’audit. En fait, il n’y a
pas de chevauchement. Voyons pourquoi en examinant l’audit de gestion des
comptes. Avec les paramètres élémentaires de politique d’audit, vous pouvez activer
la politique « Audit account management » (Auditer la gestion des comptes) avec les
options Success (Réussite) et Failure (Échec). Avec la politique d’audit avancée, vous
pouvez activer l’audit pour la gestion des groupes d’applications, la gestion des
comptes d’ordinateur, la gestion des groupes de distribution, les événements de
gestion des comptes, la gestion des groupes de sécurité et la gestion des comptes
d’utilisateur. Le fait d’activer la configuration élémentaire de politique d’audit « Audit
account management » (Auditer la gestion des comptes) équivaut à activer l’audit
pour les six sous-catégories disponibles dans une politique d’audit avancée. Aucune
d’entre elles ne fournit plus de données que l’autre. Mais, comme beaucoup
d’administrateurs l’ont compris, générer trop de données d’audit peut être pire que
de ne pas en générer du tout, en raison de l’énorme volume de données potentiel.
Les administrateurs se débattent depuis longtemps avec les données d’audit. Voici
quelques-unes des difficultés les plus courantes :
Chapitre X | Audit 32
Saturation des journaux d’événements Windows. Les journaux d’événements
Windows peuvent être configurés de différentes manières. Vous pouvez définir une
taille maximale pour les journaux et supprimer les anciens événements selon les
besoins. Vous pouvez archiver un journal lorsqu’il se remplit, puis en commencer
un nouveau. Vous pouvez également configurer les journaux de manière à ce que
les événements ne soient pas écrasés, mais qu’une intervention manuelle soit
nécessaire. Vous pouvez même faire en sorte que le serveur s’arrête s’il n’est plus
possible d’écrire dans le journal des événements de sécurité. Les administrateurs
ne peuvent généralement pas se permettre que de nouveaux événements ne
soient pas enregistrés ou que des serveurs s’arrêtent lorsqu’un journal se remplit.
De ce fait, l’écrasement des événements ou l’archivage sont les options les plus
courantes. Mais cela entraîne des contraintes administratives : il faut surveiller la
taille des journaux d’événements, surveiller l’espace disque, déplacer les journaux
archivés hors du serveur, gérer les journaux archivés et trouver un moyen de
rechercher parmi toutes ces données.

Manque d’espace disponible sur les disques. Je n’en reviens toujours pas
qu’aujourd’hui, dans de nombreuses entreprises, le manque d’espace disque reste
la principale source d’indisponibilité des serveurs. Les fichiers journaux posent
fréquemment problème, qu’il s’agisse d’audits ou d’applications telles que IIS. J’ai
entendu parler de plusieurs organisations victimes d’une panne dont la cause
profonde était le manque d’espace du système dû à l’archivage du journal des
événements Windows.

Incapacité de trouver des données d’audit spécifiques. Lorsque vous générez une
grande quantité de données, toutes les tâches de gestion des données, même les
plus simples, deviennent complexes et chronophages. Des tâches telles que la
compression des fichiers, la copie de fichiers vers un autre emplacement via le
réseau ou la recherche d’un terme clé spécifique dans les fichiers deviennent
problématiques et prennent beaucoup de temps. Les administrateurs se tournent
donc vers des solutions tierces pour obtenir de l’aide.

Incapacité d’utiliser les données d’audit en temps utile. Imaginez que l’équipe de
sécurité vous appelle au sujet d’un employé qui pourrait avoir consulté des
données RH confidentielles. Ils vous demandent d’extraire les données d’audit de
cet utilisateur pour les dernières semaines. Ce n’est pas trop difficile si vous avez 1
Go de données d’audit. Mais si vous en avez 500 Go, cela devient soudain votre
travail à plein temps pour les prochaines semaines.

Les paramètres avancés de politique d’audit peuvent vous être utiles. Grâce à des
options d’audit plus granulaires, vous pouvez réduire considérablement la quantité de
données recueillies. Cela minimise les difficultés évoquées précédemment. Mais le
passage aux paramètres avancés de politique d’audit représente un gros
investissement en temps. Dans certaines organisations, cet investissement est
rentable.

Chapitre X | Audit 33
Voyons rapidement comment cela influe sur le nombre d’événements capturés.
Dans ce premier exemple, dans un domaine Windows Server 2003 R2 nommé
adatum.com, j’ai défini les paramètres d’audit élémentaires de manière à ce que
seuls les événements réussis de gestion des comptes soient audités, comme indiqué
ci-dessous. La version du système d’exploitation est sans importance car les
paramètres d’audit élémentaires indiqués ci-dessous sont disponibles dans toutes
les versions de Windows Server depuis Windows 2000 Server.

Figure 10.2
Basic audit settings

J’ai ensuite créé un nouvel objet ordinateur et rafraîchi le journal des événements de
sécurité. Voici ci-dessous les entrées relatives à la création du nouvel objet
ordinateur.

Figure 10.3
Entries related to the new
computer object creation

Il y a 5 événements. Ensuite, dans un domaine Windows Server 2012 R2 nommé


contoso.com, j’ai créé une politique d’audit avancée visant à n’auditer que les
événements de gestion des comptes utilisateurs réussis, comme indiqué ci-dessous.

Figure 10.4
An advanced audit policy

J’ai ensuite créé un nouvel objet ordinateur et rafraîchi le journal des événements de
sécurité. Voici ci-dessous les entrées relatives à la création du nouvel objet ordinateur.

Figure 10.5
Entries related to the new
computer object creation

Chapter IV | Audit 34
Avec la politique d’audit avancée, seuls 2 événements ont été enregistrés.
Cela représente une grande différence, et imaginez à quel point ceci peut être
extrapolé lorsque toutes les catégories d’audit auront été configurées.
Remarquez que non seulement nous gagnons du temps avec l’approche
granulaire, mais nous en gagnerons encore plus une fois les autres catégories
d’audit configurées. Vous vous demandez peut-être pourquoi la création d’un
compte d’ordinateur apparaît dans l’audit des comptes d’utilisateur ?
Réponse : parce que les objets ordinateur font partie de la classe utilisateur
d’AD DS, avec les objets utilisateur ! Vous vous demandez aussi pourquoi
les ID des journaux d’événements sont différents pour chaque
environnement ? Ceci n’est pas lié à la configuration de l’audit, mais plutôt à une
modification des ID des journaux d’événements utilisés dans Windows Server
2008 et les versions plus récentes. De nombreux ID d’événements ont été
modifiés entre les différentes versions de Windows Server.

Chapitre X | Audit 35
Données de journalisation
peu conviviales
Effet secondaire des audits et de la journalisation, les administrateurs doivent traiter
une montagne de données et d’informations. Souvent, non seulement ces
informations sont surabondantes, mais en plus, elles sont difficilement utilisables.
Voici quelques-uns des obstacles auxquels se heurtent les administrateurs lorsqu’il
s’agit d’auditer et de journaliser les données :

Les informations ne sont pas formatées. Les informations sont enregistrées,


mais elles ne sont pas formatées. Autrement dit, tout se ressemble et il peut être
difficile d’extraire les informations essentielles dont vous avez besoin. Les
administrateurs ont alors du mal à travailler avec les données : le filtrage, le tri, la
manipulation et l’extraction se font au prix de longues heures de tâches
d’administration.

Les informations sont surabondantes. Il y a trop d’informations. Prenons


l’exemple d’un utilisateur qui se connecte à son ordinateur le matin. Au lieu d’une
entrée unique dans le journal des événements, vous vous retrouvez avec
plusieurs entrées, chacune couvrant une partie de l’ensemble du processus de
connexion. Un autre exemple est la capture de paquets. Vous êtes par exemple
en train de résoudre un problème d’authentification sur un contrôleur de
domaine, mais votre capture de paquets contient des quantités d’autres données
non pertinentes. Dans certains cas, les administrateurs peuvent recourir à des
outils qui leur permettent de créer des filtres pour minimiser la capture de
données. Mais ce n’est pas très efficace pour capturer de manière continue les
données liées à la sécurité de Windows.

Les informations ne sont pas corrélées. Imaginons par exemple un scénario dans
lequel vous cherchez à résoudre un problème d’authentification d’un partenaire
fédéré. Vous disposez d’informations dans les journaux d’événements Windows
du contrôleur de domaine, dans les journaux d’événements Windows des
serveurs AD FS, dans les journaux d’événements Windows du serveur Web cible,
dans les journaux d’événements Windows de l’ordinateur client, dans les
journaux proxy AD FS, dans les journaux spécifiques AD FS et dans les journaux
IIS. La mauvaise nouvelle, c’est qu’il n’y a pas de corrélation entre les journaux, à
part la date et l’heure. Les outils intégrés de Windows n’offrent pas de solution
satisfaisante à ce problème de corrélation des événements, si bien que les
administrateurs utilisent souvent des outils tiers.

Les informations sont ignorées. Après avoir passé un temps considérable à


traiter des informations non formatées, surabondantes et non corrélées, les
administrateurs commencent souvent à ignorer les journaux, les alertes et les
informations importantes qui sont peut-être enfouies « là quelque part ». Le
même phénomène est souvent observé dans le cadre de projets de surveillance,
lorsque les alertes sont si nombreuses que personne n’y prête attention.

Chapitre XI | Données de journalisation peu conviviales 36


Une partie de la solution à ce problème consiste à réduire la quantité
d’informations que vous capturez. Mais cela va parfois à l’encontre de ce que le
service de sécurité souhaite que l’entreprise capture : tout. Il s’agit donc de trouver
un équilibre. Vous devez capturer suffisamment d’informations pour qu’elles
soient utiles, sans pour autant qu’elles ne deviennent un fardeau. Les
administrateurs recourent souvent à des outils tiers pour parvenir à la bonne
solution.

Chapter IV | Données de journalisation peu conviviales 37


Références utiles
Les ressources suivantes vous aideront à améliorer la gestion et la sécurité
d’Active Directory :

Article de blog | Les sept défis les plus importants avec Active Directory
Gestion
Article de blog | Gestion d’Active Directory : Top 7 des erreurs courantes

Article de blog | Comment créer, supprimer, renommer, désactiver et associer des

ordinateurs dans AD à l'aide de PowerShell

Article de blog | Comment ajouter et supprimer des groupes AD avec PowerShell

Article de blog | Gérer les UOs et déplacer leurs Objets avec PowerShell

Bonnes pratiques | Bonnes pratiques de gestion des groupes Active Directory

Bonnes pratiques | Bonnes pratiques de stratégie de groupe

Guide pratique | How to Monitor User Logons in a Domain


Surveillance
Guide pratique | How to Monitor Active Directory Group Membership Changes

Guide pratique | How to Detect Changes to Organizational Units and Groups in AD

Guide pratique | How to Detect User Account Changes in Active Directory

Guide pratique | How to Detect Password Changes in Active Directory

Podcast | Active Directory Security 101, Episode 1: Listen and Learn


Sécurisation
Article de blog | Privileged Access Management to Secure a Compromised AD Forest

Article de blog | Protection d’Active Directory

Article de blog | 3 Ways to Secure Service Accounts in Active Directory

Bonnes pratiques | Bonnes pratiques de délégation des autorisations d’Active Directory

38
Bénéficiez d’une visibilité totale sur ce qui
se passe dans votre Active Directory et
votre stratégie de groupe

Avec Netwrix Auditor for Active Directory

Regarder la présentation de Netwrix Auditor

Télécharger un essai

33
À propos de l’auteur
Brian Svidergol est spécialisé dans l’infrastructure Microsoft et les solutions Cloud
liées à Windows, Active Directory, Exchange, System Center, la virtualisation et
MDOP. Il a obtenu de nombreuses certifications, notamment MCITP, MCSE, RHEL3,
VCP, NCIE-SAN, MCT, MCSA. Il est Expert en solutions certifié par Microsoft pour
l’infrastructure des serveurs. Brian est l’auteur du cours Microsoft Official
Curriculum (MOC) 6426C - Configuring and Troubleshooting Identity and Access
Solutions with Windows Server 2008 Active Directory (Configuration et dépannage
des solutions de gestion des identités et des accès avec Windows Server 2008
Active Directory). Il a travaillé pendant plusieurs années à l’élaboration de l’examen
de certification Microsoft et des contenus de formation associés. Il est également
co-auteur de l’Active Directory Cookbook.

Netwrix est un éditeur de logiciels qui permet aux professionnels de la sécurité et


de la gouvernance de l’information de reprendre le contrôle des données
sensibles, réglementées et stratégiques, quel que soit leur emplacement. Plus de
10 000 organisations du monde entier s’appuient sur les solutions Netwrix pour
sécuriser leurs données sensibles, tirer pleinement parti des contenus d’entreprise,
réussir les audits de conformité en déployant moins d’efforts et en dépensant
moins et améliorer la productivité de leurs équipes informatiques et de leurs
travailleurs du savoir.

Fondée en 2006, Netwrix a obtenu plus de 150 distinctions sectorielles et a été


sélectionnée dans les listes Inc. 5000 et Deloitte Technology Fast 500, qui recensent
les entreprises à la croissance la plus rapide aux États-Unis.

Pour plus d’informations, visitez www.netwrix.fr

Nous contacter Siège social Téléphones netwrix.com/social

300 Spectrum Center France : +33 9 75 18 11 19

Drive Suite 200 Gratuit : 888-638-9749

Irvine, CA 92618 EMEA : +44 (0) 203 588 3023


34

Vous aimerez peut-être aussi