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

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.