Microsoft AZ-801: Sécurité des services de domaine Active Directory — Guide d'étude

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les services de domaine Active Directory (AD DS) constituent le fondement de l’identité et de l’accès sur les réseaux Windows. La sécurisation d’AD DS implique de contrôler la manière dont les informations d’identification sont créées, stockées et utilisées ; de restreindre les endroits où les identités à privilèges peuvent s’authentifier ; de renforcer les protocoles d’authentification ; d’auditer les actions à haute valeur ; et d’assurer une récupération fiable. Cette section couvre les stratégies de mot de passe et de compte affinées, les protections des identités à privilèges, le renforcement et la délégation de l’authentification, l’audit et les SACL, la corbeille, la signature LDAP et la liaison de canal (channel binding), le comportement d’AdminSDHolder, la sauvegarde et les restaurations faisant autorité, y compris la récupération de SYSVOL, ainsi que le modèle de hiérarchisation AD.

Stratégies d’identification et contrôles des identités à privilèges

Les stratégies de mot de passe affinées (PSO) permettent d’appliquer plusieurs stratégies de mot de passe et de verrouillage de compte dans un même domaine, sans avoir besoin de domaines supplémentaires. Les PSO sont des objets msDS-PasswordSettings stockés dans CN=Password Settings Container,CN=System,<domain DN> (le conteneur msDS-PasswordSettingsContainer). Une PSO s’applique aux utilisateurs et aux groupes de sécurité globaux via l’attribut msDS-PSOAppliesTo. Lorsqu’un utilisateur est concerné par plusieurs PSO applicables (directement ou via des groupes), la PSO résultante est celle qui a la plus faible valeur de msDS-PasswordSettingsPrecedence ; en cas d’égalité, la PSO avec le GUID le plus bas l’emporte. La PSO effective de l’utilisateur est inscrite dans l’attribut msDS-ResultantPSO. Concevez les PSO de manière à ce que les numéros de précédence les plus bas correspondent aux stratégies les plus restrictives que vous souhaitez voir appliquées, et validez les stratégies effectives en lisant l’attribut msDS-ResultantPSO.

Le groupe de sécurité Protected Users renforce les comptes à haute valeur en supprimant les comportements d’authentification hérités et risqués. Ses membres :

Ne peuvent pas utiliser NTLM, Digest ou CredSSP
Se voient refuser RC4 et DES pour Kerberos
Ne peuvent pas être délégués via Kerberos (délégation non contrainte ou contrainte)
Reçoivent des TGT non renouvelables avec une durée de vie courte et fixe (4 heures par défaut)
Ne mettent pas en cache les informations d’identification en texte clair ou les secrets à long terme sur le poste de travail (ce qui empêche le recours à WDigest et la persistance de matériel d’identification dans LSASS) Utilisez ce groupe pour les identités à privilèges gérées par des humains et les propriétaires de services à haut risque après avoir validé la compatibilité des applications. Les contrôleurs de domaine doivent exécuter Windows Server 2012 R2 ou une version ultérieure pour appliquer ces protections.

Les stratégies d’authentification et les silos de stratégie d’authentification restreignent où et comment les comptes peuvent s’authentifier. Une stratégie d’authentification peut définir des contraintes Kerberos par compte, telles que la durée de vie des TGT et les appareils autorisés (par SPN/FQDN de l’hôte). Un silo de stratégie d’authentification regroupe des utilisateurs, des ordinateurs et des comptes de service afin que seules les combinaisons autorisées puissent s’authentifier en utilisant Kerberos, contraint par cette stratégie. Cela met en œuvre des contrôles de type « station-à-admin » : par exemple, les administrateurs de Niveau 0 (Tier 0) ne peuvent se connecter que sur les contrôleurs de domaine et les stations de travail à accès privilégié (PAW) désignées, mais pas sur les serveurs membres ou les postes de travail. Combinez-les avec le groupe Protected Users pour un effet maximal. Ces fonctionnalités nécessitent des contrôleurs de domaine Windows Server 2012 R2 et le blindage du KDC (KDC armoring).

AdminSDHolder et SDProp protègent les ACL des identités à privilèges. Les membres des groupes d’administration intégrés (par exemple, Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators, et autres) sont « protégés ». SDProp s’exécute toutes les heures sur l’émulateur PDC, copiant l’ACL de CN=AdminSDHolder,CN=System sur les objets protégés, et il désactive l’héritage des ACL sur eux (AdminCount=1). Pour accorder des droits de support technique (helpdesk) sur des objets protégés, modifiez l’ACL sur AdminSDHolder — jamais directement sur les objets protégés individuels — sinon la modification sera annulée. Lorsqu’un compte est retiré de tous les groupes protégés, réactivez l’héritage des ACL et effacez la valeur d’AdminCount afin que les ACL et les GPO au niveau de l’UO (OU) s’appliquent à nouveau.

