Share via

frequent “Access Denied (0x00000005)” on shared printers with Windows 11 + WHFB (Kerberos ID 208 errors)

young leo 1 Reputation point
2026-06-04T20:06:37.7633333+00:00

I’m a Level 1–2 IT technician at a company currently deploying Windows 11 devices enrolled in Intune with Windows Hello for Business (WHFB).

Since this rollout, we’ve been experiencing an intermittent “Access Denied” (0x00000005) error when users try to access printers shared from our file server. Based on our observations so far, this issue seems affecting the majority (~99%) of devices that are running Windows 11 + WHFB.

Issue behavior

The symptoms are somewhat inconsistent but reproducible with these steps:

  1. Restart the computer
  2. Sign in using PIN (WHFB)
  3. Open File Explorer and navigate to the file server
  4. Double-click any shared printer
  • The first attempt usually opens the print queue successfully
  • After closing the queue, a second attempt often results in:

“Access Denied” (0x00000005)

If we continue retrying, the issue may:

  • Resolve itself temporarily, or
  • Persist for a random period of time

Running klist purge or klist purge_bind does not appear to make a difference.

Event Viewer findings

Each time of double clicking when the issue persists, we see a few errors Event ID 208 under:

Applications and Services Logs > Microsoft > Windows > Security-Kerberos

The Kerberos client and KDC could not agree on a policy compliant hash algorithm for PKINIT.

Client supported algorithms: { 2.16.840.1.101.3.4.2.3, 2.16.840.1.101.3.4.2.2, 2.16.840.1.101.3.4.2.1 }

KDC supported algorithms: { }

Additional symptoms

On affected machines:

  • gpupdate /force often fails
  • We see the following errors in System logs:

Event ID 1055

Windows could not resolve the computer name (possible DC resolution or replication issue)

Event ID 1006

Windows could not authenticate to Active Directory (LDAP bind failed)

However:

  • DNS resolution appears to work correctly (nslookup, Resolve-DnsName return valid results)

Comparison with non-affected devices

Devices upgraded from Windows 10 → Windows 11 that did NOT successfully receive WHFB policy:

  • Do not exhibit this issue
  • Can access shared printers normally
  • Do not log the Kerberos ID 208 error

Question

This seems related to Kerberos PKINIT / WHFB authentication and potentially domain controller configuration (e.g., supported hash algorithms or certificate setup).

Has anyone encountered similar issues, or can suggest what server-side settings (KDC, certificate templates, crypto policies, etc.) we should review or adjust?

Any guidance would be greatly appreciated.I’m a Level 1–2 IT technician at a company currently deploying Windows 11 devices enrolled in Intune with Windows Hello for Business (WHFB).

Since this rollout, we’ve been experiencing an intermittent “Access Denied” (0x00000005) error when users try to access printers shared from our file server. Based on our observations so far, this issue affects the majority (~99%) of devices that are running Windows 11 + WHFB.

Issue behavior

The symptoms are somewhat inconsistent but reproducible with these steps:

  1. Restart the computer
  2. Sign in using PIN (WHFB)
  3. Open File Explorer and navigate to the file server
  4. Double-click any shared printer
  • The first attempt usually opens the print queue successfully
  • After closing the queue, a second attempt often results in:

“Access Denied” (0x00000005)

If we continue retrying, the issue may:

  • Resolve itself temporarily, or
  • Persist for a random period of time

Running klist purge or klist purge_bind does not appear to make a difference.

Event Viewer findings

Each time the error occurs, we consistently see Event ID 208 under:

Applications and Services Logs > Microsoft > Windows > Security-Kerberos

The Kerberos client and KDC could not agree on a policy compliant hash algorithm for PKINIT.

Client supported algorithms: { 2.16.840.1.101.3.4.2.3, 2.16.840.1.101.3.4.2.2, 2.16.840.1.101.3.4.2.1 }

KDC supported algorithms: { }

