Security

I have an issue that has me banging my head against the wall.  Here is my scenario:

 

We would like to do 2 factor authentication user certificates and Active Directory user or computer account authentication.  I have no problem getting EAP-PEAP authentication to work, but when I try to do certificate based authentication it fails every time.

 

I have a valid cert on the NPS server and a client cert issued from the Root CA on the client/supplicant machine.  I have my NPS set up pretty simply and I have the windows machine configured to used smar card or other certificates to connect.  Connecting to the wireless even prompts you for which cert you want to use.

 

Immediately after selecting the cert you are denied access to the wireless network.  If I remove the EAP-TLS (cert requirment) in the NPS conditions I can connect to the wireless. 

 

I have gone through so many forum posts and documentation trying different settings.  I'm about ready to through this thing out window.  Any help to save my sanity is appreciated.  We have never done certificate authentication before.

 

Also clearpass is not an option for us.

 

 

It looks as though your client is attempting to authenticate with a different method than that is supported on the NPS policy.   Your client is attempting to use EAP-TLS with the certificate; while the NPS server is setup to use PEAP with the inner authentication method being the certificate (PEAP-TLS).   Either change your client to use PEAP-TLS (PEAP with Smart Card or Certifiate as a valid inner authentication type) or change the NPS policy to support just Smart Card or Certificate in the EAP methods box.

 

Still getting the same error message: Authentication Type: EAP EAP Type: - Account Session Identifier: - Logging Results: Accounting information was written to the local log file. Reason Code: 66 Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.    Here are my client settings.  

 

This is what I think PEAP-TLS is supposed to look like, am I right?

 

 

 

Here is what my NPS server looks like, similar to your picture.

 

 

Here are my conditions

 

 

My certificates are all issued off the DART Industries Root CA.  

 

Any other advice or settings I should post?

 

 

On your Authentication Methods section on the Contraints tab in NPS; click Microsoft Protected EAP and click Edit.  What supported EAP types do you have listed?   Also, Is the proper certificate present.

 

 

OR

 

On the Windows machine, change the Network Authentication Method to Smart Card or other Certifictate (to use EAP-TLS).....which is often more common as not all OS' support PEAP-TLS.

So I have switched to EAP-TLS by setting the connection to use a smart card or other cert.  My authentication methords section on the Constraints tab looks like this, with a valid certificate for the NPS server.

 

 

Here are the EAP - Types from the constraints tab.  I have MS-CHAPv1 & 2 disabled.

 

 

Here is my Allowed EAP types settings:

 

 

And finally here are the Windows 7 client settings.

 

 

Here's the error message from the NPS server:

 

Authentication Type: EAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 66
Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.

It looks like you are hitting the proper Connection Request Policy, but not the Network Policy.  Your original post shows you matching the network policy of "Connections to other access servers" which is a default policy.    Do you have a Network Policy for these connections?  If so, is it higher in the processing order?

 

Upon an authentication attempt, the Connection Request Policies are matched first.    It is then passed to the Network Policy engine. The Network Policies are where the actual authentication takes place; and attributes applied if configured.    The Network Policy is where you are seeing your mismatched authentication types.

I forgot to disable the default policies on the Test NPS server.  I have disabled Connections to other access servers now.  Still no luck.  

 

I guess I will keep playing with the settings on the Network Policy page and see what I can do.  If it were a certificate issue would it say that there is a cert issues instead of: The connection request did not match any configured network policy?

 

Also, if I use a computer account certificate to connect I get an error message of:  The specified user account does not exist.

 

I'm not sure if that means I've managed to meet to required network policy, but the computer account doesn't exist.  

My recommendation is to delete both the network and connection request policy you created.  Then, create a new Network Policy.   The default Connection Request Policy (Use Windows authentication for all users) can stay enabled (it is basically unrestricting).

 

Create a new Network Policy.  You can start with minimal configurations to ensure functionality; then go back and addtional conditions as necessary.

 

Policy Name - Anything

Type of Network Access Server - Unspecified

