G'day everyone! I'd like to switch from PEAP-MSCHAPv2 user/password auth to certificate-based auth on my network. The current setup has been working for years without issues: two Windows 2016 domain controllers with NPS role, and Windows 10 + Windows 11 clients. Authentication works for both wired and wireless clients (use of both computer and user accounts is allowed).
Test environment
For the testing purposes I have deployed a separate switch (Aruba 2530) and chosen two physical machines, one running Windows 10 and one running Windows 11. Both are domain-joined and are correctly fetching all settings from group policy objects. Settings in question being:
- auto-start of the Wired Autoconfig service
- allow autoenrollment of certificates
- setup wired network profile to authenticate with a certificate, machine auth only
The switch has been added as a RADIUS client on Domain Controller #2. The switch points to DC #2 as the only radius host. Also, I've created a new network policy on DC #2, which handles requests coming only from the aforementioned switch (this way I won't disrupt connectivity for other radius clients with my experiments). The policy is set to use 'Microsoft: smart card or other certificate' and I made sure proper cert is chosen from the list.
As for the certificates, the NPS servers already had correct certificates enrolled from the domain CA. For the testing purposes I issued a new certificate template for clients, which they can now autoenroll to use in the network authentication (this was all configured according to Microsoft article).
Client behavior
Now here's where things get weird...
Windows 11 (Lenovo laptop) connected to the auth-configured switchport authenticates almost instantly, with the event logs on both the client and the NPS server showing similar information: authentication succeeded, network access granted (it also shows the correct network policy is being used). Success!
Windows 10 (Dell desktop) however will not authenticate! The event log on the client says "The network stopped answering authentication requests" with reason 0x70004. The event log on the NPS server does not show any sign of a failed authentication, just like the request never reached the server!
This seems very weird as the settings fetched from GPO's are identical and I'm connecting both laptops to the same switch, so it's a controlled environment. Both computers have proper certificates in their stores.
Packet trace
I couldn't see any connected events on the switch either, so I configured port mirroring and ran a packet capture.
There I can clearly see that the process of authenticating the Windows 10 machine stops after the PC sends 'Client Hello'. Only after some time, switch sends a 'Failure' to the client, ending the whole process.
On Windows 11 however I can see that just after 'Client Hello', the server responds with 'Change Cipher Spec, Encrypted Handshake Message', which leads to a 'Success' shortly after.
I've looked into the 'Client Hello' packets and there are some differences, the most obvious being the TLS version in one line (highlighted). It looks like Windows 10 sticks to TLS 1.2, and Windows 11 uses TLS 1.0? Or am I reading it wrong? Also, the list of cipher suites the clients offer are slightly different.
Windows 10:
Windows 11:
And here's the response from NPS server to the Windows 11 machine, in case it provides some additional info:
I'm a bit confused here, hopefully someone can shed more light and point me in the right direction - probably how to make sure Windows 10 uses correct cipher for this purpose. I feel this might be the reason the authentication fails.
Update 24/04/2024: See the debug on the switch.
0000:00:41:13.31 1X m8021xCtrl:Port 24: added new client f8b156-b83e62.
0000:00:41:13.34 1X m8021xCtrl:Port 24: received EAPOL Start from f8b156-b83e62.
0000:00:41:13.34 1X m8021xCtrl:Port 24: added client f8b156-b83e62 to VLAN 40.
0000:00:41:13.87 1X m8021xCtrl:Port 24: connection detected.
0000:00:41:13.87 1X m8021xCtrl:Port 24: sent ReqId #1 to f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24:No. of EAP Id request sent: 1 to client:f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: received RspId #1 from f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: enterAuthState for client f8b156-b83e62, State SM_AUTHENTICATING for host/0pc-test.domain.local0000:00:41:13.87 1X m8021xCtrl:Port 24: started authentication session for client f8b156-b83e62 user: host/0pc-test.domain.local.
0000:00:41:13.87 RAD mRadiusCtrl:Received RADIUS MSG: AUTH REQUEST, session: 10, access method: PORT-ACCESS.
0000:00:41:13.87 1X m8021xCtrl:Port 24: received EAP identity request for client f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: sent EAP response from client f8b156-b83e62 to authentication server.
0000:00:41:13.87 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 10.
0000:00:41:13.87 RAD mRadiusCtrl:ACCESS REQUEST id: 22 to 10.10.5.11 session: 10, access method: PORT-ACCESS, User-Name: host/0pc-test.domain.local, Calling-Station-Id: f8b156-b83e62, NAS-Port-Id: 24, NAS-IP-Address: 10.10.5.231.
0000:00:41:13.87 RAD mRadiusCtrl:ACCESS REQUEST id: 22 to 10.10.5.11 session: 10, access method: PORT-ACCESS, NAS-identifier: HP-2530-24G.
0000:00:41:13.89 RAD tRadiusR:ACCESS CHALLENGE id: 22 from 10.10.5.11 received.
0000:00:41:13.89 1X m8021xCtrl:Port 24: received EAP request for client f8b156-b83e62.
0000:00:41:13.89 1X m8021xCtrl:Port 24: EAP request #2 to f8b156-b83e62 can pass through without authenticator processing.
0000:00:41:13.89 1X m8021xCtrl:Port 24: sent EAP request #2 to f8b156-b83e62.
0000:00:41:13.89 1X m8021xCtrl:Port 24: set supplicant timeout for client f8b156-b83e62 to 30 sec.
0000:00:41:13.90 1X m8021xCtrl:Port 24: received type 13 EAP response #2 from f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: EAP response #2 to f8b156-b83e62 can pass through without authenticator processing.
0000:00:41:13.90 1X m8021xCtrl:Port 24: sent EAP response from client f8b156-b83e62 to authentication server.
0000:00:41:13.90 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 10.
0000:00:41:13.90 RAD mRadiusCtrl:ACCESS REQUEST id: 23 to 10.10.5.11 session: 10, access method: PORT-ACCESS, User-Name: host/0pc-test.domain.local, Calling-Station-Id: f8b156-b83e62, NAS-Port-Id: 24, NAS-IP-Address: 10.10.5.231.
0000:00:41:13.90 RAD mRadiusCtrl:ACCESS REQUEST id: 23 to 10.10.5.11 session: 10, access method: PORT-ACCESS, NAS-identifier: HP-2530-24G.
0000:00:41:13.90 RAD tRadiusR:ACCESS CHALLENGE id: 23 from 10.10.5.11 received.
0000:00:41:13.90 1X m8021xCtrl:Port 24: received EAP request for client f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: EAP request #3 to f8b156-b83e62 can pass through without authenticator processing.
0000:00:41:13.90 1X m8021xCtrl:Port 24: sent EAP request #3 to f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: set supplicant timeout for client f8b156-b83e62 to 30 sec.
0000:00:41:32.61 1X m8021xCtrl:Port 24: connection terminated.
0000:00:41:32.61 1X m8021xCtrl:Port 24: Deleted Client f8b156-b83e62User host/0pc-test.domain.local from Client-List
0000:00:41:32.61 1X m8021xCtrl:Aborted authentication session for client f8b156-b83e62.
0000:00:41:32.61 RAD mRadiusCtrl:Received RADIUS MSG: ABORT REQUEST, session: 10, ACCESS REQUEST id: 23 to 10.10.5.11, access method: PORT-ACCESS.
0000:00:41:32.61 RAD mRadiusCtrl:Removing RADIUS REQUEST id: 23 from queue.
Update: While trying to get printers to auth in the network using a cerificate, I learned that the MTU needed to be changed on the NPS servers, according to this articile: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc755205(v=ws.10)?redirectedfrom=MSDN I'm currently only testing it on a network policy dedicated for the printers, but I'm going to test it on the workstations soon and I'll get back with another update.
