redircmp redirusr conteneurs par defaut GPO : guide AD

Que sont les conteneurs par défaut dans Active Directory ?

La question pratique derrière redircmp redirusr conteneurs par defaut GPO est de savoir où arrivent les nouvelles identités et si cet emplacement appartient à la structure de stratégie prévue. Active Directory fournit CN=Computers et CN=Users à l'installation du domaine. Ce sont des conteneurs, et non des unités d'organisation. Les instructions de Microsoft sur la redirection des conteneurs expliquent leur rôle par défaut, tandis que sa présentation de la stratégie de groupe désigne l'OU comme le niveau le plus bas d'AD auquel une stratégie de groupe peut être affectée.

Vous ne pouvez pas lier directement une GPO à ces conteneurs par défaut. Cela ne signifie pas que leurs ordinateurs et utilisateurs ne reçoivent aucune stratégie de groupe : les GPO liées au site et au domaine peuvent toujours s'appliquer, et la stratégie locale reste pertinente. La lacune est plus précise. Un objet dans CN=Computers se trouve hors de la sous-arborescence d'une stratégie liée uniquement à votre OU de postes de travail ou de serveurs. La référence Redircmp de Microsoft confirme l'absence de lien direct de stratégie de groupe vers le conteneur par défaut. Les règles de portée du site, du domaine et des OU sont documentées dans la présentation de la stratégie de groupe citée ci-dessus.

Ce guide distingue quatre questions : où résident les objets aujourd'hui, où la création par défaut placera les futurs objets, quelles stratégies atteignent réellement le client et quels comptes d'ordinateur nécessitent une revue du provisionnement. Un constat concernant un conteneur par défaut répond à la première question. La redirection traite la deuxième. Aucun des deux n'établit l'état LAPS du client ni la sécurité d'un compte de machine préparé à l'avance.

Fonctionnement : destination et portée des stratégies sont distinctes

La création par défaut suit une référence de l'annuaire

Microsoft documente les destinations par défaut dans l'attribut wellKnownObjects du domaine. Les anciennes API de création consultent ces références pour les utilisateurs, groupes et ordinateurs. Les utilitaires de redirection modifient ces références vers des OU choisies par l'administrateur ; ils ne transforment pas les conteneurs d'origine en OU. Les nouveaux objets créés par les chemins par défaut concernés utilisent ensuite la nouvelle destination. KB324949 décrit à la fois ces références et les opérations qui en dépendent.

Un processus de jonction peut aussi fournir explicitement une destination. La référence netdom join documente /ou et indique que la création du compte utilise la destination d'ordinateur par défaut du domaine lorsque cette option est omise. Dans une installation standard sans redirection, il s'agit de CN=Computers ; après redirection, il peut s'agir de l'OU désignée. La réutilisation d'un compte existant pour une jonction constitue un autre cas. Évitez donc de supposer que toute jonction crée nécessairement un nouvel objet dans le conteneur par défaut.

Pour les utilisateurs, redirusr affecte l'emplacement de création par défaut des utilisateurs, groupes et comptes utilisateur d'approbation créés par les API documentées. Placer un groupe à un emplacement ne signifie pas que ce groupe traite lui-même la configuration utilisateur comme un utilisateur connecté. Distinguez l'inventaire des comptes du traitement des stratégies et conservez les comptes par défaut, sauf si une modification examinée séparément exige autre chose. S1 décrit l'ensemble plus large d'objets affectés par la destination Users.

Le placement dans une OU crée un chemin admissible, pas un contrôle achevé

La portée de la stratégie de groupe suit les liens au niveau des sites, domaines et OU, y compris la hiérarchie des OU parentes concernées. Déplacer un ordinateur dans l'OU prévue peut le placer sous cette hiérarchie, mais il reste nécessaire de valider le traitement et les paramètres attendus. La présentation de Microsoft décrit la portée fondée sur l'emplacement et le traitement côté client.