Adoptez un modèle de hiérarchisation AD (tiering model) pour minimiser l’exposition des informations d’identification. Le Niveau 0 (Tier 0) contient les contrôleurs de domaine, les systèmes d’identité (PKI, fédération, PAM) et les comptes administrateurs qui les gèrent. Le Niveau 1 (Tier 1) contient les charges de travail des serveurs et leurs administrateurs. Le Niveau 2 (Tier 2) contient les postes de travail et leurs administrateurs. Empêchez la connexion entre les niveaux, utilisez des PAW pour l’administration des Niveaux 0 et 1, et isolez les informations d’identification à l’aide de fonctionnalités telles que Protected Users, les silos d’authentification, Remote Credential Guard, Just-Enough Administration (JEA) et Windows LAPS pour la rotation des mots de passe d’administrateur local.

Renforcement de l’authentification et délégation

La signature LDAP et la liaison de canal (channel binding) protègent contre les attaques par relais et de l’homme du milieu (man-in-the-middle). Configurez les contrôleurs de domaine pour exiger la signature via une stratégie de groupe (Group Policy) : Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\“Domain controller: LDAP server signing requirements” = Require signing. Exigez la signature du client lorsque cela est possible : “Network security: LDAP client signing requirements” = Require signing. Pour LDAPS, activez la liaison de canal sur les DC en définissant LDAPEnforceChannelBinding sous HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters à 1 (Enabled, recommandé) ou 2 (Always). Inventoriez les appareils et applications hérités ; l’activation de la signature ou de la liaison de canal peut interrompre les liaisons anonymes/simples ou les anciennes piles LDAP. Surveillez le journal d’événements Directory Service : 2886 (signature non requise), 2887 (résumé des liaisons simples non signées), 2888 (signature toujours désactivée), 2889 (IP des clients effectuant des liaisons simples non signées lorsque la journalisation de diagnostic est activée). Déployez les changements en mode « Avertir » (Warn, channel binding=1) avant d’appliquer le mode « Toujours » (Always, 2).

La délégation Kerberos contrôle la manière dont les services agissent au nom des utilisateurs :

La délégation non contrainte (“Trust this computer for delegation to any service (Kerberos only)”) permet à un service de recevoir un TGT transférable et d’usurper l’identité des utilisateurs auprès de n’importe quel service. Ceci présente un risque élevé ; à éviter au profit des modèles contraints.
La délégation contrainte (KCD) (“Trust this computer for delegation to specified services only”) limite les services auxquels un service peut déléguer (liste de SPN cibles). Avec “Use any authentication protocol,” le service peut utiliser la transition de protocole (S4U2Self) puis S4U2Proxy pour atteindre les backends spécifiés.
La délégation contrainte basée sur les ressources (RBCD) transfère le contrôle à la ressource en définissant msDS-AllowedToActOnBehalfOfOtherIdentity sur le compte de service cible. Le propriétaire de la ressource accorde aux principaux front-end le droit de déléguer vers elle, simplifiant les scénarios inter-domaines et minimisant la surface d’attaque. Préférez la RBCD pour les conceptions modernes ; auditez et vérifiez périodiquement les SPN et les paramètres de délégation.

Audit et résilience

L’audit d’AD DS doit être délibéré et spécifique. Utilisez la configuration de stratégie d’audit avancée (Advanced Audit Policy Configuration) pour activer des sous-catégories plutôt que les catégories héritées, et définissez “Audit: Force audit policy subcategory settings to override audit policy category settings” pour garantir la cohérence. Les sous-catégories recommandées incluent la gestion des comptes (Account Management), l’ouverture/fermeture de session (Logon/Logoff : Logon, Logoff, Special Logon), l’ouverture de session de compte (Account Logon : Kerberos Authentication Service/Service Ticket Operations), et les modifications/accès au service d’annuaire (Directory Service Changes/Access). ID d’événements clés :

