Limites de confiance de Configuration Manager : carte de l'autorité

Pourquoi le placement en OU ne suffit pas à établir les limites de confiance de Configuration Manager

Les limites de confiance de Configuration Manager suivent l'autorité administrative : qui peut modifier un composant de gestion, quelles ressources un opérateur peut contrôler et où une identité d'installation possède des droits locaux. Le nom distinctif d'un ordinateur AD constitue une preuve d'inventaire utile, mais le déplacer dans une OU nommée Management ne répond pas à ces questions.

Partez de l'ordinateur candidat, puis suivez les pouvoirs qu'il confère vers les autres systèmes. S'agit-il d'un serveur de site, d'un hôte SMS Provider, d'un autre système de site ou simplement d'un client géré dont la description contient un nom de produit ? Quelles personnes et identités de service l'administrent ? Quels systèmes ces identités peuvent-elles atteindre ? L'examen d'une frontière reste incomplet tant que le même dossier ne relie pas l'infrastructure de gestion à ses cibles réelles.

Le modèle d'administration par tiers Active Directory et les sessions administratives fournit les principes généraux de séparation. Cet examen y ajoute une cartographie de l'autorité propre au produit. Gardez les deux liés : une convention d'OU peut faciliter le déploiement des stratégies, mais elle ne remplace pas les preuves établissant qui contrôle Configuration Manager ou les systèmes qu'il gère.

Fonctionnement : accès au fournisseur, autorité sur la base de données et portée sur les cibles

Microsoft décrit des couches de sécurité distinctes. Le SMS Provider expose l'accès à la base de données du site via WMI et le service d'administration. L'accès au fournisseur et les permissions sur les objets gérés sont deux questions différentes. Local System et l'utilisateur d'installation de Configuration Manager disposent par défaut d'une autorité sur tous les objets de la base de données du site ; les autres utilisateurs administratifs sont régis par l'administration basée sur les rôles de la console. Les rôles, les étendues de sécurité et les collections définissent ensemble ce qu'un utilisateur peut consulter et gérer. Ces distinctions proviennent des fondamentaux de sécurité de Configuration Manager.

Pour l'examen, consignez séparément trois chemins :

• Contrôle de l'infrastructure : identités capables d'administrer l'hôte du fournisseur, le serveur de site ou l'infrastructure de base de données.
• Administration du produit : principaux dont les permissions attribuées autorisent des opérations sur certains objets Configuration Manager et certaines collections cibles.
• Autorité d'installation : comptes disposant de droits sur les systèmes où le produit installe un client ou un composant de système de site.

Il s'agit d'un modèle d'évaluation, pas d'une affirmation selon laquelle tout opérateur Configuration Manager dispose d'une administration Windows sans restriction. Pour chaque chemin, établissez l'opération autorisée et la ressource concernée. Ne transformez pas la capacité d'interroger le fournisseur en conclusion que l'identité peut déployer sur tous les appareils.

La référence des comptes Configuration Manager de Microsoft fournit des distinctions concrètes. SMS Admins est un groupe local sur les ordinateurs hébergeant le fournisseur ; ses permissions WMI peuvent être examinées avec le composant logiciel enfichable MMC WMI Control. Le RBAC détermine toujours l'accès aux objets de la console. Le client push installation account doit appartenir au groupe Administrators local des clients cibles, pas à Domain Admin ; en l'absence de compte configuré, le site essaie son compte d'ordinateur. Le site system installation account, distinct, exige des permissions administratives locales et le droit utilisateur d'accès réseau sur les systèmes de site cibles. Le network access account sert à accéder aux ressources, pas de contexte d'exécution pour les logiciels, les mises à jour ou les séquences de tâches.

Ces comptes méritent des lignes séparées, même lorsqu'une même identité AD remplit plusieurs fonctions. Une étiquette comme « compte de service » masque la distinction entre télécharger du contenu et administrer une cible. À l'inverse, des noms de comptes différents n'établissent pas une séparation s'ils reçoivent des droits équivalents sur les mêmes machines.

Détection : construire la matrice d'autorité à partir des preuves du produit

Étape 1 : confirmer la fonction réelle du candidat

Conservez le résultat LDAP, le DN de l'ordinateur, le champ d'inventaire ayant correspondu et la date de l'examen. Demandez au responsable du produit d'identifier la fonction réelle du candidat et le site associé. Rapprochez sa réponse de la configuration déployée du produit et de l'inventaire des hôtes. S'il s'agit uniquement d'un client, consignez pourquoi l'heuristique l'a retenu ; n'inventez pas un rôle de gestion pour justifier le constat.

Pour un composant de gestion confirmé, listez les hôtes du fournisseur et de la base de données dont il dépend, les identités d'installation et les responsables administratifs. Marquez les relations non résolues comme inconnues. Un inventaire qui omet un fournisseur ou un système de site distant peut donner l'impression qu'un périmètre de gestion supposément étroit est plus sûr qu'il ne l'est.

