Revue AD des postes en OU serveur : impact avant un déplacement

En quoi consiste une revue AD des postes en OU serveur ?

Une revue AD des postes en OU serveur vérifie si l'emplacement d'un ordinateur dans l'annuaire correspond à son usage réel et aux stratégies qu'il doit recevoir. Un ordinateur activé qui semble être un poste de travail dans une OU dont le nom évoque des serveurs mérite un examen. Son emplacement seul ne démontre ni un échec de stratégie, ni un incident de sécurité, ni une violation de conformité.

La question utile est précise : déplacer cet ordinateur modifierait-il le résultat de stratégie attendu, et son responsable peut-il démontrer que ce changement est approprié ? Commencez par le rôle réel de l'appareil et la convention d'OU de l'organisation. Conservez ensuite le résultat de stratégie actuel de l'ordinateur, examinez la destination proposée et testez un pilote approuvé avant d'étendre le changement.

Ce guide traite d'un signal de classification issu de WORKSTATION_IN_SERVER_OU. Il ne propose pas une organisation universelle des OU. Une hiérarchie partagée, un nom hérité ou un terminal à usage particulier documenté peuvent expliquer un résultat. La revue doit aboutir à une décision d'emplacement dont la responsabilité est identifiée, étayée par des preuves de stratégie, y compris une décision de conserver l'emplacement actuel lorsqu'elle est justifiée.

Rapport entre l'emplacement et la portée des stratégies

La référence Microsoft sur le traitement des stratégies de groupe décrit le traitement au niveau local, du site, du domaine et des OU, y compris des OU parentes. L'ordre des liens, leur application forcée, le blocage de l'héritage, les sections désactivées, le filtrage de sécurité et le filtrage WMI influencent le résultat. Le libellé d'une OU n'est pas un paramètre de stratégie.

Préparez une comparaison entre la source et la destination dans GPMC. Consignez les liens et l'héritage pertinents pour chaque emplacement, puis identifiez les paramètres que le responsable de l'appareil prévoit de conserver, d'obtenir ou de perdre. Utilisez les identités des stratégies ainsi que leurs noms d'affichage afin de ne pas confondre des GPO aux noms similaires dans le dossier de changement. Résolvez les différences inexpliquées avant de planifier le pilote.

Pour la couche des permissions, consultez notre guide sur Read pour les ordinateurs, Apply ciblé et le filtrage de sécurité GPO. Read et Apply Group Policy sont distincts ; la récupération par l'ordinateur et la population visée par l'application nécessitent des vérifications séparées. Ce guide étaye l'examen de la portée présenté ici. Il ne démontre pas qu'un nom d'OU a provoqué un échec.

Lorsque l'expérience utilisateur dépend de l'ordinateur, examinez aussi le traitement en boucle, ou loopback. La référence Microsoft sur le traitement distingue Merge, qui ajoute la liste des stratégies utilisateur fondée sur l'ordinateur, de Replace, qui utilise cette liste à la place. Consignez le mode configuré et incluez des tests utilisateur représentatifs lorsque cela est pertinent. Un résultat limité à l'ordinateur ne répond pas à toutes les questions relatives aux sessions utilisateur.

Le problème des conteneurs par défaut est également distinct. Notre guide sur CN=Computers, la redirection et les résultats de stratégie client explique que le conteneur par défaut ne peut pas porter de lien GPO direct comme une OU. Rediriger les créations futures, déplacer les objets existants et valider les résultats clients sont des tâches distinctes. Un objet déjà situé dans une OU nommée Servers ne nécessite pas automatiquement cette procédure de redirection.

Détection : identifier l'appareil et conserver son résultat

1. Confirmer les données à l'origine du résultat

Pour chaque candidat, conservez le nom distinctif, sAMAccountName, l'attribut d'annuaire operatingSystem, l'état activé, l'heure de collecte et le périmètre de collecte. Identifiez la partie du DN qui correspond au motif de nom de serveur. Une correspondance dans un ancêtre a une explication administrative différente d'une correspondance dans le parent immédiat, même si le détecteur accepte les deux.