Notre guide du filtrage de sécurité des GPO traite la couche suivante : portée des liens, droit Read de l'ordinateur, droit Apply de l'utilisateur et distinction entre autoriser la récupération et élargir le public concerné. Il explique qu'un emplacement correct et une stratégie liée ne suffisent pas sans les autorisations et conditions de traitement requises. Effectuez cette revue après avoir corrigé le placement.

LAPS ajoute ses propres exigences de déploiement. La procédure Windows LAPS avec stockage dans AD de Microsoft distingue l'autorisation d'écriture de l'appareil, l'autorisation de récupération du mot de passe, la stratégie de l'appareil et la vérification des mises à jour de l'annuaire. Un ordinateur hors d'une OU qui constitue l'unique source de sa stratégie LAPS peut donc présenter un problème de couverture ; un ordinateur recevant une stratégie équivalente par une autre voie prise en charge peut ne pas en présenter.

Le guide des lacunes de couverture LAPS associé examine le déploiement partiel, le stockage historique, les droits excessifs de récupération et les preuves nécessaires pour valider la rotation. Il fournit la revue complémentaire lorsqu'un placement révèle une lacune possible. Compter les ordinateurs dans CN=Computers ne mesure pas le nombre d'ordinateurs dépourvus de LAPS.

Mesurer le placement avant de modifier les valeurs par défaut

1. Inventorier les ordinateurs dans le conteneur par défaut

Utilisez un domaine défini et consignez la base de recherche, l'heure de collecte, l'état d'activation et les identifiants des objets. L'exemple suivant destiné au lecteur adapte les paramètres documentés Filter, SearchBase, SearchScope et Properties de Get-ADComputer. Les noms de domaine et d'objet employés dans ce guide sont des exemples fictifs.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

L'objectif est d'énumérer les enfants directs pour une revue de placement. Cette requête inclut les comptes désactivés, alors que le détecteur de placement EtcSec examiné les exclut. Distinguez ces populations lors de la comparaison des résultats. Un inventaire administratif et un décompte de détecteur ne sont pas nécessairement identiques, car leurs prédicats diffèrent.

Le nombre d'objets dans un conteneur mesure leur placement dans l'annuaire, pas la couverture de protection. Déterminez quels objets appartiennent à la production, lesquels sont des comptes de préparation approuvés et lesquels nécessitent une investigation. Pour chaque objet, consignez la destination proposée et le responsable. Ce sont des décisions de revue ; la commande fournit des données d'annuaire, pas une évaluation de la protection des terminaux.

2. Inventorier les utilisateurs sans assimiler le conteneur à une seule classe de comptes

L'exemple suivant remplace la base du modèle documenté de recherche dans un conteneur par le conteneur Users par défaut et demande l'état d'activation via Properties. Get-ADUser documente ces deux paramètres :

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

Cette requête récupère les utilisateurs, et non un inventaire complet de tous les groupes et objets spéciaux du conteneur. Les instructions de redirection de Microsoft traitent spécifiquement des groupes par défaut et des comptes utilisateur d'approbation. Avant la migration, distinguez les utilisateurs ordinaires des comptes intégrés ou dépendants d'applications et déterminez quels objets doivent rester en place.

Examinez conjointement la source et la destination. Un utilisateur déplacé dans une autre OU peut entrer dans une autre hiérarchie de stratégies utilisateur, tout comme un ordinateur peut entrer dans une autre hiérarchie de stratégies ordinateur. Utilisez le modèle de portée de la stratégie de groupe pour identifier le changement attendu avant de déplacer l'objet, au lieu de considérer une vue d'annuaire mieux organisée comme le critère d'achèvement.

3. Examiner séparément le signal de provisionnement des comptes de machine

Un ordinateur peut être préparé dans une OU appropriée tout en nécessitant une revue. Inversement, un ordinateur actif dans le conteneur par défaut ne correspond pas nécessairement au signal de préparation. Pour obtenir l'attribut sous-jacent, cet exemple utilise le paramètre Properties documenté de Get-ADComputer :

Get-ADComputer -Filter * -Properties userAccountControl