Étape 2 : lire ensemble les rôles, les étendues et les collections attribuées

Suivez la procédure de configuration de l'administration basée sur les rôles de Microsoft. Dans la console, ouvrez Administration > Security > Administrative Users, sélectionnez le principal et ouvrez Properties. Examinez Security Roles et Security Scopes, notamment l'association configurée entre les rôles, les étendues et les collections. Pour examiner les permissions d'un rôle sur les objets, accédez à Administration > Security > Security Roles, sélectionnez le rôle, ouvrez Properties et choisissez l'onglet Permissions.

Pour l'autorité sur les collections, examinez les permissions du rôle sur l'objet Collection et les collections attribuées à l'utilisateur administratif. Incluez les collections limitées par ces collections attribuées. Microsoft mentionne aussi le Role-based administration and auditing tool pour auditer les utilisateurs, les collections et les étendues.

Utilisez ces vues comme des preuves, pas seulement comme des captures de noms lisibles. Consignez les identifiants, les actions autorisées pertinentes, les attributions via des groupes et les appareils membres utilisés pour l'examen. Lorsque l'appartenance change, la cartographie de l'autorité doit être réexaminée. Une collection nommée « Servers » ne prouve pas que tous ses membres appartiennent au niveau de confiance prévu.

Étape 3 : examiner la configuration d'installation et les droits locaux sur les cibles

La procédure de déploiement des clients Windows de Microsoft indique le chemin de console : Administration > Site Configuration > Sites, sélectionnez le site, puis Client Installation Settings > Client Push Installation. Examinez l'onglet Accounts ainsi que les paramètres d'installation automatique, les types de systèmes sélectionnés et la sélection des contrôleurs de domaine dans l'onglet General. La procédure documente aussi l'installation poussée lancée pour un appareil ou une collection.

Lisez cette configuration avant de lancer une installation. Une sélection de cibles configurée constitue une preuve sur le processus d'installation ; examinez indépendamment où chaque identité détient réellement des droits administratifs locaux. Distinguez le client push installation account configuré, le recours au compte d'ordinateur et le site system installation account.

Consignez séparément les vérifications réussies et échouées. Si l'appartenance à un groupe local ne peut pas être vérifiée sur une cible, marquez cette cible comme inconnue. Ne déduisez pas une absence de droits d'un hôte indisponible, ni des droits sur toutes les machines d'une vérification réussie sur un seul appareil représentatif.

Étape 4 : relier les principaux aux systèmes gérés

Construisez une ligne par chemin d'autorité. Le tableau suivant est un modèle d'examen, pas un environnement découvert ni un ensemble de permissions par défaut :

Lisez le tableau de gauche à droite : principal → rôle/compte → site/collection → systèmes gérés. Demandez ensuite quelle ligne relie des niveaux de confiance auparavant séparés. Examinez les attributions combinées au lieu de considérer chaque rôle isolément. Conservez une entrée séparée pour un ensemble de cibles inconnu ; une cellule vide ne doit jamais signifier silencieusement « aucun accès ».

Remédiation : aligner l'autorité avant de changer le placement en OU (Remediation)

Étape 1 : décider de la frontière visée et préserver l'état de référence

Avec les responsables de l'infrastructure et des identités, définissez quels systèmes gérés doivent être regroupés et quels chemins administratifs doivent rester séparés. Comparez cette frontière visée à chaque ligne de la matrice. Consignez la raison de chaque écart, son responsable et les preuves nécessaires pour le clore.

Conservez les attributions de rôles existantes, la configuration d'installation, les membres des ensembles cibles et les dépendances opérationnelles avant les changements. Choisissez un pilote contenant à la fois une cible prévue et un système qui doit rester hors de l'autorité de l'opérateur. Prévoyez un test fonctionnel approuvé et un retour arrière pour chaque changement.

Étape 2 : réduire les permissions du produit via la console prise en charge

Utilisez les propriétés des utilisateurs administratifs déjà examinées pour ajuster les associations pertinentes de rôles, d'étendues et de collections. Lorsque les rôles existants accordent une autorité excessive, utilisez la procédure de rôle personnalisé documentée par Microsoft : copiez un rôle dans Administration > Security > Security Roles, examinez ses permissions sur les objets et attribuez uniquement les permissions nécessaires. Les permissions des rôles intégrés ne peuvent pas être modifiées. Ces opérations sont couvertes par la procédure de configuration de l'administration basée sur les rôles.

Le changement doit supprimer une opération indésirable précise ou une relation avec une cible. Vérifiez que l'administration prévue fonctionne toujours et que le système exclu se trouve hors de l'autorité accordée. Gardez l'administration de l'infrastructure dans l'examen ; réduire une attribution dans la console ne résout pas à lui seul un chemin distinct d'administration de l'hôte ou de la base de données.

