Protection contre la suppression accidentelle : vérifier les OU AD

Ce que fait la protection contre la suppression accidentelle des OU AD

La protection contre la suppression accidentelle des OU AD est une garantie à examiner avant de nettoyer l'annuaire. Une unité d'organisation peut contenir des identités et s'inscrire dans une hiérarchie administrative dont dépendent d'autres équipes. Avant de supprimer ou de réorganiser cette hiérarchie, déterminez quelles OU doivent être conservées, qui porte la décision et si les permissions réelles de l'annuaire assurent la protection attendue.

La référence Set-ADOrganizationalUnit de Microsoft décrit ProtectedFromAccidentalDeletion comme une propriété booléenne : lorsqu'elle vaut true, l'objet ne peut pas être supprimé sans modifier cette propriété. Il s'agit d'une garantie fondée sur les permissions, plutôt que d'un verrou immuable. Les administrateurs capables de retirer la protection doivent toujours disposer d'une décision opérationnelle revue.

Ce guide pratique a été relu le 4 octobre 2026 à partir de Microsoft Learn et du code source du collecteur identifié ci-dessous. Toutes les commandes sont des exemples documentaires destinés au lecteur, et non des opérations exécutées sur le domaine d'un client. Aucune suppression, restauration ni vérification réussie de la protection n'est revendiquée ici.

Fonctionnement : permissions, valeurs à la création et récupération

La protection est représentée par des permissions Deny

La protection utilise deux permissions Deny pour Everyone, identifié par le SID S-1-1-0 : Delete et Delete Subtree. Les consignes de prévention des suppressions accidentelles de Microsoft décrivent des ACE Deny pour DELETE et DELETE TREE sur l'objet. Elles décrivent aussi un refus complémentaire de DELETE CHILD sur le parent. Examinez l'objet et son parent lorsque le comportement des permissions est incertain ; n'assimilez pas une seule ACE correspondante à une évaluation complète des permissions effectives.

Dans Active Directory Users and Computers, activez Advanced Features pour afficher l'onglet Object et sa case de protection. Pour examiner les permissions, inspectez les entrées avancées de l'onglet Security, leur bénéficiaire, les droits refusés et leur portée. Les consignes de prévention citées ci-dessus documentent la case et le modèle de permissions sous-jacent. Conservez une trace des entrées pertinentes au lieu de vous fier uniquement à une capture d'écran d'une case cochée.

Cette distinction compte lorsqu'on compare des outils. Une propriété étendue présente une vue administrative de la protection, tandis qu'un détecteur peut ne reconnaître qu'un sous-ensemble des représentations de permissions. Une revue d'ACL doit aussi tenir compte du parent et de la portée de chaque entrée. Si ces observations divergent, conservez cette divergence et examinez-la avant de modifier les permissions.

Une protection par défaut à la création n'audite pas les OU existantes

L'exemple 1 de New-ADOrganizationalUnit crée une OU protégée sans définir explicitement le paramètre de protection. L'exemple 2 crée explicitement une OU non protégée avec $False. Une valeur actuelle par défaut à la création n'établit donc pas l'état des OU anciennes, migrées ou modifiées ensuite. Leur protection peut différer et doit être lue.

Notre guide des conteneurs par défaut et de leur redirection utilise cette protection implicite lors de la création d'OU cibles pour redircmp et redirusr. Il traite du placement et de la portée des stratégies de groupe. Examiner les garanties contre la suppression d'une OU existante constitue une tâche distincte ; l'exemple de création ne fournit ni inventaire ni approbation pour un nettoyage.

Prévention et récupération répondent à des questions différentes

La protection vise à empêcher une opération accidentelle. Les sauvegardes et la récupération d'objets concernent ce qui se passe après une perte de données. Les consignes Recycle Bin de Microsoft expliquent que seuls les objets supprimés après l'activation peuvent être récupérés par cette fonctionnalité. Vérifiez séparément l'état réel de la fonctionnalité et la préparation à la récupération.

Notre guide de restauration de forêt Active Directory et de validation des sauvegardes explique la sélection des sauvegardes, les preuves de restauration et les limites de Recycle Bin. Utilisez-le pour la revue complémentaire de récupération. Ni une OU protégée ni la disponibilité de Recycle Bin ne prouvent qu'une restauration de forêt a été validée. De même, préparer la récupération ne justifie pas de laisser une OU de production sans protection en l'absence d'une exception acceptée.

Détection : inventorier indépendamment et lire la DACL

1. Établir une collecte réussie et délimitée