La référence UserAccountControl de Microsoft attribue à PASSWD_NOTREQD la valeur 0x20 et à WORKSTATION_TRUST_ACCOUNT la valeur 0x1000. Le collecteur les combine en 0x1020, soit 4128 en décimal, et teste si les deux bits sont présents. Le prédicat exact est détaillé plus loin ; ne le remplacez pas par un test d'égalité sur l'attribut entier.

Pour les comptes correspondants, demandez qui a créé l'objet, quelle demande de provisionnement il sert, si la machine prévue a rejoint le domaine et quelles preuves indépendantes d'activité existent. Définissez une période locale de revue avec le propriétaire du compte. Le détecteur ne fournit ni seuil d'ancienneté ni historique de jonction vérifié ; aucun des deux ne doit donc figurer dans un résultat présenté comme celui du détecteur.

Détection : corréler les signaux d'annuaire avec les résultats du client

Un objet mal placé justifie une revue de portée

Traitez le placement comme un signal invitant à examiner la relation de stratégie prévue. Consignez les GPO de référence attendues pour l'ordinateur, l'emplacement de leurs liens et les résultats réels du client. La documentation gpresult définit les rapports du jeu de stratégie résultant ainsi que la portée ordinateur et les options de synthèse utilisées ici :

gpresult /scope computer /r

Exécutez le contrôle documenté destiné au lecteur sur l'ordinateur concerné avec les accès appropriés. Comparez les GPO appliquées à la référence attendue, puis vérifiez les paramètres importants. Un rapport indiquant l'application d'une stratégie constitue une preuve différente d'une sauvegarde LAPS réussie ou de l'état effectif d'un paramètre d'audit. Cet article ne revendique aucun résultat obtenu dans un domaine réel.

Pour Windows LAPS natif avec stockage dans AD, la procédure de déploiement de Microsoft identifie l'événement 10018 comme une preuve de mise à jour réussie d'un nouveau mot de passe dans AD. Utilisez-le comme contrôle de résultat distinct lorsque ce déploiement s'applique. L'absence d'événement nécessite d'examiner la chronologie et les journaux disponibles ; ce n'est pas une preuve déduite du DN de l'objet.

Les mots de passe par défaut historiques exigent un contexte de version

La précréation peut être un processus légitime. Les instructions de Microsoft sur les autorisations de jonction au domaine décrivent un administrateur créant un compte d'ordinateur et une autre identité autorisée le réutilisant. Un compte préparé mérite une gestion de cycle de vie, mais sa préparation seule n'établit pas une compromission.

Il existe un risque historique distinct. La référence NetProvisionComputerAccount documente une option explicite utilisant le nom de machine en minuscules comme mot de passe initial et recommande d'éviter cette option lorsque c'est possible. Il s'agit d'un mode de provisionnement particulier. Le masque UAC ne lit pas le secret et ne peut pas établir que cette option a été utilisée, qu'un mot de passe est vide ou prévisible, ou qu'une authentification a réussi.

La version compte. Les changements de Windows Server 2025 documentés par Microsoft décrivent des mots de passe initiaux de comptes d'ordinateur générés aléatoirement, des contrôles rejetant les valeurs par défaut dérivées du nom et la suppression, dans ADUC/ADAC, de la possibilité de créer des comptes pré-Windows 2000. La stratégie documentée est Domain controller: Refuse setting default machine account password. Vérifiez les versions des contrôleurs de domaine, les outils de création et cette stratégie avant d'appliquer le modèle historique aux comptes actuels. Une identité abandonnée nécessite toujours un propriétaire et une décision de cycle de vie, même si son secret initial était aléatoire.

Remédiation : rediriger les créations futures et migrer les objets existants (Remediation)

1. Concevoir les OU cibles et leurs responsabilités

Choisissez les OU cibles selon les besoins d'administration et de stratégie. Décidez si la création par défaut doit aboutir dans une OU de préparation ou dans la hiérarchie de production finale et documentez qui termine la transition. Une OU nommée « Staging » n'est utile que si sa stratégie prévue et l'équipe responsable sont clairement définies. La présentation de la stratégie de groupe traite de l'équilibre entre délégation et exigences de stratégie.

