TECHNICAL TIP: Network problems after moving to Windows 11? Read this!
Updated: Oct 29
We understand that both we and our clients would like to see more technology among our IT solutions that is developed and made in Europe and complies with our privacy regulations. But this change will not happen overnight. In some cases, there are no good alternatives today. Microsoft’s Windows operating system will stay with us in business use for a long time yet. Support for Windows 10, however, ends this month (October 2025), and it is time to move to the new Windows 11 (unless you fancy migrating your users to Linux).
Replicant IT sells only European technology, but supports its clients with services regardless of where the technology comes from. While moving to Windows 11, our technical team came across a technical fault, and we are sharing how we solved it.
This article is fairly technical. If the content is unclear but you are in the middle of upgrading your organisation’s computers to Windows 11, get in touch and we will help.
Problem description
A secure LAN using a RADIUS server stopped working after the workstation was upgraded from Windows 10 to Windows 11.
As a result, Windows 11 computers could no longer access the secure internal network, and the switch connected the device to the fallback network configured on the port.
Fallback networks are usually guest networks or other networks that give no access to the company’s internal network.
Root cause
The situation arose because the Windows 11 default security threshold (security baseline) is higher than in Windows 10, which affects network profiles applied through Group Policy. Credential Guard can be configured in Windows 10, but in Windows 11 it is enabled by default.
Solution
To resolve the situation, a separate OU (Organizational Unit) was created in Active Directory, the Windows 11 workstations were added to it, and a separate Group Policy was created for them.
The following changes were made in the new Group Policy compared with the existing GPO for Windows 10 machines:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Wired Network (IEEE 802.3) Policies
Protected EAP Properties option: ticked Verify the server’s identity by validating the certificate
Trusted Root Certification Authorities: checked and confirmed that the specific CA root certificate that also issued the certificate to the NPS server(s) is selected.
Ticked Connect to these servers and entered the FQDNs of the NPS servers, observing upper and lower case.
Select Authentication Method: selected Smart Card or other certificate because EAP-MSCHAP v2 is no longer reliable in Windows 11 and may cause problems.
As a temporary measure, the authentication protocol problem can also be solved by disabling the Credential Guard Group Policy, but this can only be temporary until you have moved from MSCHAP v2 to EAP-TLS.
Disabling this setting leaves your systems vulnerable to unknown applications and operating systems.
Main differences between the two authentication protocols:
EAP-TLS uses digital certificates and offers higher security than PEAP-MSCHAPv2, which relies on user credentials (username/password).
PEAP-MSCHAPv2 is vulnerable to credential theft in man-in-the-middle attacks and to pass-the-hash attacks.
EAP-TLS makes authentication simpler for the user, as there is no need to remember and frequently change a password.
We restarted the workstation and/or ran gpupdate /force in Command Prompt. After that, the connection to the company’s secure network worked. The same solution also applies when a secure Wi-Fi network is not working.
Other issues that came up
There are other reasons why a secure LAN or Wi-Fi network may fail. Here are some that may occur, all of which came up while we were solving our problem:
GPO conflict: the same SSID/profile is defined by multiple GPOs; “Winning GPO” wins and the other is overshadowed.
PEAP/EAP settings on the client: Verify server’s identity is enabled, but Root/Issuing CA is not trusted, or “Connect to these servers” does not match the SAN DNS names in the NPS certificate.
NPS certificate: EKU/SAN does not meet expectations (e.g. the SAN is missing the NPS FQDN that the client expects).
No certificate on the client device: computer auto-enrolment not configured in the GPO
Windows 11 security baseline: Credential Guard / LSA Protection and similar features may reduce the reliability of PEAP-MSCHAPv2. Microsoft recommends using EAP-TLS instead.
VLAN attributes: VLAN assignment is defined in only some policies, or the conditions do not apply.
Drivers: outdated Wi-Fi/Wired NIC drivers cause authentication or encryption errors.
We recommend planning the move to Windows 11 and starting with a smaller number of workstations. Need help? Get in touch!
