NPS RADIUS – “Message-Authenticator attribute is not valid

[athan1234]

Hi everyone,

Some time ago, I configured an SSID using 802.1X authentication with NPS, and it has been working correctly.

Now, I need to add a new SSID to the same NPS server. In this case, the computer that will connect to the SSID is not joined to the domain.

I created a new Network Policy in NPS and placed it at the top of the policy list. The conditions are:

• NAS Port Type: Wireless – IEEE 802.11
• Calling Station ID: *.wifiname$

The complete IP range is already configured under RADIUS Clients.

However, when I try to connect to the Wi-Fi network, I receive the following error in the NPS Event Viewer:

An Access-Request message was received from RADIUS client x.x.x.x with a Message-Authenticator attribute that is not valid.

I have been reading about this error, and several posts suggest that it may be related to an incorrect shared secret.

I have checked the shared secret and it seems to be correct. Nevertheless, to rule this out, I created a new RADIUS client containing only this AP and configured a completely new shared secret on both sides, Meraki and NPS.

Unfortunately, I still receive exactly the same error.

Has anyone experienced this issue before or have any idea what else I could check?

Thanks in advance.

[aleabrahao]

You can certainly use MS-CHAPv2 without the machine being joined to the domain, but, if you don't mind me asking, if it's just a test machine, wouldn't it be much easier to set up a test SSID with PSK and enable it only when you need to run a test?

Do you really think it's worth all that effort? Sometimes the simple solution is the best one.

[athan1234]

Okay, I understand, but I would like to understand the technical reason why this doesn't work.

Is it mandatory for a device to be domain-joined when using NPS with 802.1X certificate-based authentication? My assumption is that NPS needs the device to exist in Active Directory in order to validate the certificate or apply the corresponding authentication policy. Therefore, if the PC used for the POC is not domain-joined, the authentication fails. Is my understanding correct?

I also need to implement a similar solution for mobile devices that are not domain-joined. Would I face the same limitation?

My plan is to deploy the required CA certificate to the mobile devices and authenticate them to the SSID using 802.1X and certificates.

[aleabrahao]

@athan1234 

I mentioned that, but I never said that domain joining is mandatory. What I said was that many authentication methods (especially 802.1X/EAP-TLS) require the device to be domain-joined or, at the very least, capable of proving its identity as that specific machine.
So, no, a device does not need to be domain-joined for 802.1X EAP-TLS to work with NPS. Non-domain mobile devices can be successfully authenticated, provided they have valid client certificates and NPS is configured to trust and authorize them. The errors you reported suggest that the failure occurs before NPS even reaches the certificate-based authentication stage.

The suggestion to simplify things was just so you wouldn't waste time, given that this is just a test SSID.

Another option you could test is using a user certificate instead of a machine certificate. Finally, I would recommend consulting a Microsoft NPS specialist or opening a support case with Cisco.

[athan1234]

Thanks @aleabrahao 

To be precise about my mobile scenario:

- 1000+ Android/iOS phones, managed by Intune, NOT domain-joined and NOT present in on-prem AD.
- EAP-TLS with a DEVICE certificate from our AD CS (via Intune SCEP/PKCS).
- Windows NPS as RADIUS, Meraki APs.

When you say NPS must be "configured to trust and authorize them", what exactly do I need on the NPS/AD side?

1. Does NPS require an AD object (computer or user) mapped to each device certificate, or can it authorize based only on the certificate (trusted CA + EKU)?
2. If an AD object is required, how would you handle it for 1000+ devices?

Thanks!

[aleabrahao · Accepted solution]

No, NPS cannot perform certificate-based authorization for devices that do not have a corresponding identity in AD.
With Windows NPS and EAP-TLS, authentication goes beyond simply verifying that the certificate was signed by a trusted CA. NPS typically validates the certificate and then maps it to an Active Directory account (user or computer) so that AD can authorize the identity.

Standalone NPS is not typically used as an identity repository for these devices. Common approaches involve Azure/Entra-compatible NAC solutions.

Examples:

Cisco ISE
Aruba ClearPass
Microsoft Cloud PKI + modern NAC integrations

The easiest way in this case would be to use a user certificate instead of a machine certificate.

[athan1234]

Thanks for your reply, @aleabrahao . I really appreciate it.