Enterprise Windows security is rarely undone by a single catastrophic failure. In my experience, breaches usually start much earlier — quietly, methodically, and often using features that have existed for decades and were never revisited.
Anonymous Security Account Manager (SAM) enumeration falls squarely into that category.
It’s not a zero-day.
It doesn’t trigger antivirus alerts.
And on its own, it doesn’t compromise a system.
But if you’ve ever investigated lateral movement, ransomware deployment, or privilege escalation after an incident, you’ll recognise it immediately: reconnaissance.
Disabling anonymous SAM enumeration won’t make headlines, but it removes a valuable source of information attackers rely on in the early stages of an attack. And with Microsoft Intune, it’s one of those rare security controls that is easy to deploy, low risk, and high impact.
What Anonymous SAM Enumeration Actually Is
The Security Account Manager (SAM) database stores local account information on Windows systems, including:
- Local users
- Local groups
- Group memberships
- Certain domain-visible account details
Historically, Windows has allowed unauthenticated (anonymous) queries to retrieve some of this information. This behaviour exists largely for backward compatibility and legacy networking scenarios.
In practical terms, anonymous SAM enumeration can allow an attacker to identify:
- Which user accounts exist
- Which accounts are members of administrative groups
- Whether service or default accounts are present
That information alone doesn’t grant access — but it dramatically reduces guesswork.
Why This Still Matters in 2026 (Yes, Really)
I’ve heard the argument more than once:
“Isn’t this an old issue? Surely modern security tools already cover this.”
Unfortunately, attackers still rely heavily on cheap, low-noise techniques. Anonymous enumeration is attractive because:
- It doesn’t require credentials
- It doesn’t exploit a vulnerability
- It often isn’t logged or alerted on
- It works across poorly hardened endpoints
In real-world investigations, I’ve seen anonymous enumeration used to:
- Identify privileged local accounts before brute-force attempts
- Confirm naming conventions for phishing campaigns
- Map machines suitable for lateral movement
- Prioritise targets for ransomware deployment
Think of it this way: attackers don’t kick down the door first — they check if it’s unlocked.
Why Leaving This Enabled Is a Risk You Don’t Need
Even in well-managed environments, leaving anonymous SAM enumeration enabled creates unnecessary exposure.
1. It Enables Smarter Attacks
Knowing which accounts exist — especially admin or service accounts — allows attackers to tailor their approach instead of spraying credentials blindly.
2. It Aids Lateral Movement
Once an attacker gains a foothold, enumeration helps them decide where to go next. Removing this visibility slows them down and increases the chance of detection.
3. It Undermines Defense-in-Depth
Security works best when layers overlap. Allowing unauthenticated account discovery undermines endpoint hardening, even if everything else is well configured.
The Old Way: Why Manual Fixes Don’t Scale
Traditionally, disabling anonymous SAM enumeration involved modifying Local Security Policy settings on individual machines:
- Navigating to Security Options
- Adjusting anonymous access settings
- Hoping nothing reverts or drifts
That approach might work for a handful of servers. It does not work for:
- Hundreds or thousands of endpoints
- Remote and hybrid workforces
- Compliance-driven environments
Manual configuration also fails the audit test: if you can’t prove it’s enforced everywhere, it may as well not exist.
The Modern Approach: Enforcing This with Intune
Microsoft Intune finally makes this control practical at scale.
Instead of touching each endpoint, you define the policy once and enforce it consistently across all managed devices.
This is exactly how endpoint security should work.
How to Disable Anonymous SAM Enumeration Using Intune
There are two solid approaches in Intune: Security Baselines (recommended for most organisations) or custom configuration profiles. I’ll focus on baselines, as they align best with enterprise security posture.
Step 1: Create or Modify a Security Baseline
- Open the Microsoft Intune Admin Center
- Navigate to Endpoint security → Security baselines
- Select the Windows 10 and later Security Baseline
- Create a new baseline profile or edit an existing one
Security baselines provide a sensible starting point and reduce configuration mistakes.
Step 2: Configure the Relevant Security Options
Within the baseline, locate Security Options and configure the following:
- Network access: Let Everyone permissions apply to anonymous users
Set to Disabled - Network access: Restrict anonymous access to Named Pipes and Shares
Set to Enabled
These two settings work together to prevent anonymous users from enumerating accounts and resources.
This is one of those rare cases where Microsoft’s baseline recommendations align perfectly with real-world security needs.
Step 3: Assign the Policy Carefully
Target device groups — not users.
Prioritise:
- Corporate laptops and desktops
- Domain-joined or Entra ID–joined devices
- Any system with local admin accounts
I strongly recommend:
- A pilot group first
- A staged rollout
- Monitoring before full enforcement
In most environments, this change causes no functional impact, but testing is still good hygiene.
Step 4: Monitor Compliance and Drift
Once deployed:
- Monitor baseline compliance in Intune
- Investigate any failures
- Remediate non-compliant devices early
Security settings that silently drift are often worse than settings that were never applied.
Auditing and Validation (For the Paranoid and the Auditors)
If you need to verify enforcement at a technical level, the relevant registry value is:
HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
EveryoneIncludesAnonymous
- 0 = Anonymous access disabled (desired state)
- 1 = Anonymous access enabled
This can be checked manually, via PowerShell, or audited at scale using Intune scripts.
In regulated environments, this extra validation step is often worth the effort.
The Practical Benefits of Disabling Anonymous SAM Enumeration
From experience, the benefits are clear:
Reduced Reconnaissance Surface
Attackers lose an easy way to map accounts and privileges.
Stronger Endpoint Hardening
Endpoints no longer disclose unnecessary information without authentication.
Better Compliance Alignment
This control supports requirements in:
- ISO 27001
- NIST CSF
- CIS benchmarks
- GDPR data minimisation principles
Minimal User Impact
No UI changes. No workflow disruption. No support desk tickets.
This is the definition of quiet security — controls that do their job without anyone noticing.
Best Practices from the Field
- Treat this as part of a broader hardening baseline, not a one-off fix
- Combine with local admin restrictions and credential hygiene
- Ensure SMB and legacy protocols are also reviewed
- Document the decision — auditors love rationale
- Don’t rely on EDR alone to compensate for weak configuration
Modern security isn’t about a single tool doing everything. It’s about reducing opportunities at every layer.
Final Thoughts
Anonymous SAM enumeration is one of those legacy behaviours that survives mostly because it’s invisible — not because it’s useful.
In enterprise environments, leaving it enabled provides attackers with information they simply don’t need to have. Disabling it doesn’t break Windows, doesn’t impact productivity, and doesn’t complicate management — especially when enforced with Intune.
Key takeaway for IT professionals:
Disabling anonymous SAM enumeration is a low-effort, high-value security control. When enforced centrally through Intune, it removes a common reconnaissance technique and meaningfully strengthens your Windows security posture without disrupting business operations.
Sometimes the smartest security improvements aren’t the most complex — they’re just the ones we finally get around to locking down.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.