in May 2022 Microsoft changed the way that client certificates are mapped to AD accounts, causing 802.1X EAP-TLS computer account authentication to stop working. Here is an additional resource with detailed background info on the Schannel<=>Kerbers S4U2Self authentication
The solutions available for this were:
- Create strong mappings using the altSecurityIdentities mapping
- Using the new certificate extension szOID_NTDS_CA_SECURITY_EXT
- Temporarily disabling Schannel<=>Kerberos S4u2Self via the CertificateMappingMethods registry key and setting flag 0x4 for SAN certificate mapping
This all works well if the NPS server and client computer account are in the same domain. In our scenario, however, the NPS server is in the root domain of the forest, and the client computer account is in a subdomain. This causes the computer accounts in all subdomains to fail to authenticate with reason code 16, with events 4625 and 6273 to be logged on the NPS server.
Computer accounts that are in the root domain (like the NPS server) can authenticate successfully
The problem appears to be lying somewhere between the Schannel and Kerberos authentication:
- Setting the CertificateMappingMethods key on all subdomain controllers and NPS server to 0x1F makes authentication work (unfortunately only temp solution)
- Creating strong mappings using the altSecurityIdentities mapping has no effect; no events logged on DC; no change in error on NPS server; no noticable difference
- Using the new certificate extension szOID_NTDS_CA_SECURITY_EXT has no effect; authentication still fails
The errors logged on the RADIUS server are:
Event 4625
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: <NPS SERVER>$
Account Domain: <NPS SERVER DOMAIN>
Logon ID: 0x3E7
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064
Process Information:
Caller Process ID: 0x278
Caller Process Name: C:\Windows\System32\lsass.exe
Network Information:
Workstation Name: <NPS SERVER>
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Schannel
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event 6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: <CLIENT DOMAIN>\<COMPUTER ACCOUNT>$
Account Name: host/<client DNS>
Account Domain: <CLIENT DOMAIN>
Fully Qualified Account Name: <CLIENT DOMAIN>\<COMPUTER ACCOUNT>$
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: 6E-22-32-2F-19-CF:<SSID>
Calling Station Identifier: 84-38-38-86-82-C2
NAS:
NAS IPv4 Address: <ap ip>
NAS IPv6 Address: -
NAS Identifier: 6e22322f09cf
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1
RADIUS Client:
Client Friendly Name: <ap name>
Client IP Address: <ap ip>
Authentication Details:
Connection Request Policy Name: Secure Wireless Connections
Network Policy Name: Secure Wireless Connections
Authentication Provider: Windows
Authentication Server: <DOMAIN CONTROLLER FQDN>
Authentication Type: EAP
EAP Type: Microsoft: Smart Card or other certificate
Account Session Identifier: 43323444383435463834444530463634
Logging Results: Accounting information was written to the SQL 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.
It appears that somehow the NPS server fails to get a Kerberos ticket for the subdomain; but I am not sure.
So, to sum up: Authentication works, unless the client is is a two-way trusted subdomain of the same forest as the NPS server (or sibling domain).
Also tried:
- Add NPS server to "RAS and IAS Servers" group in subdomain
What configuration options are we missing??
