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
Type: REG_DWORD
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" -ForceConsequences (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" -ForceWorkaround 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
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?
Thanks
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.
Hi Morten, question: is there any system to figure out which ports/addresses are used to connect to a particular application where I have installed the global secure access client? I have opened the necessary ports provided by the software manufacturer but the connection doesn’t work; I have also tried opening all of them but that doesn’t work either
all communication with the GSA client and microsoft runs on 443. But inside the tunnel, it depends on the client. If TCP/UDP 0-65535 doesn’t work, then it seems as the scoping of IPs and/or FSDN isn’t working as expected.
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) ?
fgwdf
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.
Thank you very much for the clarification.
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?
Regards
Sandro
that is expected behavior, as we always want to protect the user with MFA if they are at non-trusted locations
Entra Private Access adds a second level of security, separate from the tunnel functionality
Thx Morten
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.
Hey Morten, while browsing for a solution to our problem we finally landed on your page. Only our problem is a little bit different:
First off: If it works, it does a great job, and we just recently implemented UDP related things like Kerberos, and it also just works great.
We then extended the range of our devices for testing, and for some of them it also just works. But on some devices it just works once, and once you restart the computer, we have a red exclamation mark and the rules are ignored. We can’t find any hints in the logs on why that is – and better: it appears that there is traffic going to our internal servers, but nothing works. Health check shows everything in green (but IPv4 preferred), but we do have the exclamation mark in the tray.
Reinstallation of the client does not change anything.
This article is the closest thing to our solution, and we’ve been looking for a fix or a hint on this issue for quite some time, since we tried GSA in beta as well.
THanks for all the good work you’re doing!
is there a difference on the machines on WHfB login ?
Does it work if you use password instead of PIN code vs. biometric ?
Wow, that was quick – we’ll be checking that, will get back to you.
Hi Morten,
so, we checked: it is always password login, and it seems only Laptops running Windows 10 are affected. We haven’t hat this issue on our W11 testing machines yet.
We have also tried cleaning up the registry before we tried reinstallation (since reinstallation does not work other way) – we’re back to square one then, it works until the system is rebooted.
Hi Mortan,
I have been testing Entra Private access with SSO to connect to domain resources – A file server share. I have got line of sight to all the domain controllers via GSA client and have setup network segments for the domain controllers and file server and enabled private DNS. When I access the file server I am still being asked to authenticate with a username and password. I can access the resource after authenticating. My understanding was that as long as my Device is Entra Joined and connected to the private network I should be able to connect to my file server.
The Entra joined device is connecting from remote location to the private network. It also has windows hello with PIN setup via Intune. Have I missed any config steps in the Setup or is the behaviour expected?
Thanks in advance,
Prav
Hi Morten,
Do you have any news on the intelligent local access feature?
I’ve been doing some testing by enabling RDP port 3389 over private access to one of my on-prem servers. When working remotely the latency is much higher and bandwidth lower vs on-prem. In both cases I’m not using your script or otherwise disabling private access. I’m using the private DNS feature to resolve the FQDN of the server in question.
My feeling was that maybe the local access feature has quietly gone live? I’ve not been able to confirm one way or another.
Regards
Robert
I guess is it will come 1H-CY2025
Tentative deadline for functionality in preview is 1H-CY2025
Hi Morten,
Sorry you seem to be the main person posting about this right now so another question incoming I’m afraid.
With a hybrid joined client offsite, no line of site to DCs, Kerberos cloud trust, logging in with FIDO2 to windows I can browse to and access a QuickAccess published fileserver via \\Fileserver\share and even access \\DC-hostname but NETLOGON and SYSVOL shares both prompt for user/pass. I’m only getting 1 klist ticket issued by kerberos.microsoftonline.com.
Private access enabled, have published FQDN of my forest root and child domain where user resides and various combinations of publishing all DCs, all ports, TCP/UDP but nltest /dsgetdc:domainFQDN always gives an error:
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
I’m wanting to use as a VPN replacement for a few fileshares and basic access to on prem DCs/GPOs etc. Is there some missing piece of the puzzle that you can think of ?