Entra Private Access & Windows Hello for Business Kerberos Trust – Network Drive Fails for 10 min. after restart and user login

If you are using Entra Private Access (or other SSE solutions) – together with Windows Hello for Business Kerberos Trust, you might experience that access to network drives fails for 10 mins. after restart and user login. Error “The system cannot contact a domain controller to service the authentication request”. After 10 min, it works !

Root Cause

Client is trying to connect to closest DC for Kerberos ticket but fails as Entra Private Access (EPA) is still not connected or DC is not reachable at that moment. Once this request fails, it does not try to connect again for next 10 minutes as this is the default value.

During the default 10 min, EPA is connected and Private DNS resolution is working. However, client is still holding that negative cache entry and thinks that the DC locate process is not working. Once the time is reached, client can query DC for ticket and the connection is successful.

End-user experience

Below are 2 examples of end-user messages. As you can see, they will increase the helpdesk calls so my focus has been to find the best solution. Please see Workaround Method #1 below.

Workaround Method #1 (best end-user experience)

As part of my testing, I have found that setting the parameter FarKDCTimeout to 0 (disabled), gives the best end-user experience.

You can read about the settings here

Entry: FarKdcTimeout


Default value: 10 (minutes)

It's the time-out value that's used to invalidate a domain controller from a different site in the domain controller cache.

Recommended setting

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name FarKdcTimeout -PropertyType DWORD -Value "0" -Force

Consequences (please evaluate according to your environment)

Setting the FarKdcTimeout registry value to 0 means that the system will not wait before trying to connect to a domain controller (DC) again after a failed attempt. This means that the client will immediately try to connect to the DC again if the first attempt fails, instead of waiting for the time specified in the FarKdcTimeout value. 

This can help reduce the time it takes for the client to obtain a Kerberos ticket from the DC, but it may also increase the load on the DC if there are many clients repeatedly trying to connect.

The extra load will only happen until the EPA client is running and then the connections to DCs are available and KDC will be happy.

Workaround Method #2 (not the best !)

You can also lower the KDC negative caching to e.g. 1 min, but in my experience end-users see will start to see errors during that 1 min, when they try to access e.g. network drives – and especially the popup “Windows needs your current credentials” causes calls to helpdesk.

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name FarKdcTimeout -PropertyType DWORD -Value "1" -Force

Workaround Method #3

You can also resolve the issue with an scheduled task using script below which executes the command KLIST PURGE_BIND to run after user logon – after waiting initially 10 sec. This command will delete the negative cache entry.

C:\Windows\System32>klist purge_bind

Current LogonId is 0:0xxxxx
The kerberos KDC binding cache has been purged successfully.
powershell.exe -Command "Start-Sleep -Seconds 10; KLIST PURGE_BIND"

More info

Issue has been reported to Entra Private Access product team to se if they can fix this as part of EPA.

Script for Intune (Workaround #3)

$Action = New-ScheduledTaskAction -Execute 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ' -Argument '-Command "Start-Sleep -Seconds 10; KLIST PURGE_BIND"'

$trigger =  New-ScheduledTaskTrigger -AtLogOn

$STPrin = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -Action $action `
                       -Trigger $trigger `
                       -TaskName "Intune_Kerberos_Negative_Cache_Reset" `
                       -Description "Intune_Kerberos_Negative_Cache_Reset" `
                       -Principal $STPrin

14 thoughts on “Entra Private Access & Windows Hello for Business Kerberos Trust – Network Drive Fails for 10 min. after restart and user login”

  1. Hi,

    great analysis. Can you outline which ports you had to open Entra Private Access and Cloud Kerbeors Trust. Is Kerberos tcp/udp 88 to the domain controller sufficient?


    • Thx. Please see the updated findings, I have just published https://mortenknudsen.net/?p=2965

      Are you using Private DNS resolution (preview right now) ? You can see it if you access the portal using aka.ms/vpnreplacement – click ‘Global ASecure Access (preview) – Applications – Quick Access
      If you are doing a Proof-of-Concept with Private DNS solution in EPA, you can consider to open for the specified networks using TCP/UDP 0-65535. Remember this setting opens for all ports, so it should be for testing only. Lastly, remember that Private DNS resolution is only supported in the Quick Access feature right now (not the Enterprise Applications-mode)

      Normal AD authentication/communication + network drive access requires these ports:
      TCP 389 – Used by clients for accessing directory services for reading and querying objects in Active Directory.
      UDP 389 – Occasionally used for LDAP network operations.
      TCP/UDP 88 – Essential for Kerberos-based authentication between clients and the domain controller.
      TCP 445 – Used for access to shared resources, such as file shares and printers,
      TCP 135 – Used by the RPC Endpoint Mapper, which assists in dynamic port allocation for services such as replication and DCOM (Distributed Component Object Model) services.
      Dynamic RPC Ports – Although primarily a concern for server-to-server communication (like AD replication), clients may occasionally need to communicate over dynamically allocated high ports (typically 49152-65535 on modern systems) for certain operations.
      TCP 139 and TCP 445 – For passing logon and authentication messages.
      UDP 123 – For time synchronization with the domain controller, which is crucial for Kerberos operation.

  2. I cannot get this to work. I have an Azure ad-computer with WHFB setup. When I try to access a network share over Entra private access I get a message that I cannot access the domain controller.

    I tried nltest /dsgetdc:domain and it gives me this error:
    Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

    Do you have any idea what I am missing?
    Thank you!

    • Does it work if you have line of sight to DCs?

      Have you enrolled in Private Dns (private preview right now) ?

  3. Hi Morten,

    We haven’t been enrolled in the “Quick access” private preview. But the url you mentioned aka.ms/vpnreplacement enables the gui for both UDP and Private DNS.
    UDP works, I can configure UDP port which also get picked up by the GSA client.
    But I cannot save the Private DNS settings. As soon as I enable Private DNS, and try to save. The following error message show:
    Application could not be saved due to errors. Please review and make the appropriate changes.

    You have a suggestion ? Or do have to be enrolled by MS? Thanks, mories.

    • Microsoft has upgraded UDP from private preview to public preview. The changes are under deployment for portal, which is why you need to use aka.ms link. Soon you won’t even need aks.ms link for UDP.
      for Private DNS, it is still under private preview and needs whitelisting from backend side. Hopefully it will be available public sometime in July.

  4. Hi,

    great analysis, thank you. We have configured Entra Private Access & Windows Hello for Business Kerberos Trust and it works as expected if the user is working inside corporate network. If the user is on the road WhfB is not working. The user has to login with username/password to access SMB shares. Is this an expected behaviour?


  5. Is there any formal response from Microsoft about the reported issue, are they actively investigating (and looking to resolve)?

    • I just verified with the lead PM. Problem is acknowledged and is in the backlog to be fixed. Workaround is to use recommendations from this article. Once we have a official fix, I will inform

      • That’s perfect thanks. We’ve implemented the reg key and now all works as required. Hopefully we get the official response / fix from Microsoft soon.


Leave a Reply