Utilisez un poste d'administration autorisé doté du module PowerShell Active Directory. Consignez le domaine, le serveur interrogé, l'heure de collecte, le contexte des identifiants et le périmètre de recherche. Une lecture échouée ou partielle doit figurer dans les preuves comme un problème de collecte non résolu. Ne classez pas un objet illisible comme non protégé et n'interprétez pas un résultat vide comme un inventaire terminé.

L'exemple suivant, destiné au lecteur, adapte les paramètres documentés Filter et Properties de Get-ADOrganizationalUnit. Il demande explicitement la propriété étendue :

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Choisissez le domaine et le serveur visés au lieu d'accepter silencieusement les valeurs par défaut du poste d'administration. Learn documente aussi Server, SearchBase et SearchScope pour définir ce contexte. La commande ci-dessus est un point de départ pour l'inventaire, pas une garantie d'exhaustivité à l'échelle de la forêt ni une instruction de modifier chaque résultat.

Pour chaque OU lue avec succès, conservez son nom distinctif et son GUID d'objet avec la valeur de la propriété. Ajoutez l'équipe métier ou d'infrastructure responsable, la finalité prévue et toute décision de nettoyage proposée. L'équipe responsable est une donnée d'entrée de la revue ; ne supposez pas qu'un attribut ou un nom d'OU prouve qui peut approuver la suppression.

2. Lire les permissions indépendamment du collecteur

Pour un objet précis, l'exemple suivant demande à la fois la propriété de protection et le descripteur de sécurité par le même mécanisme documenté Properties. Le DN Fabrikam est un exemple fictif à remplacer par la cible examinée :

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Inspectez la DACL du descripteur de sécurité retourné avec un outil d'administration d'annuaire autorisé, ou utilisez la vue Security avancée dans Active Directory Users and Computers. Confirmez Everyone par son SID plutôt que de dépendre d'un nom affiché localisé. Examinez les refus Delete et Delete Subtree, leur application à l'objet et les permissions pertinentes du parent. Conservez les preuves brutes ou exportées des permissions lorsqu'elles sont disponibles.

Cette lecture indépendante doit conserver les entrées Deny. Réutiliser la liste d'ACL filtrée du collecteur reproduit exactement la limite examinée. Si l'accès au descripteur échoue, consignez cet échec et obtenez les droits de lecture appropriés par le processus d'administration habituel. Une valeur de propriété et une lecture de DACL échouée doivent rester distinguables.

3. Rapprocher les constats des preuves de l'annuaire

Comparez l'inventaire du collecteur à l'inventaire administratif lu avec succès. Utilisez les identifiants d'objets et les DN réels pour examiner les écarts. Une différence d'orthographe ou de casse doit conduire à un rapprochement, plutôt qu'à conclure que deux enregistrements décrivent nécessairement des objets différents. Conservez les valeurs d'origine pour expliquer la recherche sensible à la casse du collecteur.

Un constat ne fournit ni chronologie d'attaque ni historique de suppression. Ne déduisez pas une compromission, une intention malveillante ou un incident avéré de ce signal de configuration. Si une suppression a réellement eu lieu, son investigation et sa récupération exigent des preuves distinctes.

Remédiation : protéger les OU sélectionnées et encadrer les exceptions de nettoyage (Remediation)

1. Décider de l'état souhaité avec le responsable

Partez de l'inventaire rapproché. Identifiez les OU de production à conserver, les hiérarchies de préparation, les exceptions de migration et les objets proposés à la suppression. Demandez à l'équipe responsable de confirmer les dépendances et les objets exacts couverts par le changement. Une OU apparemment vide ne constitue pas en soi une demande de nettoyage approuvée.

Consignez les preuves actuelles de la propriété et de la DACL, le responsable de la décision, l'identifiant cible, l'état souhaité et la méthode de vérification. Examinez qui peut modifier les permissions pertinentes. La protection ne remplace ni cette revue administrative, ni une sauvegarde utilisable, ni un plan de récupération d'objets. Si la collecte ou la responsabilité restent incertaines, gardez le point ouvert au lieu de transformer l'incertitude en modification en masse.

2. Activer la protection sur une OU conservée et approuvée

Cet exemple utilise les paramètres documentés Identity et ProtectedFromAccidentalDeletion de Set-ADOrganizationalUnit, en définissant le booléen à true pour une cible fictive. C'est un exemple de modification ciblée, pas une recommandation de transmettre tout l'inventaire à une opération de changement :