Conditions - NAS Port Type = Wireless - IEEE 802.11 (initially, I'd recommend you add more later)

Acesss Granted

EAP Type - Microsoft: Smart Card or other certificate; click Edit and make sure your Certificate is populated

Constraints - NONE

RADIUS Attributes - NONE (unless needed later on)

 

Move this new policy to the very top of the Network Policies.   Test.  If successful, consider adding additional conditions such as "Client Friendly Name" or "Windows Group" memberships.   If it fails, please post the NPS log entry.

 

 

 

 

 

Ok, now I have a different error.  This is still progress.

 

Authentication Details:
Connection Request Policy Name: Use Windows authentication for all users
Network Policy Name: Wireless Access Policy
Authentication Provider: Windows
Authentication Server: USA1NTMGT05.global.company.domain
Authentication Type: EAP
EAP Type: Microsoft: Smart Card or other certificate
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 258
Reason: The revocation function was unable to check revocation for the certificate.

Yes, progress indeed.  Basically the message is saying that the NPS server cannot check the CRL or OCSP (depending on how the CA is setup) to validate whether the client is valid or not.   This may mean the client certificate or the Issuing CA itself.  The entire chain needs to be trusted and their CRLs accessible.  

 

 

Typically CRLs or OCSP are http or ldap paths that are accessible.  However, consider if your PKI design has an offline Root CA; if so, its CRL would need to be imported for full trust.  This is typically imported into AD, thus all AD clients typically trust and know of the CRL; but you may need to import it into the NPS server.

 

 

Well....would you happen to know how I can import that CRL onto the NPS server?  Do I need to export it from the PKI server and onto the NPS server in the Intermediate Certification Authorities \ Certificate Revocation List?

If NPS is a member of AD and your PKI is AD integrated, this information should already be populated to the NPS server.    Without knowing more about your setup, I can't offer much more advise on that topic.  

 

If you need to import it to the NPS server, you can import it right into the Certificates MMC, or try from the CLI:

 

certutil -addstore CA "name-of-file.crl"

 

 

Thanks!  I will give this a shot tomorrow.

It works!  I was able to import the Policy CRL on to the NPS server and now I can get through!

So how could I go about adding EAP-PEAP to this Network Policy so that it won't break the EAP-TLS?

You can add multiple supported authentication types on the same Network Policy without breaking the other.   On the Constraints Tab/Authentication Methods just add what you need.

 

Microsoft: Protected EAP (PEAP) ----> PEAP-MSCHAPv2 or PEAP-TLS depending on the inner type chosen

Microsoft: Smart card or other certificate ---> EAP-TLS

I want to require a certificate and a username and password.  Adding the EAP-PEAP to the constraints allows for either authentication method.  Any idea how I can do this?

You cannot do that.  That is a limitation of the Windows supplicant (and maybe even the IEEE standard).     It will only attempt one authentication type.    

 

Windows computers will try to authenticate as the computer upon boot; and then as the user when someone logs in.  The wireless configuration on the client only passes one authentication mechanism.  What you can do, is enable "enforce machine authentication" on the AAA profile.   This will ensure that both the computer and user have authenticated successfully before assigning the default role; if one or the other has failed, an alternate role can be assigned.  There are caveats to this configuration (caching times, non-windows machines, etc.).   The user guide and these forums discuss this.

 

 

Thanks for all your help!

Where can one purchase a public CA issued certificate which would actually work with NPS?

 

Which CA? Go Daddy has no clue of the requirements and specialized purpose of the needed cert. Obvisouly SSL won't work. Who can sell those certs?

A standard web server SSL certificate will work for NPS.

sorry it won't; don't mean to be brisk or undiplomatic. Many have tried and it has become an anectodal first answer that https SSL would most certainly not work for NPS EAP authentication purpsoes.

I have many EAP-PEAP NPS environments running with a regular web server certificate for the server identity.

Ok fair is fair; could you post a screen shot of the EDIT screen on your NPS (eaxmple attached)?

Here's one:

 

And here's the cert. Just a standard web SSL certificate.

 

Thanks Tim!

 

I can see that this is a self-signed cert and that the purpose is in fact authentication with the correct EKU.

 

I can only coclude that when you self-sign the EKU is preserved but then one sends the cert signing request to godaddy they strip that out.

 

I was able to self-sign and NPS accepted just as you said. Thank you!

 

Of course my issue now is trivial as the non-CA imported clients pop the usual screens:

 

I'm still searching for a paid CA which would sign the request and not screw up the EKU

I've used all major public CAs for a RADIUS server certificate without any issues. GoDaddy, Verisign, Thawte, Digicert, AddTrust, etc.