Despite there beeing multiple explanations that access to an on-prem fileshare / print server should “just work” from an Entra ID Joined client as long as a few basic pre-requisites are inplace – there always seems to be some hiccup revealing itself when implementing new clients.
Peter Klapwijk described a time-out issue to a requesting a Kerberos-ticket and not receiving one – requiring a 10 minute reset period which then causes an aggrevating user experience. Issue not beeing isolated to EIDJ-clients, but rather a behaviour that can happen when a network change is not imposed due to VPN for example connecting and also explained in further detail by Morten Knudsen.
In addition to the above there have been a new setting introduced with the Windows 24H2 Windows Security Baseline – which explains a new hash algoritm for certificate logon impacting the ability to recieve new Kerberos-tickets. It is recommended to test this alongside a Windows Server 2025 based on the stated news;
A new setting, located at System\KDC and System\Kerberos, has been added for smart card crypto agility. This setting lets users configure the hash algorithm to be used in certificate-based smart card (PKINIT) authentication of Kerberos. With this configuration, customers have the option to prevent SHA-1 from being used. The security baseline recommends support for SHA-256, SHA-384, and SHA-512, but does not recommend support for SHA-1. It’s important to note these settings are useful only if both the client and KDC (Windows Server 2025) are configured this way in the environment.
Note that the Windows Server Security Baseline has the same announcement;
Configure hash algorithms for certificate logon
The policy Configure hash algorithms for certificate logon has been added for smart card crypto agility, located at System\KDC and System\Kerberos. This setting lets users configure the hash algorithm to be used in certificate-based smart card (PKINIT) authentication of Kerberos. With this configuration, customers have the option to prevent SHA-1 from being used. It’s important to note these settings are useful only if both the client and KDC (Windows Server 2025) are configured this way in the environment.Disabling SHA-1 for PKINIT is more secure for your environment. However, the authentication might fail if your domain controller does not support PKINIT SHA-2. For that reason, we leave the SHA-1 option as default in the baseline and suggest you test your own environment before making a decision.
The experience for the end-user when the systems aren’t aligned (client and server) is a very common prompt for username / password when attempting to access a fileserver with the error message “The system cannot contact a domain controller to service the authentication request.”
Reviewing the System Event Log – a 40960 event from LSA can be seen indicating the culprit
The Security System detected an authentication error for the server The failure authentication protocol Kerberos was “Hash generation for the specified version and hash type is not enabled on the server”
If the setting PKInitHashAlgorithmConfiguration is enabled in Kerberos Policy CSP | Microsoft Learn, alongside PKInitHashAlgorithmSHA1 on the client beeing configured as Not Supported without also ensuring that the backend has this inplace (server) – this conflict will happen and the end-user might receive the username / password prompt with the error message that a domain controller is not available.