Unable to get Kerberos ticket with ZPA

I noticed that certain users are unable to get/fetch kerberos tickets with ZPA. Kerberos team states that,it might be DNS issue or reach ability issue. We are sure that, there shouldn’t be reach ability issue and other users can get/fetch kerberos ticket. Issue happens in certain machine and its consistent. When we execute "klist get , we get error as below.

Current LogonId is 0:0x969xyz
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x51f
klist failed with 0xc000005e/-1073741730

Did anyone experienced similar issue with ZPA?

Ganesh Krishnan

Hi Ganesh,

Best practice is to configure your domain controllers into an App Segment and add the ports Microsoft uses to authenticate such as 88, 389 etc. ensure there is no reauthentication timeout on the Access Polcy.

Yes we have created individual App seg for Domain controller and allowed necessary ports. We have multiple application authenticates using the Domain controller. Issue we notice something specific to getting Kerberos ticket. Error is very much generic stating “machine has to be part of Domain”.

Kerberos team suspect that machine has some issue related to DNS. As per them machine will use DNS server to find SITES and kerberos server in that SITE. If it cannot get response, then it fails to identify the Domain.

Ganesh Krishnan


Kerberos will require SRV records to be received by user’s device. With ZPA, this translates to a wild card domain on any port. Can you check 1) if such a domain is configured 2) SRV records are coming back to user’s device.

 We allowed wildcard address. i get ZPA elastic IP when i ping the Url in SRV record. ZPA policy is applied only when a user tries to reach internal servers. In this case, user machine send DNS query (SRV record) to Gateway router. Zapp intercepts the DNS request and give ZPA elastic IP. Machine never connects to the elastic IP it got from SRV records. Theoretically, we can say that this DNS communication (port 53) will not come to ZPA itself. 

  We identified an workaround for this issue. Configuring External DNS server in user machine or gateway router, fixes the issue. I read in some forums stating that some gateway router doesn't handle SRV records properly and it fails. Configuring External DNS will fix the issue rather than using DNS proxy (gateway router). 

Consider that we pin pointed the issue till DNS layer. However we are not sure why other users can connect without any issue. Added to that, Google DNS cannot resolve our SRV record. I haven’t identified the inner working in this flow yet. The gateway router products causing the issue are NetGear and Unifi so far.

“machine has to be part of the domain” usually indicates the service record of the machine in the domain may have gotten corrupted… Try removing the machine from the domain, then re-adding it and see if the problems go away.

1 Like

The issue occurs only with ZPA. Whereas same machine can get Kerberos ticket with our traditional VPN.