Demandez au responsable de l'appareil de vérifier son rôle actuel et son système d'exploitation à partir de l'inventaire fiable des terminaux de l'organisation ou d'une vérification autorisée de l'appareil. Réconciliez les divergences avec les attributs d'annuaire. Un préfixe de nom est une piste d'investigation ; ce n'est pas une preuve indépendante que l'hôte est actuellement un poste de bureau ou qu'il doit être déplacé.

Utilisez cette matrice de revue pour distinguer les preuves :

2. Capturer le RSoP de l'ordinateur avant de changer son emplacement

Microsoft décrit Get-GPResultantSetOfPolicy comme une cmdlet qui écrit les informations RSoP dans un fichier. Sa syntaxe accepte Computer, ReportType et Path. L'exemple suivant destiné au lecteur adapte ces paramètres documentés à un poste fictif et à un nom de fichier de référence :

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-before.xml'

Utilisez le nom vérifié de l'appareil, un répertoire disponible pour les rapports et un compte autorisé dans votre environnement. La documentation Microsoft sur les résultats de stratégie de groupe décrit l'accès distant au moyen de la permission déléguée Remotely access Group Policy Results data sur le domaine ou l'OU qui contient l'objet, ou de l'appartenance au groupe Administrators local de l'ordinateur cible. Vérifiez aussi la connectivité réseau vers la cible. Conservez le rapport avec l'identité de l'objet, son DN d'origine, l'heure de capture et le dossier de revue. Examinez le contexte de journalisation retourné et la section ordinateur du rapport pour confirmer que les preuves concernent l'appareil voulu. Une requête échouée laisse le résultat inconnu ; ce n'est pas une référence vide obtenue avec succès.

La cmdlet retourne des résultats de journalisation. Microsoft oriente les administrateurs vers GPMC pour la modélisation RSoP. Ce rapport consigne donc le traitement observé au lieu de prédire le résultat à destination. Comparez-le à la référence approuvée et répertoriez les différences non résolues avant d'envisager un déplacement. Lorsqu'un paramètre régit un service ou une protection, prévoyez aussi une vérification opérationnelle correspondante.

Remédiation : valider un pilote avant de déplacer davantage d'hôtes (Remediation)

1. Choisir une décision documentée

Classez le candidat examiné comme une exception approuvée, un désaccord de classification ou un changement d'emplacement nécessitant une validation. Consignez le responsable, l'explication et les preuves. Conserver un objet peut être la bonne décision si son rôle et la stratégie attendue sont déjà satisfaits. Renommer un appareil ou une OU uniquement pour faire disparaître le signal heuristique ne prouve aucune amélioration de son résultat de stratégie.

Pour un déplacement proposé, documentez le DN source, la destination approuvée, la différence de stratégie attendue, l'appareil pilote, les critères d'acceptation et le responsable du retour arrière. Confirmez que le changement concerne le même domaine et l'ordinateur sélectionné. Une migration entre domaines nécessite sa propre procédure examinée ; elle sort du cadre de l'exemple d'emplacement d'un seul ordinateur présenté ici.

2. Examiner l'opération d'annuaire individuelle

La référence Microsoft de Move-ADObject documente Identity, TargetPath, WhatIf et Confirm. L'exemple suivant insère dans cette syntaxe un DN d'ordinateur fictif et une OU approuvée fictive :

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -WhatIf

-WhatIf prévisualise l'opération. Il ne déplace pas l'objet et ne simule pas le traitement des GPO. Examinez la source et la destination résolues avant de poursuivre. Ne transmettez jamais tous les résultats à une opération de déplacement par pipeline : le prédicat ne connaît ni la décision du responsable, ni l'adéquation de la destination, ni le plan de maintenance approuvé.

Après validation et autorisation, l'opération pilote individuelle peut utiliser les mêmes paramètres documentés avec confirmation :

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -Confirm