Étape 3 : séparer l'autorité d'installation lorsque sa portée traverse la frontière

Pour chaque identité d'installation, comparez ses droits locaux vérifiés à l'ensemble de cibles prévu. Proposez des identités distinctes, au périmètre adapté, lorsqu'un compte couvre plusieurs niveaux de confiance. Vérifiez le compte configuré dans le produit et les permissions accordées à chaque destination ; ne changer qu'un côté laisse l'examen incomplet.

La référence des comptes de Microsoft recommande de refuser explicitement l'ouverture de session interactive locale au client push installation account. Elle documente aussi une séquence de remplacement : créer un compte portant un autre nom, l'ajouter à la liste configurée, laisser la réplication AD s'effectuer, puis retirer l'ancien compte. Traitez cela comme une migration coordonnée avec vérification des droits sur les cibles, pas comme une instruction de purger des comptes ou des groupes. L'identité d'installation du système de site exige son propre examen des cibles. Suivez les exigences documentées pour les comptes correspondant à la fonction réellement utilisée.

Étape 4 : rapprocher placement en OU, sessions administratives et flux

Une fois seulement la cartographie de l'autorité cohérente, comparez le placement en OU, la délégation, les stratégies et les points d'entrée administratifs à la conception prévue. Considérez ensemble les hôtes de gestion et les personnes et comptes qui les contrôlent. Déplacer un objet ordinateur ne peut pas corriger un compte qui conserve des droits sur un ensemble de cibles non prévu.

Examinez le transport comme un contrôle distinct. Les contrôles GPO du transport des métadonnées WSUS traitent de la protection de cette connexion ; ils n'établissent pas qui peut administrer le SMS Provider ni ce qu'une identité d'installation peut contrôler. Conservez les deux examens, avec des preuves et des conclusions séparées.

Étape 5 : clore les constats avec des preuves et conserver les exceptions

Reconstruisez la matrice après le pilote et le déploiement ultérieur. Pour chaque ligne modifiée, joignez la nouvelle attribution, les membres actuels des ensembles cibles, les preuves pertinentes des droits locaux et le résultat fonctionnel. Une exception doit identifier l'opération requise, les systèmes concernés, le responsable, les mesures compensatoires et un déclencheur de réexamen. Une permission non résolue ou une cible injoignable reste inconnue.

Définissez les déclencheurs d'un nouvel examen : nouvel hôte du fournisseur, système de site, attribution de collection, identité d'installation ou niveau de confiance géré. Une décision sur la frontière reste défendable uniquement tant que la cartographie d'autorité qui la justifie correspond à l'environnement déployé.

Comment EtcSec détecte ce cas

Le contrôle etc-collector examiné est ANSSI_R49_R50_MGMT_CATEGORIZATION, au commit du collecteur 15fc6399c215eabc415c370b762303cfcd7a353a. Il s'agit d'une heuristique d'inventaire et de nommage, pas d'un audit des autorisations Configuration Manager.

Un ordinateur devient candidat lorsque son DN correspond à une entrée du paramètre facultatif mgmt_systems, ou lorsque la combinaison en minuscules de SAMAccountName, DNSHostName, Description et OperatingSystem contient l'un de ces marqueurs : sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack ou sentinelone.

Il produit un constat pour les candidats dont le DN en minuscules ne contient aucun de ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt ou ou=management. Ce sont des tests de sous-chaînes, pas une validation des contrôles réels d'une OU. Si aucun candidat n'échoue à ce test, Detect() renvoie nil.

La liste facultative mgmt_systems provient de tier0_groups.yaml. Si ce fichier est absent, aucune personnalisation n'est chargée, la liste est vide et seules les heuristiques de nom s'appliquent, sans avertissement. Si le fichier est illisible ou son YAML mal formé, le moteur écrit un avertissement sur stderr et poursuit avec les valeurs par défaut. Une entrée DN explicite ajoute un candidat ; elle n'établit pas l'autorité du produit et ne remplace pas le test de sous-chaînes sur l'OU.

Le fournisseur LDAP fournit les champs d'inventaire des ordinateurs. Ce contrôle ne collecte aucune permission SMS Provider, autorité sur la base de données du site, attribution RBAC, collection cible ni aucun droit de compte d'installation. Un nom de client peut correspondre ; un système de gestion réellement puissant peut être manqué ; un nom d'OU peut satisfaire le test de sous-chaînes sans imposer l'isolation.

Utilisez le constat pour commencer l'examen de l'autorité. Résolvez la question architecturale avec les preuves du produit et des cibles dans la matrice, en conservant les inconnues et les exceptions même lorsque l'heuristique de nommage ne signale plus de constat.