AuthHound

Test a Windows NPS server from a client machine

You want to know whether your NPS server actually authenticates a client the way your Wi-Fi or switch does — not whether the service is running, but whether a real PEAP or certificate login from the client side is accepted. The probe sends that exact request from wherever you run it and tells you, in one line, what NPS decided and why.

1. Register the probe in NPS (one time)

NPS silently discards RADIUS requests from any source it doesn't know — there's no reject to see, just a timeout. So the probe's source IP has to be a RADIUS Client first. In the NPS console: RADIUS Clients and Servers → RADIUS Clients → New, or from an elevated PowerShell on the NPS host: 

# NPS host, elevated PowerShell — register the probe's source IP as a client
New-NpsRadiusClient -Name "authhound-probe" -Address "10.20.0.50" -SharedSecret "<shared secret>"

Use the address NPS will actually see. If the client machine sits behind NAT or a VPN, register the post-NAT source IP, not the client's local address — this is the number-one "I added the client and it still times out" mistake. More in troubleshooting → the NAT trap.

2. Run a PEAP-MSCHAPv2 login

PEAP-MSCHAPv2 is what most password-based Windows Wi-Fi uses. Give the probe a real test account — a least-privilege one, never a domain admin — and it runs the full tunnelled login: 

# on the client machine — keep the shared secret out of shell history
$env:AUTHHOUND_RADIUS_SECRET = 'the-secret-you-registered'

# reachability + shared-secret + certificate + BlastRADIUS checks (no login yet)
.\authhound-probe.exe radius test --server nps.corp.com

# add a real PEAP-MSCHAPv2 login — you're prompted for the password (no echo)
.\authhound-probe.exe radius test --server nps.corp.com --peap alice

The password is prompted with no echo; on a script use --password-file. The first two checks need no credential at all — they prove the server is reachable and the shared secret matches before any login is attempted.

3. Testing machine (computer) authentication

Machine auth on NPS is normally EAP-TLS with the computer certificate, not a password. To reproduce it, point the probe at a certificate and key the way a domain-joined machine would present them: 

# machine (computer-certificate) auth is EAP-TLS — point at the device's cert/key
.\authhound-probe.exe radius test --server nps.corp.com `
  --client-cert C:\certs\machine.pem --client-key C:\certs\machine-key.pem `
  --server-name nps.corp.com
💡 A domain computer's PEAP-MSCHAPv2 machine login (host/NAME against the machine-account password) isn't something you can reproduce from a standalone credential — that password is managed by the domain. For machine auth, test the certificate path (EAP-TLS) the machine actually uses, using that machine's own cert, or a test cert from the same issuing CA. The one-line openssl commands to mint a test client cert are in the README.

4. Reading the result

Each check prints a verdict, a plain-English reason, and the next thing to check:

  • PASS NPS accepted the login (or the reachability / shared-secret / cert check proved out). The path a real client uses works.
  • WARN Working, but worth a look — the server cert expiring soon, name validation skipped (add --server-name), or a missing Message-Authenticator (BlastRADIUS).
  • FAIL NPS rejected the login, or nothing answered. The reason line points you at the policy or the registration.

5. What each outcome means for NPS

  • Everything times out. The probe isn't a registered RADIUS Client (step 1), the shared secret is wrong (also silent on NPS), or a firewall is eating UDP/1812. On a first-run timeout the probe prints the exact registration snippet with your detected source IP filled in.
  • Reachable, but the login FAILs. NPS answered Access-Reject — now it's a policy question. NPS logs the reason as an Event 6273 with a Reason Code; that code is the fast way in. Paste the event into the log analyzer, or jump straight to the code: 16 (bad credentials), 22 (client couldn't be authenticated), 66 (auth method not enabled).
  • PEAP passes but EAP-TLS FAILs (or vice-versa). That's a connection-request / network-policy scoping difference on NPS — the two methods hit different policies. It tells you exactly which policy to open.

Related

Running the probe by hand answers "is it working right now?". AuthHound is building monitoring that runs these same checks on a schedule from every site and alerts you when one drifts — early access:

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