Solved: NPS Error 22- Extensible Authentication Protocol (EAP) Issue

Remote Authentication Dial-in User Service (RADIUS) is an integral part of network infrastructure, especially for authentication, authorization, and accounting (AAA) purposes. NPS (Network Policy Server) is Microsoft’s own RADIUS server, replacing its age-old Internet Authentication Service (IAS). Like any other RADIUS, NPS performs the same function and filters out non-compliant network access, assuring the organization’s overall security.

For robust  Wi-Fi authentication, organizations usually rely on 802.1X, an IEEE Standard for Port-Based Network Access Control (PNAC). It primarily uses the Extensible Authentication Protocol (EAP) as the standard protocol. However, you might encounter some errors if the EAP handshake with NPS fails.

Here we will be addressing one of the most frequent errors you might encounter while using NPS as a RADIUS server or proxy: NPS Error 22.

What is Error: NPS Server Reason Code 22?

NPS Reason Code 22 is one of the common issues users face while using the Extensible Authentication Protocol (EAP) type with the client computer. In short, it typically means that NPS was unable to complete the EAP handshake with the client device, usually because NPS or the client were misconfigured.

NPS works with both credentials and digital certificates. While using certificates, authentication protocols such as PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS must meet the requirements for X.509 certificates and work for connections that use Secure Socket Layer/Transport Level Security (SSL/TLS).

Although it is mandatory that the NPS meet the requirements of both server and client certificates, manually tampering with the TLS in the Windows Registry can have dire consequences, particularly in the Registry path:

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

If you’ve disabled the TLS 1.0 server by manually customizing the TLS registry paired with Group Policy, it can cause the malfunction of the NPS server. This can result in NPS Error 22. If you are keen to resolve this issue, we advise you to check the log files associated with the NPS errors.

Figuring Out the Reason Code

You can follow the instructions from Microsoft documentation to locate the NPS log files associated with the error. The following steps will help you confirm that you are, indeed, experiencing NPS Error 22 and not another issue:

• Open the NPS console or the NPS Microsoft Management Console (MMC) snap-in.
• Click Accounting in the console tree.
• In the details pane, in Log File Properties, click Change Log File Properties.
• In the Log File Properties dialog box, click the Log File.
• You can locate these files by typing the NPSLogFile in Log File Directory. The file is located at %systemroot%\System32\NPSLogFile.
• Keeping the other settings in default mode is recommended to minimize unnecessary headaches.
• For XML descriptions of the log files, click DTS Compliant in Format.

Once you’ve  located the log files, you can verify the last lines of the log files and check if it looks like “<Reason-Code data_type=”0″>22</Reason-Code>.” This line confirms that the error you are facing is Reason Code 22.

There’s a possibility you might see an error code other than the one described in this guide. If you are confused about the NPS errors you are encountering and can not figure out the root cause for the same, then we recommend checking out Microsoft’s reason code chart.

How to Fix NPS Server Reason Code 22

For the Windows implementation of the TLS and SSL protocol, instead of editing the registry directly, use Group Policy or other Windows tools such as the Microsoft Management Console (MMC). We recommend that you avoid directly editing the registry unless there are no other alternatives. If you have decided to edit the registry, be extra cautious in the process.

Now, if you have already disabled the TLS 1.0 server, you need to enable it by following the given commands in the registry:

“HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0” /v Server /t REG_DWORD /d 0xffffffff /f

 The following example shows TLS 1.0 client set to the Enabled state:

                                                                    Source: Microsoft Docs

Sometimes, Microsoft Point-to-Point Encryption (MPPE ) is used by NPS for encryption. If there’s a possibility you disabled this in the past by mistake, you can check it now. Should it be disabled, you can re-enable RC4-128 Bits  using the given commands:

“HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128” /v Enabled /t REG_DWORD /d 0xffffffff /f

Sometimes there might be authentication time-outs or delays, also known as MaxConcurrentApi bottlenecks in an environment. You can resolve the problem by raising the maximum allowed worker threads in the server using the following steps:

• Click Start, click Run, and type Regedit.
• Click OK.
• Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• On the Edit menu, navigate to New, and then click DWORD Value.
• Type MaxConcurrentApi, and then press Enter.
• On the Edit menu, click Modify.
• Set the new MaxConcurrentApi setting to 5(or any desired decimal value).
• Click OK.

When you authenticate the client computer using SSL or TLS, the server sends a list of trusted certificate issuers. This list contains the set of certificate issuers that the server usually trusts and assists client computers in selecting specific client certificates from multiple certificates. It is always a healthy practice to minimize the number of certificates in the system by disabling the SendTrustedIssuerList.

The default value of the SendTrustedIssuerList is generally 0 (off by default), but you must verify that and disable it. You can use the given instructions to disable the SendTrustedIssuerList:

Click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

• On the Edit menu, navigate to New, and then click DWORD Value.
• Type SendTrustedIssuerList, and then press Enter.
• A new DWORD value SendTrustedIssuerList is created.
• Now, set it to 0 (disable).

Drawbacks of NPS

NPS is an on-premise RADIUS server that is located physically within your organization. It might appear advantageous to you, considering you can have complete control over it due to its physical presence, but that’s not always the case. NPS was designed to work with Active Directory (AD) in on-premise environments long before cloud servers came into existence.

What’s more, NPS can be complex to configure. There are many ways to accidentally misconfigure it or the client devices it authenticates, leading to error codes such as NPS Error 22.

Of course,  you can still rely on NPS if you want to work on outdated on-premise directories, but the paradigm shift in the IT landscape has threatened the utility of NPS in the future. Also, the on-premise nature of the NPS server is prone to various security threats, considering its easy physical accessibility.

Even if you decide to authenticate NPS with cloud infrastructure, it will require a proxy to convert the data from the cloud app to a format readable by NPS back and forth. These steps are not only very tedious and complex in nature, but also heavier on the budget side.

NPS also has integration issues with other Microsoft-owned applications operating in the cloud, such as Azure AD, since Azure is a cloud solution and is incompatible with NPS. If you want to deploy Azure, a different authentication server or proxy will need to facilitate the process. You might need third-party solutions that allow you to use your Active Directory with a cloud RADIUS server, like Cloud RADIUS.

Cloud RADIUS: The way Forward

An improperly configured RADIUS server is more of a security liability than a strength. You can skip the headache of self-configuration by using RADIUS-as-a-service options like our best-in-class Cloud RADIUS. Cloud RADIUS can seamlessly integrate with a range of vendors, so you’re not just limited to Microsoft.

Cloud RADIUS minimizes the errors you face in an on-premise RADIUS and offers numerous benefits that a physical server simply cannot match. It has built-in redundancy to provide integrations for cloud applications like Azure that can securely authenticate remote users. The Cloud RADIUS has an additional capacity for deploying certificate-based 802.1x network authentication, the gold standard in network authentication.

Check out our pricing page to see if SecureW2’s Cloud RADIUS solutions fit the authentication needs of your organization.