Nov 06 2019 05:18 AM
Nov 06 2019 05:18 AM
I am trying to fathom NPS (RADIUS) in Windows Server 2016, but all efforts are failing. I have peeled back to just a basic client (Win10) to server connection on the same LAN and using NTRadPing to test an authentication request ... but all efforts fail.
The latest is "response: Access-Reject". There is nothing logged in the event viewer.
The intention is to use RADIUS authentication for some appliance VPN connections (not RRAS).
My test NPS configuration is as follows:
> NPS enabled and registered
> RADIUS client is created and defined as IP address of 'my_laptop'
> Shared Secret is same as defined on client and server side
> Vendor name is "RADIUS Standard"
> Connection Request Policy: Enabled; Type of network access server is Unspecified, Condition defined is Access Client IPv4 Address is 'my_laptop' IP, Settings is set to Authentication requests on this server
> Network Policy: Enabled; Grant access if connection request matches this policy; Ignore user accounts dial-in properties; Type of network access server is Unspecified; Windows Groups defined where user authenticating is a member of the security group; Machine Groups defined where client machine 'my_laptop' connecting is a member of the security group; Authentication Methods has all "less secure" methods selected, except the last one; RADIUS Attributes has Standard defines as Framed-Protocol as PPP and Service-Type as Framed
> everything else is default
If I change the NTRadPing request type to Status Server, then I get an event logged on the NPS server ... A RADIUS message with the Code field set to 12, which is not valid, was received on port 1812 from RADIUS client <my_laptop>. Valid values of the RADIUS Code field are documented in RFC 2865.
Is this because NTRadPing is old and no longer complies? If so, how else can I do basic RADIUS testing?
I have tried to find some very basic setup for RADIUS (NPS) in Windows but all attempts to get this working fail.
I have the necessary ports open on the firewall too ... 1812, 1813, 1645 & 1646.
Apr 08 2020 06:11 PM
May 20 2020 01:52 PM
@jay26cee Try changing your condition from "Access Client IPv4 Address" to "Client IPv4 Address"
Also make sure you enable logging under Accounting and create your log files in a format you can manage. Because you are being rejected by NPS, it doesn't create an Event Log entry, but it will record in the NPS accounting logs.
When creating your Network Policy, start at the widest breadth - only one condition. Make sure it works, then add another. Same for any constraints. Get it working at the lowest level, then build additional complexity.
I'm running two NPS on Server 2016 with two network policies, including one that is only client IP (used for health monitor) and one that is a bit more extensive. The client IP one had the same issue until I changed the condition.
Jun 08 2020 03:26 AM
@mmendozaf - unfortunately, I have not been able to revisit this yet. Have a look at what DeeRex wrote and see what you can do? I might only get a change to look into this in a couple of weeks. But, I will definitely post any updates on here.
Aug 05 2020 06:29 PM
I've had a similar issue myself setting up NPS on Server 2016, originally thought it was because I was exporting our old NPS Configuration from a 2008R2 box, but still happened on a different server on a fresh setup.
I would recommend having a look at those NPS Audit Logs, usually in C:\Windows\System32\LogFiles\ and in particular look at the "Reason-code" field right up the end of an entry. I was receiving Reason Code 22, which seemingly relates to not having a CA certificate installed on the local client. On a lark I checked the Personal Computer Certificates on the NPS server and found that it didn't actually have one. I generated a new one, tried to connect to the RADIUS WiFi network and it worked.
Though I am still running into some issues with NTRadPing, eh.