Set-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -ProtectedFromAccidentalDeletion $True

Appliquez le changement uniquement à l'objet examiné par le processus d'administration autorisé. Conservez toute erreur et le résultat réel de l'opération. Une demande de définition d'une valeur constitue une preuve différente de celle d'une mise à jour réussie de l'annuaire. En cas d'échec, examinez les accès et le contexte de la cible avant de réessayer ou d'élargir les permissions.

3. Relire l'objet et ses permissions pertinentes

Après un changement réussi, récupérez indépendamment la cible à nouveau :

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Confirmez la propriété et inspectez la DACL en utilisant le contexte de collecte consigné. Conservez les preuves avant et après ainsi que tout écart restant. Si un autre serveur fait partie du plan de vérification, consignez cette lecture séparée au lieu de supposer que toutes les vues de l'annuaire sont déjà identiques. Clôturez le changement uniquement au regard des preuves d'acceptation attendues.

Ne tentez pas une suppression en production pour démontrer que la protection fonctionne. Ce guide exige une relecture réussie et une revue des permissions ; il ne prescrit pas de test destructif. Un décompte du collecteur inchangé ne suffit pas non plus à déclarer cette modification infructueuse, compte tenu du défaut du fournisseur décrit ci-dessous.

4. Limiter le retrait de la protection à l'opération approuvée

La référence Set de Microsoft comporte un exemple $false pour retirer la protection. Un tel changement relève uniquement d'une décision de nettoyage ou de migration approuvée séparément. Consignez la cible précise, le motif, l'opérateur et la période de l'exception. Évitez de retirer les garanties de toute une hiérarchie simplement pour faciliter une opération.

Après le travail approuvé, réappliquez la protection aux objets conservés temporairement exemptés et répétez la revue propriété/DACL. Si l'objet a été supprimé intentionnellement, conservez les preuves d'approbation et d'opération ; aucun objet ne subsiste à reprotéger. Un nettoyage abandonné ou échoué ne doit pas laisser silencieusement les OU conservées sans leur garantie prévue.

Comment EtcSec détecte ce problème

Le contrôle etc-collector examiné est OU_UNPROTECTED, dans public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. Le détecteur et le fournisseur LDAP ont été lus au commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c ; le même comportement pertinent a aussi été examiné au HEAD du collecteur 42bfefbace3189588e76ff291c39e100c6a603a0.

Le détecteur construit un ensemble de DN d'objets protégés à partir des entrées d'ACL fournies. Une entrée ne convient que si son type correspond exactement au nom de type ACCESS_DENIED, si son bénéficiaire vaut S-1-1-0 et si son masque d'accès contient DELETE (0x10000). La comparaison du nom de type utilise strings.EqualFold : la casse est donc ignorée pour cette comparaison ; ACCESS_DENIED_OBJECT est un type différent qui ne convient pas.

Il recherche ensuite chaque ou.DN inventorié dans cet ensemble en utilisant la clé de chaîne ObjectDN. Cette correspondance de DN est sensible à la casse. Les OU sans correspondance contribuent au Count d'un unique constat Low. Le constat est retourné même lorsque le décompte est nul ; les entités OU affectées ne sont ajoutées que lorsque les détails sont demandés et que le décompte est positif.

Malgré le commentaire plus large sur Delete et Delete Subtree, le prédicat ne teste pas DELETE_TREE (0x40). Il ne teste pas non plus le DELETE CHILD du parent, les indicateurs de portée des ACE ni les droits effectifs de suppression. Un refus Delete correspondant suffit à inclure l'objet dans son ensemble protégé ; le prédicat du détecteur ne peut donc pas, à lui seul, valider la garantie complète.

Le fournisseur empêche une détection fiable de bout en bout sur ce chemin examiné. Dans public/internal/providers/ldap/acl_parser.go:276, parseACE ne conserve que les ACE Allow. Les lignes 297-300 retournent nil pour les types autres que ACCESS_ALLOWED et ACCESS_ALLOWED_OBJECT, éliminant les ACE Deny attendues par ce détecteur. Avec cette entrée filtrée, son ensemble protégé peut rester vide et le décompte peut couvrir toutes les OU inventoriées, y compris des OU réellement protégées.

Il s'agit d'une limite de collecte exigeant une vérification indépendante de la propriété et de la DACL, pas d'une mesure fiable d'absence de protection. La correction du fournisseur relève de l'équipe du collecteur et sort du périmètre de cet article. Aucune réussite de détection de bout en bout ni aucun décompte client n'est affirmé.