skip to content

NTLM is refused by policy: what has that taken from an intruder who already holds local administrator?

level: middleimportance: should knowfreq 50%

answer

  1. where the control sits versus the privilege
  2. the package cannot be uninstalled
  3. one write, no installer needed
  4. domain policy reapplies on refresh
  5. still blocks everyone below administrator

basics

~20 s

Almost nothing durable. The refusal is a configuration value that the administrator role is allowed to write, and the security package is still installed, so the capability sits inside the privilege the intruder already holds.

solid answer

~50 s

Refusing NTLM by policy is a control aimed at positions *below* administrator - unauthenticated parties on the segment, ordinary user sessions, services running without that privilege. Against someone who already holds local administrator it buys very little, because the setting is a value that role can rewrite and the package it refuses is still installed, so there is nothing to obtain and install first. If the refusal came from domain policy the local change is undone at the next policy refresh, which makes it temporary rather than unavailable, and a position with that privilege can also stop the refresh. The useful way to say this in an interview is that a setting is not a control against a position that already holds the privilege the setting lives inside. It is still a real control against every position that does not.

go deeper

for a junior

Know that a policy setting is a value someone with administrative rights can change back, and that refusing a protocol is not the same as the machine being unable to speak it.

for a middle

Explain the privilege boundary: the setting is guarded by whoever may write it, so it works against lower-privileged positions and not against one that already holds that write.

for a senior

Demonstrate the practical consequence - where removal is impossible, the control becomes the population holding administrative rights and any delegation you granted to a third party.

for a principal

Own the standards question this raises: a hardening item expressed as a setting makes a promise your delegation model may already have broken, and that has to be reconciled deliberately.

## The shape of the answer The question is really about **where a control sits relative to a privilege**. A configuration setting is guarded by whoever is allowed to write it. If the position you are worried about already holds that write, the setting is not a barrier for that position - it is a barrier for everyone else. ## Why NTLM is the sharp example NTLM is a challenge-response authentication package that ships with Windows. Two facts about it drive this whole answer: 1. **You cannot uninstall it.** There is no optional feature to remove. Restriction policies let a host or a domain refuse to accept it, refuse to send it, or audit its use, but the package remains installed and implemented. 2. **It is a negotiated fallback.** Whether it is used is decided per connection, between two ends that both still implement it. Nothing about a refusal is baked into the code; it is consulted each time. Put those together and the honest description is: NTLM is permanently available and currently declined. That is a fundamentally different security posture from a component that has been uninstalled, even though a compliance line reading 'NTLM restricted: yes' looks the same in both cases. ## What the intruder has to do For a position holding local administrator, restoring the fallback is a configuration write. No package to fetch, no installer, no reboot in the usual case. Compare that to a removed component, where the same position must obtain and install software before the capability exists again - still possible for an administrator, but a different class of act with a different cost. If the refusal is delivered by domain policy, one extra wrinkle matters and interviewers like to hear it: **the local change does not stick by itself.** Group policy is reapplied on a refresh cycle, so the domain value returns and overwrites the local edit. That makes the window bounded, not the capability unavailable. A position with administrative rights can also prevent the refresh from landing on that host. So the correct sentence is 'temporary unless they also address the refresh', not 'impossible'. ## The non-malicious version, which is more common The same act happens without an adversary. A vendor's field engineer holds delegated administration over a fleet of multifunction scanners so they can service the devices. A scanner stops working after a hardening change. The engineer turns the legacy dialect or the fallback back on, the device works, and the ticket closes. No malice, no attack, and mechanically identical to the intruder's write. This is the practical reason the distinction matters more than it looks. If your control is a setting and you have handed the write to a third party in order to keep a business function running, you have handed them the control. The things that actually survive that are: removing the component so the write has nothing to act on, or removing the delegation so the write is not permitted. ## Do not answer 'so the policy is useless' That over-correction is a red flag in its own right. Count what the refusal does take away: - an unauthenticated party on the segment can no longer get the host to accept that authentication; - an ordinary user session cannot re-enable it; - a service compromised at low privilege cannot re-enable it; - an intruder who has *not yet* reached administrative rights is blocked from the fallback entirely, which may be the very thing they were going to use to get there. The control is real. Its boundary is the privilege that can rewrite it, and your job in the interview is to state that boundary precisely rather than to declare the control worthless. ## Classifying it out loud A strong answer ends with the classification: this is a **preventive control against a lower-privileged position**, and an **administrative-rights problem** at the higher one. Which means the follow-on work is not another setting. It is reducing who holds that privilege, and removing the capability wherever removal is on the menu - which for NTLM specifically, it is not.

  • A vendor's field engineer with delegated administration turns the fallback back on to fix a scanner. How is that different from the intruder?
    Mechanically it is not different at all - the same write, permitted by the same privilege, with the same effect on the estate. That is the point. The controls that survive both are removing the component where removal exists, or removing the delegation, not tightening the setting.
  • Does removal actually put the capability outside an administrator's reach?
    Not permanently - an administrator can install software. But restoring it becomes an installation with a package, usually a reboot, and a much larger footprint than writing a value. Removal raises the cost and changes the kind of act required; it does not create an absolute barrier.
  • If the refusal comes from domain policy, does the local change stick?
    Not on its own. The domain value is reapplied at the next policy refresh, so the local edit is a bounded window rather than a permanent state. A position with administrative rights on the host can also stop the refresh from landing, which is what turns the window into something longer.

saying these in an interview costs you the question

  • Says the policy stops the intruder because it is enforced centrally
  • Believes NTLM can be uninstalled like an optional feature
  • Concludes the restriction policy is therefore worthless
  • Forgets domain policy is reapplied at the next refresh
  • Treats refusing a protocol as the same as not implementing it

context

resolving links…