Additional symptoms

On affected machines:

  • gpupdate /force often fails
  • We see the following errors in System logs:

Event ID 1055

Windows could not resolve the computer name (possible DC resolution or replication issue)

Event ID 1006

Windows could not authenticate to Active Directory (LDAP bind failed)

However:

  • DNS resolution appears to work correctly (nslookup, Resolve-DnsName return valid results)

Comparison with non-affected devices

Devices upgraded from Windows 10 → Windows 11 that did NOT successfully receive WHFB policy:

  • Do not exhibit this issue
  • Can always access shared printers
  • Do not log the Kerberos ID 208 error

Question

This seems related to Kerberos PKINIT / WHFB authentication and potentially domain controller configuration (e.g., supported hash algorithms or certificate setup).

Has anyone encountered similar issues, or can suggest what server-side settings (KDC, certificate templates, crypto policies, etc.) we should review or adjust?

Any guidance would be greatly appreciated.

Windows for business | Windows 365 Enterprise
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Steven Nguyen (WICLOUD CORPORATION) 85 Reputation points Microsoft External Staff Moderator
    2026-06-08T08:52:53.2766667+00:00

    Hello Young Leo, thank you for posting in the Microsoft Q&A community and providing such an incredibly detailed report.

    I have investigated the intermittent Access Denied (0x00000005) error occurring when Windows 11 devices enrolled in Intune and using Windows Hello for Business (WHFB) attempt to access shared printers on the file server.

    Based on our research and the event logs provided (specifically Event ID 208), it might be an incompatibility between Windows 11 security enhancements and the current Active Directory PKI configuration.

    My investigation indicates that the issue is caused by a mismatch between:

    • The authentication method used by WHFB (PKINIT / certificate-based Kerberos).
    • The current DC certificate configuration in your environment.

    Specifically:

    • Domain Controllers are currently using legacy certificate templates (such as Domain Controller or Domain Controller Authentication).
    • These templates do not include the KDC Authentication object identifier (OID) required for modern Kerberos certificate authentication scenarios.

    Authentication Failure:

    • Event ID 208 (KDC supported algorithms: { }) indicates that your DCs (KDCs) are presenting a certificate that does not meet these new Windows 11 requirements (e.g., it is using SHA-1 or is missing the KDC Authentication OID).

    Supporting Documentation:

    Recommendation:

    You can proceed with either the permanent infrastructure fix or a temporary client-side workaround.

    1. Resolution A:

    Access your internal CA server and open the Certificate Templates Console (certtmpl.msc).

    Verify / Update or Duplicate the Kerberos Authentication certificate template. Ensure that:

    • Compatibility:  CA and Certificate Recipient levels are Windows Server 2008 or higher.
    • Cryptography:
      • Provider Category: Key Storage Provider (KSP)
      • Minimum hash algorithm: SHA256 or higher
    • Extensions: The Application Policies include the KDC Authentication OID.

    Issue this updated Certificate Template to all DCs and ensure all DCs obtain the new certificate.

    On each DC, open certlm.msc, remove the old or incompatible KDC certificates,

    Please ensure that the DC has been issued the new certificate based on the updated template and then run "Restart-Service Kdc" to apply the new certificate.

    Have affected users Sign Out completely and Sign In again with their WHFB PIN.

    2. Resolution B:

    If immediate PKI changes are not feasible, a temporary workaround can be applied:

    • Configure the PKInitHashAlgorithmConfiguration policy via Intune
    • Allow additional (legacy) hash algorithms (such as SHA-1) by setting them to Supported

    If this helps resolve your problem, please consider hitting "Accept Answer" so other users facing this failure can easily find the solution!

    Was this answer helpful?

  2. AI answer

    2026-06-04T20:07:00.76+00:00

    The described symptoms match known Kerberos/printing issues on Windows 11 after specific updates, especially where WHFB and Kerberos are involved. There are two main areas to check: domain controller patch level (Kerberos issues) and Windows 11 print/RPC configuration.

    1. Verify and remediate DC Kerberos update issues

    On environments where Windows 11 clients and WHFB are used, Kerberos issues can appear after certain security updates on domain controllers. Microsoft documents a known issue where, after installing November 8, 2022 or later updates on Windows Servers with the Domain Controller role, Kerberos authentication can intermittently fail and affect:

    • Domain user sign-in
    • Access to shared folders and file shares
    • Printing that requires domain user authentication

    This is consistent with:

    • Intermittent “Access Denied (0x00000005)” when accessing shared printers
    • Group Policy failures (gpupdate /force failing)
    • Event ID 1006 and 1055 (LDAP bind and DC resolution/authentication issues)

    Action:

    • Confirm whether DCs have the November 8, 2022 (or later) security updates installed without the corresponding out-of-band (OOB) fixes.
    • If so, install the appropriate OOB cumulative or standalone updates on all domain controllers as documented:
      • Windows Server 2022: KB5021656
      • Windows Server 2019: KB5021655
      • Windows Server 2016: KB5021654
      • Windows Server 2012 R2: KB5021653
      • Windows Server 2012: KB5021652
      • Windows Server 2008 SP2: KB5021657

    These OOB updates specifically address Kerberos authentication problems that can affect printing and access to shares. No changes are required on member servers or clients beyond installing these DC updates.

    1. Check Windows 11 print RPC configuration and firewall

    Windows 11 introduces RPC connection changes for printing that can surface as access/connection issues to shared printers if RPC over TCP is blocked or misconfigured.

    Recommendations:

    a. Ensure RPC over TCP is allowed

    On the print/file server hosting the shared printers:

    • Ensure firewall allows:
      • RPC Endpoint Mapper port 135
      • High-range ephemeral ports 49152–65535 (or a defined RPC port range) for RPC over TCP
    • If using a restricted port range, configure it per “Configuring RPC to use certain ports” guidance and open that range on the firewall.

    b. Avoid forcing RPC over Named Pipes unless necessary

    • The recommended configuration is RPC over TCP. Using RPC over Named Pipes is supported but not recommended and may require extra configuration.
    • If RPC over Named Pipes must be used, ensure:
      • RpcAuthnLevelPrivacyEnabled is set to 0 on the server/host as per the documented guidance.
      • Any required SMB guest access settings are configured if applicable.

    c. If using Group Policy to control print RPC

    On affected Windows 11 clients and/or the print server, verify these policies under:

    Computer Configuration > Administrative Templates > Printers

    Key settings:

    • Configure RPC connection settings
      • Prefer RpcOverTcp (default) unless there is a specific requirement for RpcOverNamedPipes.
    • Configure RPC listener settings
      • Ensure protocols allowed are set to allow RPC over TCP (for example, RpcOverNamedPipesAndTcp if Named Pipes is also needed).
    • Configure RPC over TCP port (optional)
      • If a specific port is configured, ensure that port is open on firewalls.
    • Configure RPC listener settings – enforce Kerberos authentication
      • If enforcing Kerberos here, ensure DCs and clients are fully patched and Kerberos is functioning correctly (see step 1). Misalignment here can contribute to the Kerberos Event ID 208 behavior.
    1. Validate after remediation

    After applying the DC OOB Kerberos updates and verifying print/RPC configuration:

    • Restart all domain controllers after patching.
    • On a test Windows 11 + WHFB client:
      • Reboot the client.
      • Run gpupdate /force and confirm it completes without Event ID 1006/1055.
      • Test accessing the shared printers multiple times from File Explorer.
      • Monitor for recurrence of Kerberos Event ID 208.

    If the Kerberos and RPC/printing configuration issues are resolved, the intermittent “Access Denied (0x00000005)” when accessing shared printers should stop, and Group Policy and LDAP bind errors should also clear.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.