I have been testing 802.1x authentication on wired networks. When deploying machine certificate (Windows 7), machine gets certificate, then turned on PEAP-MS-chapv2, everything works OK. Machine checks NPS servers certificate, creates tunnel for encrypted password and authentication works OK.
On Windows Server 2008R2 if you delete machine certificate on client, authentication fails, but on Server 2012 R2 if I delete all certificates (machine and root CA), machine gets authenticated? On both Windows versions everything else works as it should (EAP-TLS and PEAP-TLS).
Any comments? Bug?
Did I understand correctly that you Windows 2012 NPS still does authenticate clients after you have deleted its SSL server certificate?
What happens if you restart the NPS service? The only explanation I could think of is that the certificate chain would still be cached in memory.
Or does the NPS perhaps have a suitable certificate issues by another CA, self-signed,...? If you check the Network Policy for EAP-TLS or PEAP-TLS - which server certificate is configured here after you had deleted the other one?
Yes I deleted computer certificate from client, also restarted service and client. The certificate selected in NPS (for PEAP) is certificate assigned to NPS server. I followed this guide despite configuring authentication quite a few times before:
As I said with PEAP-MSCHAPv2 on Win2008R2 NPS if you delete client machine cert authentication failed, on Win2012R2 NPS authentication is successful. I have two different NPS servers in environment (2008R2 and 2012R2). Every time I change to which server I authenticate I restart client machine.
OK - got your problem now (I hope): You use PEAP in these tests (not EAP-TLS) and wonder why deletion of client certificates should matter.
What does the NPS log say?
Is there a chance that a NPS policy enforces EAP-TLS on the 2008 R2 server for the clients in question?
I am not aware of any known issue with PEAP but I have seen vaguely related 'weird things' happening to EAP-TLS clients and certificates, such as 802.1x only working if certificates of client and server are from the same cert. chain (...and it helped to import a suitable cert. even without key).
On 2008 NPS denies access on PEAP-MSCHAPv2. Also log displays access denied. There is also no EAP-TLS enforcement with 2008R2. In 2012R2 logs you see computer as authenticated. As I said two servers different OS, same infrastructure, same switch,same policies on both servers, same clients,I just switch who is authenticating clients.When i authenticate without client certificates against 2008R2 NPS I get denied, I change server to 2012R2 NPS, reboot client and I get authenticated. Then again check for certificates and they are not there?
The strangest thing is that one of our costumers were having problems with EAP session timeouts (in NPS log).
That was the reason I started testing why these timeouts appear , which led to this anomaly. If I configured PEAP-MSCHAPv2 there were no timeouts (in my test environment and also at costumer's infrastructure). As soon I selected authentication that involves EAP (EAP-TLS or PEAP-EAP-TLS) session timeouts are there. I also tried different MTU size, but timeouts are still there.
The costumer's network authentication was configured by them, we were just called to debug the problem. So I saw this strange things in my lab and also at costumer's network.(EAP session timeout and strange authentication)
The first thing was to enforce 802.1x authentication in advanced settings in GPO for wired networks, the second was to update Intel LAN drivers to latest version (I already had problems with these drivers which were randomly crashing Win7 clients).
But if the client is doing PEAP-MSCHAPv2 then a client certificate should not be checked - either a PEAP policy or an EAP-TLS policy should be applied. In case the client is allowed to do PEAP no client certificate should be required as machine domain credentials are used for authentication.
I was puzzled by the fact (if I understood it correctly) that deleting the client certificate should impact PEAP at all with the Windows 2008 R2 server. The behavior you describe for Windows 2012 is as it should work, Windows 2008 seems weird.
I was asking if there is an policy EAP-TLS enforced as using EAP-TLS _instead_ of PEAP-TLS would be an explanation why a client certificate is checked (in addition to bugs).
I'd be interested in the NPS' log entries for the anomalous case, that is:
- Windows 2008 R2 Server
- PEAP-MSCHAPv2 fails
- client certificate just deleted
There should be two lines in the log - one for the Network Policy and one the Authentication Policy. If there is already an issue with the Network Policy there might be only one line.
- Windows 2008 R2 Server