AuthHound

Event 6273 · Reason Code 66

NPS Event 6273 Reason Code 66 — auth method not enabled

The official text: “The user attempted to use an authentication method that is not enabled on the matching network policy.”

What it actually means: a network policy matched the request (so conditions, groups, and scoping are fine), but the how disagrees: the client wants to authenticate with a method the policy doesn’t offer. Client and server are both healthy; they just haven’t agreed on a protocol. Two fields in the event — Authentication Type and EAP Type — versus the policy’s Constraints tab tell the entire story.

The three flavors

1. EAP method mismatch (the migration classic)

Device asks for PEAP-MSCHAPv2, policy only lists EAP-TLS — or the reverse. This is the standard mid-migration failure when moving from password-based PEAP to certificate-based EAP-TLS: devices not yet re-profiled keep asking for the old method.

Fix: compare the event’s EAP Type with the policy’s EAP list. During migration, either run both methods on the policy temporarily, or (cleaner) separate policies with group conditions for migrated vs unmigrated devices.

2. The client fell back to a non-EAP method

If Authentication Type shows MS-CHAPv2, CHAP, or PAP rather than EAP/PEAP, the client isn’t doing 802.1X EAP at all — typical for VPN appliances, older switch fallbacks, and test tools. Those checkboxes (“less secure authentication methods”) are deliberately off in modern policies.

Fix: decide consciously. Enabling PAP/CHAP to make the error go away weakens the whole policy; usually the right move is fixing the client to do EAP, or giving the legacy device its own tightly-scoped policy.

3. The request matched a different policy than you think

You added the method to the policy you always edit — and the error persists, because the request matches an earlier, stricter policy. NPS policy matching is first-match-wins.

Check: the event’s Network Policy Name field names the policy that actually matched. If it isn’t the one you’ve been editing, fix conditions or ordering — don’t loosen the wrong policy’s methods.

Quick sanity path

Read Network Policy Name → open that exact policy → Constraints → Authentication Methods → compare with the event’s Authentication Type/EAP Type. That’s the whole diagnosis; the only decisions are on which side to change.

Test the policy without waiting for a device: the open-source authhound-probe sends a real request with the method and NAS-Port-Type your conditions key on, so a policy change is verified in seconds — and it prints the attributes the Accept returned.

export AUTHHOUND_RADIUS_SECRET='shared-secret'   # not in argv or shell history
authhound-probe radius test --server nps.corp.local --peap alice --nas-port-type wireless

Recipe: test a Windows NPS server end to end

Have the full log open? Paste it here

The analyzer detects this exact failure and 18 others, and ranks the likely causes for your specific output. It runs entirely in your browser — nothing is uploaded.

This failure is usually invisible until users complain. AuthHound is building continuous monitoring that catches it first — early access:

No spam, no sharing — one email when it's ready, and you can reply to be removed anytime.