Knowledge · Security · ConfigMgr · Active Directory
Automatic client push in Configuration Manager: NTLM flaw, KB15599094, disable, secure or replace?
Disabling automatic client push: what it fixes, what it does not, and what goes in its place.
A penetration test sometimes asks for automatic client push in Configuration Manager to be disabled, and Microsoft ranks it as the least secure installation method. The alert is sound: with an ordinary domain account, an attacker can force the site server to authenticate over NTLM to their machine, then relay that authentication. But disabling only the automatic mode achieves little, because the installation account is still used by manual push, and the alternatives (Group Policy, software update point, Intune, manual installation) each have their own flaws and costs. This article explains the mechanism, what each choice fixes or not, and the criterion that settles the decision. It ends with a read-only audit script, to read and copy.
In short
Disabling only automatic push closes a door and leaves the key under the mat.
- The risk is real and reproducible. With automatic push, the site server tries to install the client on every discovered computer. An attacker who hijacks that connection gets a reusable NTLM authentication. Two attacks are described: one through a fake device registered with the management point, the other through a fake computer account found by Active Directory.
- NTLM is the heart of the problem. Disabling NTLM fallback, with the hotfix, removes that coercion. What remains: the push account, local administrator on every target, which every push (automatic or manual) uses.
- No alternative is flawless. Group Policy, update point, Intune and manual installation move the risk (Active Directory, WSUS, network perimeter, human error) without removing it.
- The criterion is how many devices you install by push. Very few: disable everything. About a hundred: secured automatic push, with formally accepted risks, is defensible.
The recommendation, as two consistent choices
1. Secure push
Disable NTLM fallback (with the hotfix), check whether PKI is required, block outbound NTLM from the site server, harden the accounts, Active Directory and the site systems. The barriers are detailed below, in order.
2. Disable all push
Disable the automatic and the manual mode, remove the push accounts, and choose another installation method. This is the only choice that removes the push account.
Both attacks need the automatic mode: disabling it closes them. But the installation account stays configured and is still used by every manual push. If the goal is to remove the local administrator everywhere, you have to give up both modes; if the goal is only to close the coercion, cutting NTLM fallback with the hotfix closes it as well, without changing how you install.
The risk
A site server that authenticates to every discovered computer, and can be made to choose which one.
With client push, the site server connects to the target's ADMIN$ share to copy and launch the installation. It authenticates with the configured push accounts, then with its own machine account if they fail. If the site cannot reach the target, it retries every hour, for up to seven days. According to Microsoft's documentation, client push is the least secure installation method, because of its many dependencies (local administrator rights, the ADMIN$ share, firewall exceptions) which widen the attack surface.
The attack consists in getting the site server to « push » to a machine the attacker controls. That machine then receives an NTLM authentication which it can relay to another service. Each attack needs all of its conditions to be met: a single missing one blocks it, which is what makes each barrier in the next section useful on its own.
The conditions shared by both attacks
- Automatic push is enabled.
- Automatic site assignment is enabled.
- NTLM fallback is enabled (or the hotfix is missing).
- Outbound NTLM is not restricted from the site server.
- The attacker has an ordinary domain account, and nothing more.
What sets the two attacks apart
| Fake-device attack | Fake-computer-account attack | |
|---|---|---|
| Trigger | Registering a fake device with the management point. | A computer account created in Active Directory and found by AD System Discovery, with a DNS record. |
| Own condition | PKI is not required for client authentication. | AD System Discovery enabled, and the ability to create a computer account (MachineAccountQuota above 0). |
What the attacker gains
- The push account, relayed, opens lateral movement. It is local administrator on all the targets, and often far more privileged than necessary: it is sometimes added to a domain administrators group « to make it work ».
- The site server's machine account, relayed to the site database (MSSQL) or to AD CS, can lead to the Full Administrator role in Configuration Manager, hence to code execution on every client.
Before hotfix KB15599094 (CVE-2022-37972), the push account attempted an NTLM connection to read the result of a WMI query on the target, even when « Allow connection fallback to NTLM » was unchecked (only for computers in a trusted domain). Unchecking the box was therefore not enough. Microsoft publishes this hotfix for versions 2103 to 2207 and states that it replaces KB15498768; on an older version you must update first; on a version newer than 2207, check in the release notes that the behaviour is included.
No statistics of a real incident attributed to automatic client push were found: the argument is the reproducibility of the attack with an ordinary account, not an observed frequency. That is a useful nuance for a risk acceptance: the observed probability is low, but the cost (taking control of every client) is maximal.
What reduces the risk
Five barriers, each blocks some of the conditions, none does everything.
| Barrier | Closes | Limit to know |
|---|---|---|
| NTLM fallback disabled, with the hotfix | Both attacks | Computers outside a trusted forest or in a workgroup can no longer be installed by push (Kerberos relies on Active Directory). Does not change the push account. |
| Outbound NTLM denied from the site server | Both attacks | Audit first: legitimate flows may depend on it. |
| PKI required (HTTPS only) | The fake-device attack | A device without a certificate cannot register. But if certificate issuance is not controlled (auto-enrolment open to domain computers) and the domain is not hardened (MachineAccountQuota above 0), an attacker who joins a machine gets a certificate. Certificates must also exist before the client, including in a task sequence. Enhanced HTTP (eHTTP) does not enforce PKI. |
| Hardened Active Directory (MachineAccountQuota at 0, DNS, limited AD System Discovery) | The fake-computer-account attack | Also determines the value of PKI and of Group Policy. |
| Automatic push disabled | Both attacks | See the next section: the push account stays. |
Requiring certificates feels like closing the door to every unknown device. That is true only if certificate issuance is closed too: if any domain computer can enrol one, and any user can join a computer (default MachineAccountQuota), the attacker gets their certificate in two steps. PKI and Active Directory hardening hold each other up.
What « disabling » fixes
Three ways to « disable », three different outcomes.
| Choice | NTLM coercion | Push account (local administrator everywhere) |
|---|---|---|
| Secured automatic push | Closed if NTLM fallback is cut, with the hotfix. | Stays, used at every installation. |
| Automatic disabled, manual push kept | Closed: both attacks need the automatic mode. | Stays, used at every manual push. |
| All push disabled | Closed. | Removed. Microsoft states that disabling the automatic and manual modes removes the exposure. |
Disabling only the automatic mode therefore answers the penetration test finding about coercion, but does not remove the push account. Removing it means giving up all push, hence choosing another installation method. That is where the trouble starts.
The alternatives
Every option moves the risk; none removes it.
Microsoft considers Group Policy and software update-based installation (update point) more secure than client push for domain computers. That is right, on one condition: that Active Directory, or the update point, is itself hardened. The table compares what each option brings and what it costs.
| Option | Security flaws | Practical problems | Isolated / non-domain devices |
|---|---|---|---|
| Group Policy | Security becomes that of Active Directory: whoever can edit the GPO, its link or the installation share runs code as SYSTEM across the scope. With MachineAccountQuota above 0, an attacker joins a machine that receives the GPO. SYSVOL is readable by every authenticated user. | The Configuration Manager team must be able to manage GPOs (organisation). Disappears with Entra-only devices. The MSI accepts no parameters. | Domain only. |
| Software update point (SUP/WSUS) | An attack surface in itself. Over HTTP (port 8530 by default), a man-in-the-middle attacker injects an update run as SYSTEM (WSUSpect, PyWSUS). Even over HTTPS, attacks remain possible if they obtain a trusted certificate. | Requires a WSUS GPO on the devices, possibly conflicting with Intune update policies. The client must be republished at each version. It must be the site's active software update point, not a separate WSUS. | Domain only. |
| Intune | Few flaws of its own (no stored account, no inbound port); depends on the security of Intune and of enrolment. | Traditional client: the device must be on the intranet and within a site boundary, so an app that only succeeds on the local network. Off-network: a cloud management gateway (CMG) and Entra ID identity, to be deployed. | No: useless for non-enrolled devices. |
| Manual push | Same accounts and same exposure as automatic push, but not triggerable by an attacker according to the documented prerequisites. | Manual workload, device by device. | If the device is domain-joined. |
| Manual installation | Needs a local administrator on every device (credentials exposed in an interactive or RDP session); human error; no automatic traceability. | Bypasses the management tool; does not scale (tickets). | Yes. |
The questions to settle before replacing push
Each alternative is an organisational decision as much as a security one. These are the ones that almost always come up.
Group Policy
Who creates and maintains the GPO when the team is not the Configuration Manager one? On what scope: the whole domain or an OU? The device must sit in the targeted OU to get the client: what process puts it there? Who may edit the GPO and the installation share, knowing it is code execution across the whole scope? And Group Policy is receding with Entra ID.
WSUS / update point
A server has to be built (or an update point exposed to unmanaged devices). Who maintains it, updates it, hardens it, secures it? Over HTTP, an update can be injected; HTTPS is yours to manage. And the required WSUS GPO may conflict with Intune update policies.
Intune
The app must only run on the corporate network (intranet and site boundary), so corporate-network detection has to be reliable, especially behind a cloud secure access service. Non-enrolled devices (OT, industrial) are not covered. The app must be maintained at every version.
Well implemented, these options can be safer than push. But they take time, teams and hardening that has to be planned. Without that, they do not necessarily bring more security than a hardened push, and may bring less: you have only changed the attack surface.
The decision criterion
The number of devices installed by push settles it more reliably than theory.
The lower the volume, the easier it is to defend installing without push: the human cost stays small. The higher it is, the more reasonable secured automation becomes: manual installations generate tickets in numbers and their own errors.
| Devices installed by push | Consistent choice |
|---|---|
| None, or a few per year | All push disabled; documented manual installation for special devices (OT). |
| A few per month | Targeted manual push, NTLM fallback cut, accounts with a limited scope. |
| Several dozen per month, or about a hundred | Secured automatic push, residual risks formally accepted. |
These thresholds are a judgement and should be adjusted: no published threshold was found, at Microsoft or in the technical literature consulted. What matters is the principle: compare the residual risk of a secured push with the cost and risks of the alternative that is really practicable in your environment.
Measure and clean up first
Before deciding, count. How many devices have no client? Of those, how many are active and recent? How many does push really equip? Stale objects inflate the apparent volume and the exposed surface: a device that disappeared a year ago remains a potential target for the site server as long as discovery keeps it there.
The trajectory: the push risk is transitional
For Entra-only devices, neither push nor Group Policy applies (there is no domain): the client is installed through Intune co-management. In a fleet migrating to Entra ID, the volume of devices to install by push shrinks by itself, and the risk acceptance can be dated accordingly.
Securing push
Eight barriers, in order, and the risks that remain.
If the volume justifies keeping automatic push, it is defensible provided it is secured and its risks are formally accepted. Barriers 1 to 3 come mostly from Microsoft documentation; the following ones are auditor hardening recommendations (drawn from public technical literature): they reduce the surface without any standard requiring them.
- NTLM fallback disabled, and the hotfix in place. Console: Administration > Site Configuration > Sites > Client Installation Settings > Client Push Installation, untick « Allow connection fallback to NTLM ». Confirm KB15599094 (versions 2103 to 2207) or a version that includes it, and test on a pilot collection. This is the main measure: it covers both attacks. It is off by default on new sites since version 2207, but an older site keeps its original setting.
- Outbound NTLM denied from the site server, with the policy « Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers ». Audit first, to see what still depends on NTLM; then « Deny all », with tested exceptions.
- PKI required for clients (site properties, communication security, « HTTPS only »), provided certificate issuance is controlled: a template reserved for managed machines, auto-enrolment not open to every domain computer, MachineAccountQuota at 0. Otherwise it does not stop an attacker who joins a machine.
- Active Directory. MachineAccountQuota at 0 with delegated join; AD System Discovery limited to managed OUs; DNS record creation restricted.
- Push accounts. Never in a privileged group: local administrator on the targets only (Microsoft recommends a global group added to the local administrators group by a « Restricted Group » GPO). Several accounts with a limited scope, so that a compromise exposes only part of the estate; a random secret of at most 38 characters (the console limit), no SPN, no interactive or RDP sign-in, distinct from the network access account.
- Site systems. SMB signing required everywhere; EPA (Extended Protection for Authentication) mandatory and encryption forced on the site SQL database and on AD CS; WebClient service removed from the site server. These measures cover the other ways of forcing an authentication from the site server, which exist independently of push.
- Scope. Workstations only (no domain controllers, no site servers); boundary groups with site assignment reduced to the strict minimum; stale Active Directory objects removed.
- Detection. Alert on network sign-ins (event 4624, type 3) of the push account and of the site server's machine account whose source is not the site server: that is the trace of a relay.
The residual risks to accept
- The push account remains local administrator on every target: a compromise of the site server exposes it.
- A configuration regression reopens the attack: the « NTLM fallback » box ticked again, hotfix missing after a site restore.
- A still unknown flaw remains possible: the NTLM setting has already been bypassed before the hotfix.
- The penetration test finding remains open as long as it is neither fixed nor formally accepted; plan a periodic review of the acceptance (quarterly, for example).
If the volume is almost nil, or if these barriers cannot be maintained, disable all push (automatic and manual) and remove the push accounts. Disabling only the automatic mode answers the penetration test about coercion, but leaves the push account.
Measure before deciding
A read-only script records what the decision depends on.
The volume criterion assumes you know how many devices push really equips, and what state the configuration is in. The audit script in the next section records it without changing anything. It runs on the site server, in an elevated PowerShell (5.1 at least), and produces a self-contained HTML report: no external resource, printable.
Unblock-File .\Audit-MECM-ClientPush.ps1 .\Audit-MECM-ClientPush.ps1 -OutputPath C:\Temp
What the report contains
- The site version and the NTLM hotfixes (KB15599094, KB15498768), the client installation settings, the push accounts and their exposure in Active Directory.
- The discovery methods, the boundary groups, devices with and without a client, push activity (retry queue,
ccm.log) and, in the site database, the history of push requests: how many devices were installed by push, an estimate of the automatic share, the monthly pace. - Hardening of the site systems (SMB signing, outbound NTLM, WebClient, EPA on SQL) and MachineAccountQuota.
- A conclusion: an exposure level (low, medium, high or undetermined), a decision on automatic push, a prioritised action plan and the alternatives.
The options
-LogDays and -MaxLogMB bound the log reading; -SkipLogs, -SkipSql, -SkipRemoteChecks and -SkipActiveDirectory leave out the logs, the site database, the other site systems and Active Directory respectively; -ExportCsv also writes the list of push requests. Four declarations, -ConfirmAutoPush, -ConfirmNtlmFallback, -ConfirmHotfix and -ConfirmHttpsOnly (values Oui or Non), are for the settings the script cannot read reliably.
Microsoft does not document the WMI property names of the push settings: the script always shows the raw values and flags any heuristic interpretation. Read the first report and confirm by hand what it cannot read. Its WMI, LDAP and SQL queries leave traces in the logs: warn the security teams before running it. Recommended rights: the Configuration Manager « Read-only Analyst » role (or more), local administrator on the site server to read the logs and the registry, read access to Active Directory, and read access to the site database views (db_datareader) for the push history.
The action plan
Measure, harden, choose, have it re-tested.
- Measure the devices with no client (recent, stale, old systems) and the volume really installed by push.
- Record the current configuration with the audit script: automatic push, NTLM fallback, hotfix, PKI required or not, push accounts and their groups.
- Disable NTLM fallback and confirm the hotfix, first on a pilot collection.
- Audit, then block, outbound NTLM from the site server.
- Harden the push accounts, Active Directory and the site systems; decide about PKI.
- Put detection in place.
- Choose: keep and secure automatic push (with a risk acceptance), or disable all push.
- Have the point re-tested by the team that raised it.
Configuration review queries (WMI, LDAP) leave traces in the logs: warn the security teams before running them, or you will trigger an alert that is not an attack. And test each hardening step on a pilot collection: a NTLM block that is too broad also cuts legitimate flows.
The code
The whole audit script.
Split into sections, each explained in one sentence. Everything is in plain text: no encoded block, no download. Copy it, save it as Audit-MECM-ClientPush.ps1, and read it before you run it. You may adapt it to your estate or to a client's, not republish it: see the terms of use.
This script changes nothing on the system: it reads. But it queries WMI, Active Directory, the site SQL server and logs, and those queries leave traces. Warn your security teams, try it first with -SkipSql and -SkipRemoteChecks if you want to limit what it touches, and read the first report before drawing a conclusion. What you do with it afterwards is your decision.
Audit-MECM-ClientPush.ps1
Did this article help?
Your answer is counted without identifying you: no account, no cookie, no comment — only which way you voted.
Sources
- Deploy clients to Windows computers — client push, the « Allow connection fallback to NTLM » box (since 1806, off by default on new sites since 2207), the other installation methods.
- Security and privacy for Configuration Manager clients — the ranking of installation methods, and how to secure the push account.
- NTLM client installation update (KB15599094) — versions 2103 to 2207, replaces KB15498768, disabling both push modes removes the exposure.