The RADIUS server plays a vital role in the authentication within a network infrastructure. NPS (Network Policy Server) is Microsoft’s own RADIUS solution that performs a similar role of filtering out non-compliant network connections and ensuring the enterprise’s network is secure.
If you manage devices using Meraki, chances are that you might have faced difficulty in integrating with the NPS, especially in an on-premise environment. Here we will discuss a frequent error Meraki Admins face commonly known as Reason Code 66 in Microsoft setup. There are several scenarios for this error code, and we will try to resolve each one.
Case 1: 802.1X EAP failure with Network Policy Server (NPS)
Solution:
You can try connecting to the SSID without ticking the box “Use my Windows user account.” Instead, try entering your login credentials (username and password) without the prefix domain.
After that, you will receive a notification asking you to confirm the expected domain in the server. Then, it will connect to the NPS server.
Case 2: NPS denied access to a User – NPS Reason Code 66
Here the user attempts to use an authentication method (often PEAP-MSCHAPv2) that the corresponding network policy does not permit.
Your organization’s network might not be configured to support EAP-TLS or PEAP and thus could not receive client-side certificates. As a result, the system could not trust the server’s certificate for the PEAP protocol.
1st Solution:
Some users are tempted to check only the MSCHAPv2 or MSCHAP protocol on the client-side and leave PEAP, assuming the client would not necessarily validate the server’s certificate.
But in this case, you first need to specify PEAP as the authentication protocol to be used, and only after that choose MSCHAPv2 (as there is an option to uncheck PEAP on the server-side). Also, you need to ensure that the client-side has a copy of the root certificate installed in its domain.
2nd Solution:
There are some instances when the 1st remedy we suggested might not work. In that case, we recommend you start over from the top.
Delete both network and any connection policies you might have created in the process. Then create a new network policy with default settings. At the start, keep your policies simple and minimal to avoid complications and make it easier to identify issues. You can add the desired conditions in the later stages. Keep this network policy on top of the hierarchy and test to verify it.
One more thing you can try is adding different authentication protocols that are supported without breaking the existing ones. Simply add what you require under the Constraints Tab/Authentication Methods. For example, PEAP-MSCHAPv2 or PEAP-TLS, depending on the protocol selected by the system.
3rd Solution:
If your PKI configuration contains an offline ROOT CA, you’ll need to import the Certificate Revocation List (CRL) for full trust. This is usually imported automatically in Active Directory, but you might also need to import it to the NPS server.
You can add the CRL directly into Certificates MMC or try the CLI command:
certutil -addstore CA “name-of-file.crl
Drawbacks of NPS
NPS is an on-premise RADIUS server that is physically placed within your enterprise. It may seem handy at first as you have complete control over it due to its physical presence, but this is not always the case. Microsoft built NPS to interact with Active Directory (AD) in on-premise setups long before cloud servers existed.
Furthermore, configuring NPS can be relatively complex. Many things can go wrong with the configuration or with the client devices it authenticates, resulting in error codes like NPS Error 66, so an on-premise server requires an experienced team to maintain it.
Also, because of its easy physical accessibility, the NPS server’s on-premise presence makes it vulnerable to various physical security threats. Given the costs of maintaining highly-secure physical locations, there’s rarely a circumstance in which on-prem works out to be cheaper than cloud RADIUS. Somewhat counterintuitively, cloud networks are typically much better protected and highly resilient compared to their on-premise counterparts.
NPS, being built for on-prem AD environments, has significant drawbacks when integrating with other Microsoft-owned cloud-based products, such as Azure AD. If you wish to use Azure with NPS, you’ll need to use a different authentication server or proxy to make the procedure easier. These procedures are not only time-consuming and challenging, but they are also very costly in nature.
The Best Way To Solve NPS Errors – Don’t Use NPS
As we have seen, the root cause of most NPS errors lies in the difficulty (perhaps futility) of using a 15-year-old on-premise AAA solution in tandem with modern cloud environments. The physical on-premise setup, use of outdated protocols like PEAP and MSCHAPv2, and significant costs of maintenance make it suboptimal for nearly every deployment scenario.
Microsoft’s only solution to RADIUS authentication in Azure AD still requires an on-premise AD server for primary authentication with NPS, which doesn’t address the core issue of on-premise hardware. SecureW2’s CloudRADIUS is a superior solution that can actually facilitate the transition to a full cloud network and help you minimize many errors and enhance your organization’s overall security.
We offer native integrations to all major MDMs in the market, including Meraki and a long list of users’ satisfaction is a testimony to that. We have affordable pricing options for organizations of all sizes. Click here to check our pricing.