Les commandes suivantes adaptent l'exemple 1 de New-ADOrganizationalUnit, en remplaçant les noms par deux noms cibles et le domaine fictif. L'exemple documenté crée une OU dont la protection contre la suppression accidentelle est implicitement activée. Chaque opération est présentée séparément :

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Préparez les stratégies et la délégation prévues avant d'utiliser ces OU comme destinations par défaut. Créer l'OU est une opération de gestion d'objet ; cela ne lie pas de GPO, n'autorise pas le provisionnement et n'établit pas qu'un appareil a traité une configuration de référence.

2. Vérifier les prérequis de redirection

KB324949 exige un niveau fonctionnel de domaine Windows Server 2003 ou supérieur, une OU cible existante, des identifiants d'administrateur du domaine et un PDC accessible. Vérifiez la configuration réelle du domaine au lieu de déduire son niveau fonctionnel du système d'exploitation d'un seul serveur.

L'ancienne page Redircmp énumère des versions historiques de niveaux fonctionnels. Pour cette procédure, utilisez l'exigence « 2003 ou supérieur » de la KB actuelle. La référence Redircmp exige aussi une invite de commandes élevée. Une élévation du niveau fonctionnel du domaine, si nécessaire, constitue une décision de compatibilité distincte ; elle ne doit pas être présentée comme une étape accessoire d'un article sur le placement des objets.

3. Modifier indépendamment les destinations par défaut des ordinateurs et utilisateurs

Les deux commandes suivantes reproduisent les exemples de Microsoft dans S1, sans le préfixe de l'invite de commandes. Chacune modifie une destination par défaut distincte :

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

La syntaxe générique documentée est redircmp container-dn et c:\windows\system32\redirusr container-dn. L'argument est le nom distinctif de l'OU cible. Remplacez-le par la destination approuvée ; une commande réussie traite les créations futures par les chemins par défaut concernés.

Aucun des deux utilitaires ne déplace les objets existants. Traitez le placement futur et le placement existant comme des tâches distinctes. Le provisionnement avec OU explicite et la réutilisation des comptes nécessitent également leur propre validation, au lieu de les déduire de la nouvelle destination par défaut.

4. Migrer les objets existants sélectionnés avec une revue des stratégies

Évaluez les dépendances applicatives, la finalité du compte et le changement de stratégie attendu avant de sélectionner chaque objet. La commande suivante adapte la syntaxe documentée Identity et TargetPath de Move-ADObject à un ordinateur existant fictif :

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Sélectionnez les objets réels dans un inventaire ayant fait l'objet d'une revue. N'effectuez pas de déplacement en masse indifférencié de tout le contenu de CN=Users ou CN=Computers. La KB de redirection traite de la rétrocompatibilité et des comptes par défaut ; la présentation de la stratégie de groupe explique l'héritage qui donne une portée opérationnelle au changement de destination.

Après le déplacement, confirmez le nouvel emplacement de l'objet et répétez la revue des stratégies du client. Clôturez la tâche de placement avec des preuves d'annuaire et toute lacune de protection avec des preuves propres à cette protection. Ce sont des contrôles liés dont les critères d'achèvement diffèrent.

5. Déléguer explicitement la création, la réutilisation et la gestion des stratégies

Les instructions de délégation de contrôle de Microsoft distinguent les tâches telles que la jonction d'ordinateurs, la gestion des utilisateurs et la gestion des liens GPO. Déléguez les tâches nécessaires à la portée appropriée. Modifier une destination par défaut n'accorde pas à l'identité effectuant la jonction l'autorisation d'y créer ou réutiliser des comptes.

Pour les comptes d'ordinateur réutilisés, examinez le propriétaire et les autorisations requises selon la procédure d'autorisations de jonction au domaine. Diagnostiquez l'échec d'une jonction dans le cadre de ces exigences. N'élargissez pas les appartenances administratives et ne contournez pas les contrôles de propriété simplement pour faire fonctionner un processus nouvellement redirigé.

