Event 6273 with reason code 65 — "The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user." The connection attempt failed because the account's Dial-in tab says Deny access. This per-account setting is evaluated on top of your network policies, and a legacy 'deny' there overrides an otherwise-matching allow policy — unless the policy is told to ignore it.
Reason code 65
NPS 6273 reason 65: network access permission denied on the account
What it means
Common causes
The user or computer account has Deny access set on the Dial-in tab (sometimes inherited from old remote-access era standards or copied account templates).
Accounts are set to Allow/Deny explicitly instead of 'Control access through NPS Network Policy', creating per-account surprises.
Machine authentication (computer certificates,
host/identities) is being evaluated against the computer account, whose Dial-in tab is separate from the user's and is easy to overlook.
How to fix it
In Active Directory Users and Computers, open the account > Dial-in tab and set Network Access Permission to 'Control access through NPS Network Policy' (recommended) or 'Allow access'.
Fix it on the NPS side instead of per account: open the matching network policy > Properties > Overview and tick Ignore user account dial-in properties. NPS then decides purely on policy and the AD attribute stops mattering for that policy — the right default for 802.1X, where the Dial-in tab is a remote-access relic.
Bulk-fix with PowerShell:
Set-ADUser <user> -Replace @{msNPAllowDialin=$true}to allow, or clear the attribute (-Clear msNPAllowDialin) to defer to NPS policy.Audit for stragglers: search AD for accounts where
msNPAllowDialinis explicitly false, and remember computer accounts carry the attribute too.
Frequently asked
The account is set to 'Control access through NPS Network Policy' and I still get reason 65 — why?
Check which account NPS actually evaluated. The event's Account Name tells you: for computer authentication it is the computer account (host/name or DOMAIN\name$), which has its own Dial-in tab and its own msNPAllowDialin value. Also confirm the policy that matched — the Network Policy Name in the event — has not got 'Ignore user account dial-in properties' unticked while a different policy you were looking at has it ticked.
msNPAllowDialin is not set at all — does NPS treat that as deny?
No. An unset attribute is the same as 'Control access through NPS Network Policy': NPS decides from policy alone. If you see reason 65 with the attribute genuinely unset on the evaluated account, the attribute is set on a different account than you think (user vs computer), or a provisioning script or account template is writing it after the fact. Ticking 'Ignore user account dial-in properties' on the network policy removes the attribute from the equation entirely.