Forum Discussion
Windows 11 24H2 Sec Baseline → Broken SSO to on‑prem (Root cause: PKINIT SHA‑1 baseline)
Hi all,
I ran into an issue with Entra-joined devices using Windows Hello for Business (Cloud Kerberos Trust) that might help others working with Windows 11 24H2 security baselines.
Scenario
- Windows 11 25H2 devices
- Entra-joined (not hybrid)
- Intune-managed
- Windows Hello for Business (WHfB) enabled
- Cloud Kerberos Trust configured
- On-prem AD (Windows Server 2019/2022 DCs)
- Access to SMB shares / on-prem applications
Symptoms
- SSO to on-prem resources fails
- Users get credential/PIN prompt instead of SSO
- Error message:
“The system cannot contact a domain controller to service the authentication request”
Client-side observations:
klist → no tickets (initially)
After enabling Cloud Kerberos Trust:
klist get krbtgt → works klist get cifs/server.domain → fails
Error:
0xc000a100 / 0x3bc4 Hash generation for the specified version and hash type is not enabled on server
Root Cause
The issue was caused by a Windows 11 24H2 security baseline setting related to Kerberos/PKINIT.
The 24H2 baseline introduces a policy for configuring hash algorithms for certificate-based Kerberos authentication (PKINIT). This setting allows environments to disable SHA-1 and require SHA-2 algorithms. [applepie.se]
Important detail:
This configuration only works if the domain controllers fully support PKINIT with SHA-2, which effectively requires Windows Server 2025 domain controllers across the environment.
If SHA-1 is disabled while running:
- Windows Server 2019 or 2022 DCs
- Mixed environments
then PKINIT authentication fails, which directly impacts:
- Windows Hello for Business
- Cloud Kerberos Trust
- Any passwordless Kerberos-based authentication
Why this is difficult to troubleshoot
- Cloud Kerberos Trust appears correctly configured
- AzureADKerberos object exists
- PRT is valid
- Network connectivity is fine
However:
- Kerberos tickets are not issued correctly
- Service tickets (CIFS, HTTP, etc.) fail
- Errors are misleading and point to KDC/hash issues
- No explicit warning is provided in baseline guidance that mixed environments will break
Resolution
Revert the baseline change and allow SHA-1 for PKINIT again.
Policy location:
Computer Configuration → System → Kerberos / KDC → Configure hash algorithms for certificate logon
Ensure:
- SHA-1 is set to Allowed/Default
After reverting:
- Kerberos ticket issuance works
- SSO to on-prem resources is restored
Recommendation
Do not disable SHA-1 for PKINIT unless:
- All domain controllers are Windows Server 2025, and
- PKINIT SHA-2 support has been fully validated
Treat this setting as future hardening, not production-safe for mixed environments today.
Takeaway
If you experience:
- WHfB + Cloud Kerberos Trust SSO failures
- klist get errors with hash generation issues
- Missing or failing Kerberos service tickets
check the PKINIT hash configuration from the 24H2 security baseline first.
3 Replies
Thanks Steve, let me know if any luck.
Hey Stephen, Thanks for this detailed article. This is exact issue we are facing. Our scenario is, we want to migrate the on premise file server shares to Azure Files. We joined the Storage account to on prem AD. ie ADDDS based identity. Intune devices are able to map the drive, but prompt for credentials coming. we do not want that. They are very well able to map on premise shares, without prompt. But they are not able to map the Azure File shares from ADDS joined storage account silently. it prompts for credentials and then it maps. Is this the same cause?
But does it work afterwards?
Then it seems not to be related - i am also playing around with Azure Files atm. I also get the popup - if i found a solution for this - i will post it here.
Back in the days it helped to put the FQDN into the "Intranet" Zone
