Knowledge · Sécurité · ConfigMgr · Active Directory
Client push automatique de Configuration Manager : faille NTLM, KB15599094, désactiver, sécuriser ou remplacer ?
Désactiver le client push automatique : ce que ça règle, ce que ça ne règle pas, et ce qu'on met à la place.
Un test d'intrusion demande parfois de désactiver le client push automatique de Configuration Manager, et Microsoft le classe comme la méthode d'installation la moins sûre. L'alerte est fondée : avec un simple compte de domaine, un attaquant peut forcer le serveur de site à s'authentifier en NTLM vers sa machine, puis relayer cette authentification. Mais désactiver seulement le mode automatique a peu d'intérêt, parce que le compte d'installation reste utilisé par le push manuel, et les alternatives (GPO, point de mise à jour, Intune, installation manuelle) ont chacune leurs failles et leurs coûts. Cet article explique le mécanisme, ce que chaque choix règle ou non, et le critère qui permet de trancher. Il se termine par un script d'audit en lecture seule, à lire et à copier.
En bref
Désactiver seulement le push automatique, c'est fermer une porte et laisser la clé sous le paillasson.
- Le risque est réel et reproductible. Avec le push automatique, le serveur de site tente d'installer le client sur tout ordinateur découvert. Un attaquant qui détourne cette connexion obtient une authentification NTLM réutilisable. Deux attaques sont décrites : l'une par un faux appareil enregistré auprès du point de gestion, l'autre par un faux compte ordinateur découvert par Active Directory.
- Le NTLM est le cœur du problème. Désactiver le repli NTLM, avec le correctif, supprime cette coercition. Ce qui reste : le compte de push, administrateur local de toutes les cibles, que tout push (automatique ou manuel) utilise.
- Aucune alternative n'est sans faille. GPO, point de mise à jour, Intune et installation manuelle déplacent le risque (Active Directory, WSUS, périmètre réseau, erreur humaine) sans le supprimer.
- Le critère est le nombre de postes à installer par push. Très peu : tout désactiver. Une centaine : un push automatique sécurisé, avec risques acceptés formellement, est défendable.
La recommandation, en deux choix cohérents
1. Sécuriser le push
Désactiver le repli NTLM (avec le correctif), vérifier si la PKI est exigée, bloquer le NTLM sortant du serveur de site, durcir les comptes, Active Directory et les systèmes de site. Les barrières sont détaillées plus bas, dans l'ordre.
2. Désactiver tout push
Désactiver le mode automatique et le mode manuel, retirer les comptes de push, et choisir une autre méthode d'installation. C'est le seul choix qui supprime le compte de push.
Les deux attaques exigent le mode automatique : le désactiver les ferme. Mais le compte d'installation reste configuré et reste utilisé par chaque push manuel. Si le but est de retirer l'administrateur local partout, il faut renoncer aux deux modes ; si le but est seulement de fermer la coercition, couper le repli NTLM avec le correctif la ferme aussi, sans rien changer à la façon d'installer.
Le risque
Un serveur de site qui s'authentifie auprès de tout ordinateur découvert, et qu'on peut amener à choisir lequel.
Avec le client push, le serveur de site se connecte au partage ADMIN$ de la cible pour y copier et lancer l'installation. Il s'authentifie avec les comptes de push configurés, puis avec son propre compte machine s'ils échouent. Si le site ne peut pas joindre la cible, il réessaie toutes les heures, pendant sept jours au plus. Selon la documentation de Microsoft, le client push est la méthode d'installation la moins sûre, à cause de ses nombreuses dépendances (droits d'administrateur local, partage ADMIN$, exceptions de pare-feu) qui élargissent la surface d'attaque.
L'attaque consiste à amener le serveur de site à « pousser » vers une machine contrôlée par l'attaquant. Celle-ci reçoit alors une authentification NTLM qu'elle peut relayer vers un autre service. Chaque attaque exige que toutes ses conditions soient réunies : il suffit qu'une seule soit absente pour la bloquer, et c'est ce qui rend les barrières de la section suivante utiles chacune isolément.
Les conditions communes aux deux attaques
- Le push automatique est actif.
- L'affectation automatique de site est active.
- Le repli NTLM est actif (ou le correctif est absent).
- Le NTLM sortant n'est pas restreint depuis le serveur de site.
- L'attaquant dispose d'un compte de domaine ordinaire, et de rien de plus.
Ce qui distingue les deux attaques
| Attaque par faux appareil | Attaque par faux compte ordinateur | |
|---|---|---|
| Déclencheur | L'enregistrement d'un faux appareil auprès du point de gestion. | Un compte ordinateur créé dans Active Directory et découvert par l'AD System Discovery, avec un enregistrement DNS. |
| Condition propre | La PKI n'est pas exigée pour l'authentification des clients. | AD System Discovery actif, et possibilité de créer un compte ordinateur (MachineAccountQuota supérieur à 0). |
Ce que l'attaquant gagne
- Le compte de push, relayé, ouvre le mouvement latéral. Il est administrateur local de toutes les cibles, et souvent bien plus privilégié que nécessaire : il arrive qu'on l'ajoute à un groupe d'administrateurs du domaine « pour que ça marche ».
- Le compte machine du serveur de site, relayé vers la base de site (MSSQL) ou vers AD CS, peut mener au rôle Full Administrator de Configuration Manager, donc à l'exécution de code sur tous les clients.
Avant le correctif KB15599094 (CVE-2022-37972), le compte de push tentait une connexion NTLM pour lire le résultat d'une requête WMI sur la cible, même quand « Allow connection fallback to NTLM » était décochée (uniquement pour les ordinateurs d'un domaine de confiance). Décocher la case ne suffisait donc pas. Microsoft publie ce correctif pour les versions 2103 à 2207 et précise qu'il remplace KB15498768 ; sur une version plus ancienne, il faut d'abord mettre à jour ; sur une version plus récente que 2207, vérifiez dans les notes de version que le comportement est bien inclus.
Aucune statistique d'incident réel attribué au client push automatique n'a été trouvée : l'argument est la reproductibilité de l'attaque avec un compte ordinaire, pas une fréquence observée. C'est une nuance utile pour une acceptation de risque : le risque est faible en probabilité observée, mais son coût (la prise de contrôle de tous les clients) est maximal.
Ce qui réduit le risque
Cinq barrières, chacune bloque une partie des conditions, aucune ne fait tout.
| Barrière | Ferme | Limite à connaître |
|---|---|---|
| Repli NTLM désactivé, avec le correctif | Les deux attaques | Les postes hors forêt de confiance ou en groupe de travail ne sont plus installables par push (Kerberos suppose Active Directory). Ne change pas le compte de push. |
| NTLM sortant refusé depuis le serveur de site | Les deux attaques | À auditer d'abord : des flux légitimes peuvent en dépendre. |
| PKI exigée (HTTPS uniquement) | L'attaque par faux appareil | Un poste sans certificat ne peut pas s'enregistrer. Mais si l'émission des certificats n'est pas maîtrisée (auto-inscription ouverte aux ordinateurs du domaine) et que le domaine n'est pas durci (MachineAccountQuota supérieur à 0), un attaquant qui joint une machine obtient son certificat. Les certificats doivent aussi exister avant le client, y compris en séquence de tâches. Le mode HTTP amélioré (eHTTP) n'impose pas de PKI. |
| Active Directory durci (MachineAccountQuota à 0, DNS, AD System Discovery limitée) | L'attaque par faux compte ordinateur | Conditionne aussi la valeur de la PKI et des GPO. |
| Push automatique désactivé | Les deux attaques | Voir la section suivante : le compte de push reste. |
Exiger des certificats donne l'impression de fermer la porte à tout appareil inconnu. C'est vrai seulement si l'émission des certificats l'est aussi : si n'importe quel ordinateur du domaine peut s'en inscrire un, et que n'importe quel utilisateur peut joindre un ordinateur (MachineAccountQuota par défaut), l'attaquant obtient son certificat en deux étapes. La PKI et le durcissement d'Active Directory se tiennent l'un l'autre.
Ce que « désactiver » règle
Trois façons de « désactiver », trois résultats différents.
| Choix | Coercition NTLM | Compte de push (administrateur local partout) |
|---|---|---|
| Push automatique sécurisé | Fermée si le repli NTLM est coupé, avec le correctif. | Reste, utilisé à chaque installation. |
| Automatique désactivé, push manuel gardé | Fermée : les deux attaques exigent le mode automatique. | Reste, utilisé à chaque push manuel. |
| Tout push désactivé | Fermée. | Supprimé. Microsoft indique que désactiver les modes automatique et manuel supprime l'exposition. |
Désactiver seulement l'automatique répond donc au constat du test d'intrusion sur la coercition, mais ne supprime pas le compte de push. Le supprimer impose de renoncer à tout push, donc de choisir une autre méthode d'installation. C'est là que les ennuis commencent.
Les alternatives
Chaque option déplace le risque ; aucune ne le supprime.
Microsoft juge la GPO et l'installation par mise à jour logicielle (point de mise à jour) plus sûres que le client push pour des postes du domaine. C'est exact, mais à une condition : qu'Active Directory, ou le point de mise à jour, soit lui-même durci. Le tableau compare ce que chaque option apporte et ce qu'elle coûte.
| Option | Failles de sécurité | Problèmes pratiques | Postes isolés / hors domaine |
|---|---|---|---|
| GPO | La sécurité devient celle d'Active Directory : qui peut éditer la GPO, son lien ou le partage d'installation exécute du code en SYSTEM sur le périmètre. Avec MachineAccountQuota supérieur à 0, un attaquant joint une machine qui reçoit la GPO. SYSVOL est lisible par tous les utilisateurs authentifiés. | L'équipe de Configuration Manager doit pouvoir gérer des GPO (organisation). Disparaît avec des postes uniquement Entra ID. Le MSI n'accepte aucun paramètre. | Domaine seulement. |
| Point de mise à jour (SUP/WSUS) | Surface d'attaque en soi. En HTTP (port 8530 par défaut), un attaquant en position d'homme du milieu injecte une mise à jour exécutée en SYSTEM (WSUSpect, PyWSUS). Même en HTTPS, les attaques restent possibles s'il obtient un certificat de confiance. | Impose une GPO WSUS sur les postes, en conflit possible avec les stratégies de mise à jour d'Intune. Client à republier à chaque version. Il faut le point de mise à jour actif du site, pas un WSUS séparé. | Domaine seulement. |
| Intune | Peu de failles propres (ni compte stocké, ni port entrant) ; dépend de la sécurité d'Intune et de l'enrôlement. | Client traditionnel : l'appareil doit être sur l'intranet et dans une limite du site, donc une application qui n'aboutit que sur le réseau local. Hors réseau : passerelle de gestion cloud (CMG) et identité Entra ID, à déployer. | Non : inutile pour les postes non enrôlés. |
| Push manuel | Mêmes comptes et même exposition que le push automatique, mais non déclenchable par un attaquant d'après les prérequis documentés. | Charge manuelle, poste par poste. | Si le poste est joint au domaine. |
| Installation manuelle | Exige un administrateur local sur chaque poste (identifiants exposés en session interactive ou RDP) ; erreur humaine ; pas de traçabilité automatique. | Contourne l'outil de gestion ; ne tient pas à l'échelle (tickets). | Oui. |
Les questions à trancher avant de remplacer le push
Chaque alternative est une décision d'organisation autant que de sécurité. Voici celles qui reviennent presque toujours.
GPO
Qui crée et maintient la GPO, quand l'équipe n'est pas celle de Configuration Manager ? Sur quel périmètre : tout le domaine ou une OU ? Le poste doit se trouver dans l'OU ciblée pour recevoir le client : quel processus l'y place ? Qui a le droit d'éditer la GPO et le partage d'installation, sachant que c'est de l'exécution de code sur tout le périmètre ? Et la GPO recule avec Entra ID.
WSUS / point de mise à jour
Il faut un serveur à monter (ou un point de mise à jour exposé à des postes non gérés). Qui l'entretient, le met à jour, le durcit, le sécurise ? En HTTP, une mise à jour est injectable ; l'HTTPS est à gérer. Et la GPO WSUS requise peut entrer en conflit avec les stratégies de mise à jour d'Intune.
Intune
L'application ne doit être lancée que sur le réseau d'entreprise (intranet et limite du site) : la détection du réseau d'entreprise doit donc être fiable, surtout derrière un accès réseau sécurisé cloud. Les postes non enrôlés (OT, industriels) ne sont pas couverts. L'application est à maintenir à chaque version.
Bien mises en œuvre, ces options peuvent être plus sûres que le push. Mais elles demandent du temps, des équipes et un durcissement à planifier. Sans cela, elles n'apportent pas nécessairement plus de sécurité qu'un push durci, et peuvent en apporter moins : on a seulement changé de surface d'attaque.
Le critère de décision
Le nombre de postes à installer par push tranche plus sûrement que la théorie.
Plus le volume est faible, plus l'installation sans push se défend : le coût humain reste petit. Plus il est élevé, plus l'automatisation sécurisée devient raisonnable : les installations à la main génèrent des tickets en nombre et leurs propres erreurs.
| Postes à installer par push | Choix cohérent |
|---|---|
| Aucun, ou quelques-uns par an | Tout push désactivé ; installation manuelle documentée pour les postes particuliers (OT). |
| Quelques-uns par mois | Push manuel ciblé, repli NTLM coupé, comptes à périmètre limité. |
| Plusieurs dizaines par mois, ou une centaine | Push automatique sécurisé, risques résiduels acceptés formellement. |
Ces seuils relèvent d'un jugement et sont à ajuster : aucun seuil publié n'a été trouvé, ni chez Microsoft ni dans la littérature technique consultée. Ce qui compte est le principe : comparer le risque résiduel d'un push sécurisé au coût et aux risques de l'alternative réellement praticable chez vous.
Mesurer et nettoyer d'abord
Avant de décider, comptez. Combien de postes sont sans client ? Parmi eux, combien sont actifs et récents ? Combien le push en équipe-t-il réellement ? Les objets périmés gonflent le volume apparent et la surface exposée : un appareil disparu depuis un an reste une cible potentielle du serveur de site tant que sa découverte l'y maintient.
La trajectoire : le risque du push est transitoire
Pour des postes uniquement Entra ID, ni le push ni les GPO ne s'appliquent (il n'y a pas de domaine) : le client s'installe par la cogestion Intune. Dans une flotte qui migre vers Entra ID, le volume de postes à installer par push décroît de lui-même, et l'acceptation de risque peut être datée en conséquence.
Sécuriser le push
Huit barrières, dans l'ordre, et les risques qui restent.
Si le volume justifie de conserver le push automatique, c'est défendable à condition de le sécuriser et d'en accepter formellement les risques. Les barrières 1 à 3 viennent surtout de la documentation Microsoft ; les suivantes sont des recommandations de durcissement d'auditeur (issues de la littérature technique publique) : elles réduisent la surface sans qu'aucune norme ne les impose.
- Repli NTLM désactivé, et correctif présent. Console : Administration > Configuration du site > Sites > Paramètres d'installation du client > Installation Push du client, décocher « Allow connection fallback to NTLM ». Confirmer KB15599094 (versions 2103 à 2207) ou une version qui l'intègre, et tester sur une collection pilote. C'est la mesure principale : elle couvre les deux attaques. Elle est désactivée par défaut sur les nouveaux sites depuis la version 2207, mais un site plus ancien conserve son réglage d'origine.
- NTLM sortant refusé depuis le serveur de site, par la stratégie « Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers ». Audit d'abord, pour voir ce qui dépend encore du NTLM ; puis « Deny all », avec des exceptions testées.
- PKI exigée pour les clients (propriétés du site, sécurité des communications, « HTTPS uniquement »), à condition de maîtriser l'émission des certificats : gabarit réservé aux machines gérées, auto-inscription non ouverte à tout ordinateur du domaine, MachineAccountQuota à 0. Sinon elle n'arrête pas un attaquant qui joint une machine.
- Active Directory. MachineAccountQuota à 0 avec jonction déléguée ; AD System Discovery limitée aux OU gérées ; création d'enregistrements DNS restreinte.
- Comptes de push. Jamais dans un groupe privilégié : administrateur local des cibles uniquement (Microsoft préconise un groupe global ajouté au groupe des administrateurs locaux par une GPO « Restricted Group »). Plusieurs comptes à périmètre limité, pour qu'une compromission n'expose qu'une partie du parc ; secret aléatoire d'au plus 38 caractères (la limite de la console), sans SPN, sans connexion interactive ni RDP, distincts du compte d'accès réseau.
- Systèmes de site. Signature SMB exigée partout ; EPA (protection étendue pour l'authentification) obligatoire et chiffrement forcé sur la base SQL de site et sur AD CS ; service WebClient retiré du serveur de site. Ces mesures couvrent les autres moyens de forcer une authentification du serveur de site, qui existent indépendamment du push.
- Périmètre. Postes de travail seulement (ni contrôleurs de domaine, ni serveurs de site) ; groupes de limites avec affectation de site réduits au strict nécessaire ; objets Active Directory périmés supprimés.
- Détection. Alerter sur les ouvertures de session réseau (événement 4624, type 3) du compte de push et du compte machine du serveur de site dont la source n'est pas le serveur de site : c'est la trace d'un relais.
Les risques résiduels à accepter
- Le compte de push reste administrateur local de toutes les cibles : une compromission du serveur de site l'expose.
- Une régression de configuration rouvre l'attaque : case « repli NTLM » recochée, correctif absent après une restauration du site.
- Une faille encore inconnue reste possible : le réglage NTLM a déjà été contourné avant correctif.
- Le constat du test d'intrusion reste ouvert tant qu'il n'est ni corrigé ni accepté formellement ; prévoir une revue périodique de l'acceptation (trimestrielle, par exemple).
Si le volume est quasi nul, ou si ces barrières sont impossibles à tenir, désactivez tout push (automatique et manuel) et retirez les comptes de push. Désactiver seulement l'automatique répond au test d'intrusion sur la coercition, mais laisse le compte de push.
Mesurer avant de décider
Un script en lecture seule relève ce dont la décision dépend.
Le critère du volume suppose de savoir combien de postes le push équipe réellement, et dans quel état est la configuration. Le script d'audit de la section suivante le relève sans rien modifier. Il se lance sur le serveur de site, dans un PowerShell administrateur (version 5.1 au moins), et produit un rapport HTML autonome : sans ressource externe, imprimable.
Unblock-File .\Audit-MECM-ClientPush.ps1 .\Audit-MECM-ClientPush.ps1 -OutputPath C:\Temp
Ce que le rapport contient
- La version du site et les correctifs NTLM (KB15599094, KB15498768), les paramètres d'installation du client, les comptes de push et leur exposition dans Active Directory.
- Les méthodes de découverte, les groupes de limites, le parc avec et sans client, l'activité du push (file de reprise,
ccm.log) et, dans la base de site, l'historique des demandes de push : combien de postes ont été installés par push, une estimation de la part automatique, le rythme mensuel. - Le durcissement des systèmes de site (signature SMB, NTLM sortant, WebClient, EPA sur SQL) et MachineAccountQuota.
- Une conclusion : un niveau d'exposition (réduite, moyenne, élevée ou indéterminée), une décision sur le push automatique, un plan d'action priorisé et les alternatives.
Les options
-LogDays et -MaxLogMB bornent la lecture des journaux ; -SkipLogs, -SkipSql, -SkipRemoteChecks et -SkipActiveDirectory écartent respectivement les journaux, la base de site, les autres systèmes de site et Active Directory ; -ExportCsv écrit aussi la liste des demandes de push. Quatre déclarations, -ConfirmAutoPush, -ConfirmNtlmFallback, -ConfirmHotfix et -ConfirmHttpsOnly (valeurs Oui ou Non), servent aux réglages que le script ne sait pas lire de façon fiable.
Microsoft ne documente pas les noms de propriétés WMI des paramètres du push : le script affiche toujours les valeurs brutes et signale toute interprétation heuristique. Relisez le premier rapport et confirmez à la main ce qu'il ne sait pas lire. Ses requêtes WMI, LDAP et SQL laissent des traces dans les journaux : prévenez les équipes de sécurité avant de le lancer. Droits conseillés : le rôle « Analyste en lecture seule » de Configuration Manager (ou plus), administrateur local du serveur de site pour lire les journaux et le registre, lecture dans Active Directory, et lecture des vues de la base de site (db_datareader) pour l'historique du push.
Le plan d'action
Mesurer, durcir, choisir, faire re-tester.
- Mesurer les postes sans client (récents, périmés, systèmes anciens) et le volume réel installé par push.
- Relever la configuration actuelle avec le script d'audit : push automatique, repli NTLM, correctif, PKI exigée ou non, comptes de push et leurs groupes.
- Désactiver le repli NTLM et confirmer le correctif, d'abord sur une collection pilote.
- Auditer, puis bloquer, le NTLM sortant du serveur de site.
- Durcir les comptes de push, Active Directory et les systèmes de site ; décider de la PKI.
- Mettre en place la détection.
- Choisir : conserver et sécuriser le push automatique (avec une acceptation de risque), ou désactiver tout push.
- Faire re-tester le point par l'équipe qui l'a relevé.
Les requêtes de relevé de configuration (WMI, LDAP) laissent des traces dans les journaux : prévenez les équipes de sécurité avant de les lancer, sous peine de déclencher une alerte qui n'a rien d'une attaque. Et testez chaque durcissement sur une collection pilote : un blocage NTLM trop large coupe aussi des flux légitimes.
Le code
Le script d'audit, en entier.
Découpé en sections, chacune expliquée en une phrase. Tout est en clair : pas de bloc encodé, pas de téléchargement. Copiez-le, enregistrez-le sous Audit-MECM-ClientPush.ps1, et lisez-le avant de le lancer. Vous pouvez l'adapter à votre parc ou à celui d'un client, pas le republier : voir les conditions d'utilisation.
Ce script ne modifie rien sur le système : il lit. Mais il interroge WMI, Active Directory, le serveur SQL de site et des journaux, et ces requêtes laissent des traces. Prévenez vos équipes de sécurité, essayez-le d'abord avec -SkipSql et -SkipRemoteChecks si vous voulez limiter ce qu'il touche, et relisez le premier rapport avant d'en tirer une conclusion. Ce que vous en faites ensuite est votre décision.
Audit-MECM-ClientPush.ps1
Cet article vous a-t-il aidé ?
Votre avis est compté sans vous identifier : ni compte, ni cookie, ni commentaire — seul le sens du vote.
Sources
- Deploy clients to Windows computers — le client push, la case « Allow connection fallback to NTLM » (depuis 1806, désactivée par défaut sur les nouveaux sites depuis 2207), les autres méthodes d'installation.
- Security and privacy for Configuration Manager clients — la hiérarchie des méthodes d'installation, et comment sécuriser le compte de push.
- NTLM client installation update (KB15599094) — versions 2103 à 2207, remplace KB15498768, désactiver les deux modes de push supprime l'exposition.