Remplacez chaque identifiant d'exemple par les valeurs examinées. La confirmation est une invite d'exécution ; elle ne remplace pas l'approbation de l'organisation et ne valide pas la conception des stratégies. Il s'agit d'exemples documentés destinés au lecteur, et non de commandes exécutées sur un domaine AD pour cet article.

3. Comparer le résultat après le pilote

Vérifiez le nouvel emplacement dans l'annuaire et effectuez le traitement de stratégie requis par le plan de test approuvé. La référence Microsoft sur le traitement distingue le démarrage, l'ouverture de session et l'actualisation en arrière-plan ; cette dernière ne traite pas toutes les extensions. Consignez le contexte de traitement avant d'interpréter un rapport collecté après le déplacement.

Capturez un résultat séparé pour le même ordinateur à l'aide des paramètres RSoP documentés :

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-after.xml'

Comparez les deux rapports conservés aux changements attendus, puis vérifiez les paramètres pertinents et les critères d'acceptation opérationnels. Lorsque le loopback est important, incluez les comparaisons approuvées de sessions utilisateur. Examinez les ajouts, omissions ou échecs inattendus avant d'étendre le pilote. Utilisez la procédure de retour arrière consignée si les critères d'acceptation ne sont pas remplis, et vérifiez son résultat au lieu de supposer que rétablir le DN rétablit tous les paramètres.

Clôturez la revue avec la décision, les preuves et les exceptions en suspens. Un résultat disparu peut confirmer que l'annuaire ne correspond plus à cette heuristique. Les rapports de stratégie et les vérifications opérationnelles établissent si le résultat attendu a été atteint. Ne fusionnez pas ces critères de clôture en un seul statut vert.

Comment EtcSec détecte ce cas

Cette section décrit uniquement WORKSTATION_IN_SERVER_OU, examiné dans le commit etc-collector 20268a321609c193b79c5da6764f3f56950449cb, à public/internal/audit/detectors/ad/computers/organization/workstation-in-server-ou.go:37.

Le détecteur ignore les ordinateurs marqués Disabled. Pour les autres ordinateurs fournis, il recherche dans l'ensemble du DN les motifs non ancrés et insensibles à la casse ou=server et ou=datacenter. Ces motifs peuvent correspondre à un ancêtre et à des préfixes comme OU=Serverless ; ils n'analysent pas un nom exact d'OU parente immédiate.

Un objet sélectionné est classé comme poste de travail si son sAMAccountName commence, sans distinction de casse, par ws, pc, laptop, desktop ou nb, ou si sa chaîne OS contient Windows 10, Windows 11, Windows 7 ou Windows 8. L'une ou l'autre condition suffit. Par exemple, un préfixe correspondant peut sélectionner un objet sans chaîne OS de poste de travail correspondante. Ce sont des tests de chaînes, et non une vérification en direct du rôle de l'appareil.

Le fournisseur LDAP à public/internal/providers/ldap/client.go:515 fournit les objets ordinateur, et parser.go:220–278 lit le DN, le nom de compte, le système d'exploitation et le contrôle de compte utilisateur dans le modèle d'ordinateur. L'état désactivé est dérivé du contrôle de compte utilisateur. Les valeurs configurées BaseDN et MaxComputers limitent l'inventaire ; un nombre nul doit être interprété dans le périmètre réel de collecte.

Le résultat est informatif. Le commentaire du code identifie explicitement une heuristique produit sans norme de nommage provenant d'un fournisseur ou d'une réglementation, et ne consigne ni déclenchement confirmé en laboratoire ni validation par mise en place puis annulation. La description du résultat affirme un effet GPO incorrect, mais le prédicat examiné ne lit ni le rôle réel ni un rapport de stratégie résultante et ne peut pas étayer cette affirmation causale.

Utilisez le résultat pour sélectionner une revue documentée. Confirmez le rôle et la convention locale, évaluez le chemin des stratégies et conservez les preuves avant/après pour tout déplacement approuvé. Aucun pilote AD réussi, aucune correction de stratégie ni aucun résultat de laboratoire n'est revendiqué ici.