4720 (Un compte d’utilisateur a été créé) de Account Management
4740 (Un compte d’utilisateur a été verrouillé) de Account Management
4625 (Échec de l’ouverture de session d’un compte) de Logon/Logoff
4648 (Une tentative d’ouverture de session a été effectuée à l’aide d’informations d’identification explicites) de Logon/Logoff Complétez avec les modifications du service d’annuaire (Directory Service Changes) pour capturer les valeurs qui/quoi/anciennes/nouvelles pour les attributs critiques (événements 5136/5137/5139). Pour auditer des changements spécifiques (par ex., appartenance à un groupe, SPN, ACL), configurez des SACL sur les objets ou les OU ciblés (activez Advanced Features dans ADUC, ouvrez l’objet Security > Advanced > Auditing). Ajoutez des entrées pour auditer “Write all properties” ou des propriétés spécifiques (member, servicePrincipalName), et “Modify permissions/owner” selon les besoins. Validez que les journaux parviennent à un SIEM central et que les journaux de sécurité des DC ont une rétention suffisante.

La corbeille AD DS protège contre les suppressions accidentelles en préservant tous les attributs et les backlinks des objets supprimés. Activez-la une fois par forêt (irréversible) via ADAC ou PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forêt>). Après activation, un objet supprimé reste dans un état « objet supprimé » pendant la durée de vie msDS-DeletedObjectLifetime (si non définie, la valeur par défaut est tombstoneLifetime), pendant lequel il peut être entièrement restauré avec ses attributs intacts. Après cela, il devient un objet recyclé et n’est plus restaurable avec ses attributs, puis il est récupéré par le ramasse-miettes (garbage collection). Les forêts modernes ont généralement une valeur par défaut de 180 jours pour tombstoneLifetime ; les forêts plus anciennes peuvent avoir 60 jours. Restaurez avec ADAC, LDP ou PowerShell (Restore-ADObject), et préférez la récupération faisant autorité de l’appartenance aux groupes via la corbeille plutôt que les réajouts manuels pour éviter la dérive des privilèges.

Les sauvegardes et la restauration faisant autorité sont les protections de dernier recours. Effectuez des sauvegardes fréquentes de l’état du système (System State) de chaque contrôleur de domaine à l’aide de Windows Server Backup ou de wbadmin (wbadmin start systemstatebackup). Pour les restaurations au niveau de l’objet au-delà de la corbeille, effectuez une restauration ne faisant pas autorité de l’état du système, puis utilisez ntdsutil pour marquer des objets ou des OU spécifiques comme faisant autorité (augmentant leur version pour que la réplication les réapplique). Comprenez la différence : une restauration ne faisant pas autorité ramène le DC à son état antérieur puis applique la réplication actuelle ; une restauration faisant autorité marque un objet pour que la version restaurée écrase les réplicas plus récents. Pour SYSVOL utilisant la réplication DFS (DFSR), effectuez une récupération faisant autorité ou non :

Ne faisant pas autorité : Arrêtez le service DFSR, définissez l’abonnement SYSVOL du membre affecté comme ne faisant pas autorité (msDFSR-Options=0), démarrez DFSR afin qu’il se réhydrate à partir d’un partenaire en amont.
Faisant autorité : Sur le DC sain choisi, définissez l’abonnement SYSVOL msDFSR-Options=1 (faisant autorité), démarrez DFSR, puis forcez les partenaires à se resynchroniser (DFSRDIAG PollAD). Validez la santé avec le backlog de dfsrdiag et les journaux d’événements. Pour l’ancien FRS (non pris en charge), migrez vers DFSR et évitez les procédures BurFlags.

Mise en pratique : Opérations, priorités de renforcement et accès à plusieurs niveaux

Donnez la priorité au Tier 0 en premier lieu : appliquez la signature/liaison de canal LDAP, supprimez la délégation non contrainte, passez à KCD/RBCD, placez les identités privilégiées dans le groupe Protected Users et attachez des stratégies/silos d’authentification pour restreindre les points de terminaison de connexion, et exigez des PAW pour les administrateurs de Tier 0/1. Établissez des PSO pour les comptes à privilèges avec un verrouillage et une rotation stricts. Activez l’audit avancé avec des SACL sur les conteneurs de Tier 0. Assurez des sauvegardes quotidiennes de l’état du système (System State) des contrôleurs de domaine et des guides opératoires (runbooks) documentés pour la restauration faisant autorité et la récupération de SYSVOL. Dans les Tiers 1/2, bloquez la connexion des administrateurs aux niveaux inférieurs, supprimez la réutilisation des comptes administrateurs locaux avec Windows LAPS et surveillez les pics d’événements 4625/4740 et l’utilisation abusive de l’événement 4648 pour détecter les tentatives de mouvement latéral.

Scénario de problème pratique

Adobe doit sécuriser rapidement une forêt AD DS sur site après l’acquisition d’une filiale dont les applications métier dépendent de protocoles hérités. Les objectifs sont de réduire le succès des attaques par pulvérisation de mots de passe (password spraying), d’arrêter le relais d’informations d’identification vers les contrôleurs de domaine, de restreindre les connexions à privilèges aux PAW, de moderniser la délégation pour un niveau web et d’assurer une récupération rapide après des suppressions accidentelles.

