Windows NPS authentication failure

JeffreyMik

New Member
Joined
Jul 24, 2024
Messages
1
Hello,

I currently have a Windows Server 2022 with NPS and AD running on it. I have a few network policies that work fine. Now I want to add a policy that checks if a client doesn't belong to anything. The policy just checks if the incoming connection is using 'Ethernet'. If so, it must return a VLAN-ID.

When I connect a Windows 11 client to the switch that is configured as Radius client at the NPS server (This works fine), the request is forwarded to the NPS-server. At the server I see the following:

"
Authentication Details:

Connection Request Policy Name: Secure Wired Connections (SNN)

Network Policy Name: -

Authentication Provider: Windows

Authentication Server: SNN-AD-01.snn.local

Authentication Type: MD5-CHAP

EAP Type: -

Account Session Identifier: -

Logging Results: Accounting information was written to the local log file.

Reason Code: 16

Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
"

The client authenticates using (CHAP-MD5) which is not supported by NPS. No EAP-type is used and so the policy that I created doesn't get hit. How can I fix this problem?
 


Solution
Hello JeffreyMik,

It sounds like you're stuck in a tricky spot with your NPS configuration. Let's break down the situation and see what can be done.

### Understanding Your Setup

You've got Windows Server 2022 handling NPS (Network Policy Server) and Active Directory (AD), and you want a policy to return a VLAN-ID based on Ethernet connections, with the additional requirement for the client not to belong to any predefined group. However, when you're connecting a Windows 11 client, you're running into authentication issues.

### Key Points from Your Logs:

1. Connection Request Policy Name: Secure Wired Connections (SNN)
2. Network Policy Name: Empty (This indicates your policy did not match)
3. Authentication...
Hello JeffreyMik,

It sounds like you're stuck in a tricky spot with your NPS configuration. Let's break down the situation and see what can be done.

### Understanding Your Setup

You've got Windows Server 2022 handling NPS (Network Policy Server) and Active Directory (AD), and you want a policy to return a VLAN-ID based on Ethernet connections, with the additional requirement for the client not to belong to any predefined group. However, when you're connecting a Windows 11 client, you're running into authentication issues.

### Key Points from Your Logs:

1. Connection Request Policy Name: Secure Wired Connections (SNN)
2. Network Policy Name: Empty (This indicates your policy did not match)
3. Authentication Type: MD5-CHAP
4. EAP Type: Not present (No EAP type means your policy isn’t firing)

### Problem
The error message indicates an "Authentication failed due to a user credentials mismatch." The client seems to be using MD5-CHAP, which is not supported by NPS, and since no EAP type is used, the policy you intended for controlling VLAN conditions isn't activated.

### Steps to Resolve

1. Change the Authentication Method:
- Switch to EAP: Update the configuration on the client-side to use an EAP method. Common choices include EAP-TLS (which requires certificates) or PEAP (Protected EAP), as these are compatible with NPS. You'll likely want PEAP, as it works well without requiring certificates for every client.

2. Network Policy for VLAN Return:
- Create a new Network Policy in NPS that specifically checks if the connection is from an Ethernet source and returns a VLAN-ID.
- Ensure this policy is set to be applied before any restrictive policies that might be denying access.

3. Adjust Connection Request Policy:
- Make sure your Connection Request Policy allows for the new EAP method you plan to implement, as it must also match the request.

4. Testing:
- After making these changes, attempt to connect again and check the NPS logs. Ensure that the EAP type appears correctly this time and that your Network Policy actually gets hit.

5. User Credentials:
- Double-check that the user account you are testing with actually exists in AD, and that the credentials used on the client side are correct.

If you implement these changes and still face issues, don't hesitate to reach out for more troubleshooting steps. Networking can be finicky, but with patience and tweaks, you'll get it working!

Good luck! 🌐
 


Solution
Back
Top