Pour Windows LAPS natif avec stockage dans AD, la procédure de déploiement documente l'autorisation de mise à jour de l'appareil par lui-même. Cet exemple remplace la cible de cette commande par l'OU d'ordinateurs approuvée :

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

Cela ne configure pas la stratégie LAPS et n'établit pas les droits de récupération du mot de passe. Validez séparément la stratégie prévue et une mise à jour réussie du client. Examinez également la population autorisée à récupérer les mots de passe ; placer un ordinateur dans la portée d'une stratégie ne résout pas les accès excessifs à la récupération.

6. Examiner les comptes préparés et tester les futurs processus

Pour chaque candidat préparé, conservez la finalité métier, le propriétaire, l'outil de provisionnement et les preuves justifiant le maintien de son utilisation. Déterminez si le compte doit terminer son provisionnement, rester dans un processus de préparation approuvé ou entrer dans la procédure de retrait de l'organisation. Aucun seuil universel d'ancienneté ni règle de suppression automatique ne se déduit du masque UAC.

Après remédiation, testez un processus autorisé de création de compte utilisant le chemin par défaut et un processus réutilisant un compte précréé. Vérifiez la destination obtenue, les autorisations, l'application attendue des GPO et les résultats des services concernés. Les autorisations de jonction et les règles de destination netdom de Microsoft expliquent pourquoi ces processus doivent être examinés séparément.

Toutes les commandes de ce guide sont des exemples documentés destinés au lecteur ou des adaptations explicitement identifiées. Elles n'ont pas été exécutées sur un domaine AD pour cet article et ne constituent pas des preuves de redirection, de migration ou de rotation réussies.

Comment EtcSec détecte ce problème

Les descriptions suivantes reflètent les implémentations Detect() examinées dans le commit etc-collector b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Les chemins ci-dessous sont relatifs à public/internal/audit/detectors/.

COMPUTER_WRONG_OU, dans ad/computers/organization/wrong-ou.go:35, ignore les ordinateurs désactivés, convertit le DN en minuscules et recherche ,cn=computers,dc= aux lignes 39–49. Il rapporte une sévérité Low. C'est un test de sous-chaîne, et non une comparaison après analyse du parent de l'objet avec une OU cible configurée. Il n'inventorie pas l'application effective des GPO et n'établit pas l'absence de LAPS, de durcissement ou d'audit.

COMPUTER_PRE_CREATED, dans ad/computers/status/pre-created.go:35, teste UserAccountControl & 0x1020 == 0x1020 aux lignes 38–41. Des bits supplémentaires sont autorisés, y compris l'état désactivé. Son constat Medium ne comporte aucune condition sur le DN, aucun seuil d'ancienneté, aucun test d'historique de connexion ni inspection de la valeur du secret. Le nom du constat désigne un signal de revue de préparation ; le prédicat ne prouve pas que l'ordinateur n'a jamais rejoint le domaine.

Un contrôle voisin, SERVER_NO_ADMIN_GROUP, a été examiné mais n'est pas associé à cet article. Dans ad/computers/organization/server-no-admin-group.go:43, il sélectionne les ordinateurs activés classés heuristiquement comme serveurs et vérifie la couverture via des liens activés vers des données Restricted Groups analysées contenant une liste non vide de membres Administrators. Ses fonctions auxiliaires se trouvent aux lignes 102–186. Il ne détecte pas spécifiquement la présence dans CN=Computers, ne calcule pas le filtrage effectif et n'inspecte pas les membres locaux réels du serveur. En l'absence de données de stratégie GPO fournies, son décompte nul n'établit pas la conformité.

Utilisez ces constats pour choisir l'étape de validation suivante. Corrigez le placement, vérifiez le provisionnement futur, établissez la protection réelle du client et résolvez séparément la propriété des comptes préparés. Un prédicat d'annuaire devenu négatif constitue une preuve utile pour ce prédicat ; une remédiation opérationnelle réussie exige les preuves de résultat correspondantes.