Alright I can confirm that this issue does appear to only affect Windows Server 2025, Forest Functionality Level doesn’t seem to matter. A DC running server 2022 and older do not exhibit this issue.
The offending setting is “KDC support for PKInit Freshness Extension” if this is setting to Required or Support the join with TrueNas will fail. This must not be set or set to disabled in order to allow TrueNas to join the domain. A DC restart is not required but can always perform the tried and true “gpupdate /force” on the DC(s).
For those that don’t know, PKInit Freshness Extension, setting to support or required is a best practice to hardening the PKInit protocol for PKI based authentication. This allows for smartcard authentication within the domain.
I’d suspect Enterprises will have the above setting enabled however, the reason its not more widespread is likely because this is only affecting Domain Controllers running Windows Server 2025 and have the above mentioned setting set in GPO.
Enterprises are historically slow to adopt new OS’s and they might have a mix bag of DC’s if the domain contains mixed Server 2025 and older this issue might hide in the domain until all DCs are Windows Server 2025.
This feature was introduced in Windows Server 2016 and I will provide a link to some additional reading for those that work in a Microsoft AD environment as it might be useful to them.
Is the root cause not that setting directly, but having the setting enabled cause the TrueNAS Kerberos client to try PKInit which it otherwise doesn’t try with the setting disabled?
MIT Kerberos has supported PKInit Freshness extensions for ages but PKInit does need to be configured; from Claude:
Client Configuration
On client hosts, you must set the pkinit_anchors variable (and possibly pkinit_kdc_hostname and pkinit_eku_checking) in krb5.conf to trust the issuing authority for the KDC certificate MIT MIT. The basic PKINIT client configuration remains the same as for non-freshness PKInit.
I wouldn’t deny It is possible that Windows Server 2025 has a bug or a default hardening configuration that is causing this failure, or it could be a bug in TrueNas. I am not placing blame on Windows or TrueNas as I simply don’t have enough evidence to backup such a claim.
However what I can provide is evidence of the overall experience based on the testing I performed. If the setting is set to “Supported” on the KDC and TrueNas isn’t configured to use PKInit, the expectation would be that TrueNas wouldn’t request PKInit and the join would be successful. A Supported value for PKInit allows the KDC to use the PKInit Freshness Extension upon client request.
In my testing having that setting set to “Supported” on a Windows Server 2025 Domain Controller causes TrueNas to fail the join, I would expect if this setting were set to “Required” and TrueNas wasn’t configured for it that the join would fail. If the setting is set to “Disabled” or the overall policy setting set to "Not Configured, TrueNas will successfully join AD.
Having the setting set to “Supported” on a Server 2022 Domain Controller and 2019, these were the other two I tested, TrueNas will successfully join AD. In my environment I had PKInit set to supported and hadn’t made the step to required and I had moved to Server 2025 Domain Controllers.
PKInit has been set in my Active Directory Domain since the release of Windows Server 2016. I had upgraded my forest over time and adopted Windows Server 2025 and everything TrueNas related was still working. The only time this issue came up for me was when I made the upgrade between TrueNas Core to TrueNas Scale and I had the above mentioned setting set on a Server 2025 Domain Controller.
Sorry, that’s not what I meant. PKInit needs to be configured on the client side to trust the certificate on the domain controller. The feature you enabled relates to PKInit and might cause the client to try PKInit when it ordinarily would not. Have you tried doing the PKInit config on TrueNAS?
There are also issues with AD 2025 binding in redhat as well, I think truenas is using the same backend (winbind). I’m running 2019 AD and haven’t had any issues.