Définir des PSO et les attribuer aux groupes à privilèges

Créez un PSO strict (valeur de précédence faible) dans msDS-PasswordSettingsContainer avec une durée de vie de mot de passe courte, une complexité élevée et un verrouillage agressif.
Appliquez-le via msDS-PSOAppliesTo aux groupes « Domain Admins », « Server Admins » et à un groupe personnalisé « Tier0‑Privs ». Pourquoi : Les PSO affinés (Fine-grained) ne ciblent que les comptes à haut risque sans perturber l’ensemble du domaine, et la précédence garantit que la stratégie la plus stricte l’emporte.

Appliquer le groupe Protected Users et les silos d’authentification

Ajoutez les administrateurs humains du Tier 0 au groupe Protected Users.
Créez une stratégie d’authentification autorisant la connexion Kerberos uniquement à partir des SPN d’hôtes PAW et des contrôleurs de domaine ; liez les comptes et les PAW dans un silo de stratégie d’authentification. Pourquoi : Le groupe Protected Users élimine NTLM/RC4 et empêche la délégation ; les silos appliquent la règle « uniquement depuis les PAW », réduisant l’exposition des jetons et les chemins de vol d’informations d’identification.

Renforcer LDAP et surveiller les interruptions

Réglez « Contrôleur de domaine : exigences de signature du serveur LDAP » sur Exiger ; configurez initialement LDAPEnforceChannelBinding=1.
Examinez les événements 2886 à 2889 du service d’annuaire pour identifier les liaisons héritées ; corrigez les applications, puis réglez LDAPEnforceChannelBinding=2. Pourquoi : La signature et la liaison de canal (channel binding) éliminent les chemins de relais courants vers les contrôleurs de domaine, tandis que l’application par étapes évite les pannes.

Migrer la délégation vers RBCD pour le niveau web

Convertissez les serveurs web front-end de la délégation non contrainte à RBCD en ajoutant leurs comptes d’ordinateur à l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity du compte de service de l’API back-end.
Supprimez les indicateurs hérités « Approuver cet ordinateur pour la délégation à n’importe quel service » ; définissez les SPN de service avec précision. Pourquoi : RBCD permet à la ressource de dicter qui peut déléguer vers elle et limite l’usurpation d’identité aux cibles prévues, réduisant ainsi les possibilités de mouvement latéral.

Activer l’audit avancé et les SACL

Configurez la stratégie d’audit avancée pour la gestion des comptes, l’ouverture/fermeture de session, la connexion au compte et les modifications du service d’annuaire.
Sur les UO de Tier 0 et les groupes clés, ajoutez des SACL auditant l’écriture (Write) sur les attributs member et servicePrincipalName, ainsi que les modifications d’autorisations/propriétaire.
Transférez les journaux vers un SIEM ; alertez sur les anomalies des événements 4720, 4740, 4625 et 4648. Pourquoi : Vous ne pouvez pas défendre ce que vous ne pouvez pas voir ; ces événements exposent la création de comptes, les verrouillages, les échecs de connexion et les schémas d’utilisation explicite des informations d’identification.

Activer la corbeille AD DS et finaliser les guides opératoires de récupération

Activez la corbeille au niveau de la forêt et documentez les flux de travail Restore-ADObject.
Standardisez les sauvegardes quotidiennes de l’état du système (System State) des contrôleurs de domaine avec la Sauvegarde Windows Server, testez la restauration faisant autorité via ntdsutil dans un laboratoire.
Documentez et répétez la récupération faisant autorité et ne faisant pas autorité de SYSVOL avec DFSR. Pourquoi : Une récupération rapide et précise dissuade les actions destructrices des attaquants et atténue les erreurs des administrateurs sans dérive des privilèges.

Mettre en œuvre le modèle de Tiers AD de manière opérationnelle

Définissez les ressources des Tiers 0/1/2 ; restreignez les connexions des administrateurs par niveau à l’aide de stratégies de groupe et de silos d’authentification.
Déployez des PAW pour les Tiers 0/1, appliquez Remote Credential Guard et effectuez la rotation des mots de passe des administrateurs locaux avec Windows LAPS. Pourquoi : Le modèle de Tiers assure l’isolement des informations d’identification et arrête l’escalade des privilèges par un attaquant entre les couches, en alignant les opérations quotidiennes sur les frontières de sécurité.

← Microsoft Sentinel et surveillance de la sécurité · Tous les domaines · Azure Arc et gestion des serveurs hybrides →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →