EAP-TLS with Windows NPS and non-domain-joined Clients

  • 2
  • Question
  • Updated 9 months ago
Hello everyone,

I am experiencing the issue that if you have a client that is not domain joined, the Microsoft NPS refuses to authenticate the device with the following Event:

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

Security ID: NULL SID
Account Name: HOSTNAME
Account Domain: DOMAIN
Full Qualified Account Name: DOMAIN\HOSTNAME

Client Machine:
Security ID: NULL SID
Account Name: -
Full Qualified Account Name: -
Calling Station Identifier: censored
Calling Station Identifier: censored

NAS-IPv4-Adress: censored
NAS-IPv6-Adress: -
NAS-ID: AP20361
NAS-Port-Type: Wireless (IEEE 802.11)
NAS-Port: 0

Client Friendly Name: censored
Cleint IP Address: censored

Authentication Details:
Connection Request Policy Name: WLAN-Connections
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: RADIUS.domain.local
Authentication Type: EAP
EAP Type: Microsoft: Smart Card or other certificate
Kontositzungs-ID: 33363136373541444231424442383436
Logging Results: Accounting information was not written to any data store.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

The client which presents its certificate with his DNS-Name as Subject Alternative Name in it, is getting no access to the network from the NPS.

After Troubleshooting this Issue and several hours of searching through the shelves of google I found the problem.

The NPS is trying to check if the given Account Name has an Account within the Active Directory but since the device is not domain joined, there is no object found and the NPS stops its authentication process.

As a workaround the following steps in Active Directory have to be done:

1. Create a user within AD that has the same username as the hostname of the client
2. Export the certificate which is present on the desired client
3. Attach the certificate to the user (with right click on the object and "Name Mappings...")
4. Reauthenticate the client

-> Authentication is now successful.

So to make this work for a whole bunch of clients you would have to deploy a user for each device with a certificate mapped to the user object. In case the certificate needs to be renewed, you have to redo steps 2. to 4. for each client.

Another way I found is to deploy one certificate for all devices, which then is a problem if you have to revoke the certificate for one device, which then makes it necessary to renew the certificate on all other devices.

So by now I was not able to find any other solutions for authenticating non-domain-joined Clients with the Microsoft Windows NPS Role.

Is there anyone that experienced the same issue and has a solution for me that does not involve creating users and manually attaching certificates to them?

Thank you in advance!

Best Regards

Photo of Marcel Rodewald

Marcel Rodewald

  • 8 Posts
  • 0 Reply Likes
  • frustrated :(

Posted 10 months ago

  • 2
Photo of Marcel Rodewald

Marcel Rodewald

  • 8 Posts
  • 0 Reply Likes
We've opened a case at Microsoft. I'll let you know the outcome.
Photo of Matthias Schulte

Matthias Schulte

  • 4 Posts
  • 3 Reply Likes
Marcel: Did you hear any updates from Microsoft regarding this issue?
Photo of Marcel Rodewald

Marcel Rodewald

  • 8 Posts
  • 0 Reply Likes
Hi Matthias,

no - not yet, they are still into analysis.
Photo of Matthias Schulte

Matthias Schulte

  • 4 Posts
  • 3 Reply Likes
Ok, thanks. There must be only one function eliminate the manual step importing the certificate into the name mappings. Currently we are using the LDAP-DN of the existing user account in AD to deploy the certificates. But that also requires to import it into name mappings, as the counterpart of the received client certificate for authentication needs to be stored somewhere.
Photo of Marcel Rodewald

Marcel Rodewald

  • 8 Posts
  • 0 Reply Likes
Hi All,

for your information.

This is the resolution of the case we've had with Microsoft after deeper analysis:

CAUSE (if its applicable)

By design


Microsoft NPS would require at least an account (User/Machine) to authenticate itself with a Domain controller.


Since we are planning to Use only Certificate based authentication i.e. EAP-TLS, wireless client would present the User name/ machine name as per the certificate to the domain controller.


If this is not verified as an AD account, NPS wont authenticate this request. We verified the same via the trace analysis.

This means, with Microsoft NPS it is not possible to authenticate clients outside the domain without the given workarounds.