Strong Certificate Issues

Question

I've been working towards implementing strong certificate authentication since the May 2022 update release by Microsoft. I've gone so far as paying for Microsoft premier support which wasn't helpful and did not result in a successful implementation back in 2022/2023

As it stands I have auto enrolled certificates issued to computer objects. Those certificates are using the compatibility version which is Server 2016/Windows 10 both for the CA and recipient. The certs templates are also configured to use the Key Storage Provider, Algorithm is RSA, key size is 2048, and the hashing method is SHA256. I can confirm that the OID extension (1.3.6.1.4.1.311.25.2) is included on the certificates and that they correct contain the computer object's SID. Additionally, the CN equals the DNS name, a SAN is present that matches the CN (DNS Name), lastly a final SAN exists which is the SPN COMPUTER$@domain.com. This certificate is the only cert in the certificate store and via Wireshark captures on the NPS server I can confirm that the cert is being presented and that all those values are seen by NPS.

When I move to Full Enforcement mode 802.1X authentication fails. In bypass mode auth completes without issue.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Value: 2

HKEY_LOCAL_MACHINE\System\CurrentControlSet\SecurityProviders\Schannel Value: 0x18

This is for 802.1x auth with EAP-TLS. Radius/NPS logs are error code 16 which is username/password mismatch/failure. On the client side in the wired autoconfig logs the identity is represented correctly and the error is that the auth was rejected. I've checked the System event logs on all domain controllers, looking for eventIDs 39,40, 41. No events are logged. I've removed all RODC from the environment. All servers are 2016+. The NPS, ADDS, and CA roles are all on their own dedicated boxes.

Answer 1

Hi B_055,

Thank you for posting in the Microsoft Community Forums.

Check the NPS server configuration:

Ensure that the network policy on the NPS server is configured correctly, especially the parts related to EAP-TLS. Check that the network policy specifies the correct authentication method (EAP-TLS) and encryption settings.

Verify the certificate chain of trust on the NPS server The NPS server needs to trust the CA root certificate issued to the client certificate.

Check the logging settings of the NPS to ensure that all relevant logs are captured and logged.

Certificate Validation:

Although you have verified that the certificate is visible on the NPS and contains the correct OID and SAN, double-check the certificate's validity, revocation status (if CRL checking is enabled), and the integrity of the certificate chain.

Ensure that the certificate on the client computer is also valid and that the client trusts the CA that issued the certificate.

Client Configuration:

Check the 802.1X configuration on the client computer, specifically the EAP settings. Ensure that the client is configured to use EAP-TLS and that the certificate is specified correctly.

Verify that the client has the latest version of operating system patches and drivers installed.

Network issues:

Use Wireshark or other network analysis tools to capture network traffic between the NPS server and the client and check for any anomalies or errors during the EAP-TLS handshake.

Check the configuration of network devices, such as switches and routers, to ensure that they support and are properly configured for 802.1X and EAP-TLS.

System logs and events:

Although you do not see event IDs 39, 40, and 41, check other relevant event logs on the NPS server and clients, such as security logs and system logs, for possible clues.

Check the application logs of the NPS server for more detailed information about authentication failures.

Domain controller and Kerberos configuration:

Although you have set the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc to a value of 2, make sure that the Kerberos service is configured correctly.

Check the domain controller's system logs for any Kerberos-related errors or warnings.

Updates and patches:

Ensure that all servers, including NPS, ADDS, and CAs, have the latest updates and patches installed.

Testing and troubleshooting:

If possible, try to reproduce the problem in a simplified environment so that you can more easily localize the problem.

Test with different client computers and different network configurations to troubleshoot problems with specific devices or configurations.

Best regards

Neuvi

Answer 2

Most of this was validated during the support case I had open ~2 years ago but I went back through all the configurations per your request.

Check the NPS server configuration:
This has been tested. The network policy on the NPS server is, to the best of my ability/recognition, configured correctly, with EAP-TLS specified as the authentication method and the correct encryption settings applied.

Verify the certificate chain of trust on the NPS server:
The CA root certificate issued to the client certificate is trusted by the NPS server(s), clients, and domain controllers. This has been verified, and the certificate chain is complete.

Check the logging settings of the NPS:
Logging settings have been reviewed, and all relevant logs are captured. No logs found on domain controllers as noted and NPS and client side logging indicates the radius authentication failed, on NPS side Packet 3, Reason 16, client side wired auto-config authentication failures, no relevant logs found on DCs.

Certificate Validation:
Both the NPS and client certificates were checked again, and their OID, SAN, validity, and revocation status were confirmed to be correct. The CRL checking is enabled, and the certificate chain integrity was verified. No issues were found.

Ensure that the client certificate is valid and trusted:
The client's certificate is valid, and the client trusts the CA that issued the certificate.

Client Configuration:
The 802.1X settings on the client computer were reviewed, and the EAP-TLS configuration was verified, including specifying the correct certificate. The client system is up to date with the latest patches and drivers. No change in behavior was observed.

Network Issues:
Network traffic between the NPS server and the client was captured using Wireshark. No anomalies or errors were detected during the EAP-TLS handshake. Network devices like switches and routers have been confirmed to be correctly configured for 802.1X and EAP-TLS. EAP-TLS fails only when strong authentication is enabled, otherwise 802.1X works as expected.

System logs and events:
While event IDs 39, 40, and 41 are not appearing, other relevant logs on the NPS server, including security and system logs, have been checked. No new clues were found by going through the logging.

Domain controller and Kerberos configuration:
The Kerberos service on the domain controller has been configured correctly, and the registry entry for KDC are being set to 2 during testing and the KDC service is restarted after each registry change. System logs on the domain controller were checked for any Kerberos-related issues, with no errors found.

Updates and patches:
All servers involved (NPS, ADDS, and CAs) have been confirmed to be up to date with the latest patches, at least to Aug 2024.

Testing and troubleshooting:
The issue was reproduced in a simplified environment, tests were conducted using as similar as possible configurations. Strong certificate authentication functions as expected in the test/lab environment. Configurations match against prod but obviously different behavior is observed. The most notable of which is the lack of event logs 39-41. In lab environment a strong certificate failure can be induced and those logs show up on the domain controllers. In prod those logs have never been witnessed.