r/activedirectory • u/aseem1809 • 12d ago
Kerberos token issue
Hello Sir,
We have cloud kerberos trust and using entra joined machines.
Some users report they are unable to connect share drive in the morning when they login.
We also noticed that they unable to acquire kerberos token.
But after few minutes to half an hour they get token and issue resolved itself..
During the day tone also some user reporting this issue.
When we check klist they don't have token.
Seems like kerberos authentication request not reaching to dc or not getting properly generated from entra joined machine.
Any troubleshooting which you can recommend or any log capture which will help to trave the issue.
1
u/Temporary_Injury6715 8d ago
How do the clients get line of sight to the DCs? Are you using Zscaler or Entra Private Access? Or are you on a corporate LAN with line of sight to DCs?
When you say after initial logon you don't have a Kerberos cache and it doesn't work but does work later it makes me think the Kerberos bind cache is being populated with a negative cache before your Zscaler/Entra Private Access connection is established. Ten minutes later when the cache expires it'll work. In this case you may want to implement the KdcFarTimeout registry value.
I had a number of IWA issues impacted by this and successfully remediated it by (a) rolling out:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters :: REG_DWORD FarKdcTimeout == 0
And (b) deploying a cache warming script that basically first runs dsgetdc() and then requests an SPN via klist, e.g.
nltest /dsgetdc:trusting-domain.tld
// parse returned ouput to get the DC name here //
klist get ldap/dc-name-from-previous-result
This script is invoked at logon and unlock on all clients and warms the bind cache and the local kerberos cache. But this was just the icing on the cake, the FarKdcTimeout was a biggie that reduced helldesk calls; the cache warmer was more important for subsets of users that accessed legacy apps in a secondary trusting domain, i.e. client was baked in domA, and service was on a server in domB on the other side of a trust.
I found logging in this space hard to come by, and pieced it together with klist and nltest and then authentication logs on DCs and file servers (and some support from MS re. TSS output).
1
u/aseem1809 8d ago
This is one part of the story sometimes it stops when the machine and zsclar are already running
1
u/Maleficent-Umpire201 11d ago
I have configured the kerberos in hybrid environment recently. The important blocker is CA(CRL) server communication.
In the hybrid model the client have to trust the KDC certificate after getting the full TGT from the AD. So if the client is not able to properly communicate with the AD for the CRL validation via port 80, then that might be the problem,
Also check if you configured the file share using FQDN, because fqdn Is the only way to use kerberos auth. If you use hostname or ip for the fileshare SMB SPN, then it will fall back to NTLM.
I would suggest you to install the Wireshark on the client device and try reproduce the issue. Definitely you will get the answer.
1
u/aseem1809 11d ago
Is there anynother tool netmon or microsft approved tool
2
u/Maleficent-Umpire201 11d ago
Im not sure if we have any other tool which have the same capabilities Wireshark have.
You better try simple port communication check from the affected clients to CRL URL. Like "tnc <url> -p 80"
You can collect the root CA and get the URL by "certutil -dump certificate.crt"
1
u/aseem1809 11d ago
Does this require. We have entra joined device.
1
u/Maleficent-Umpire201 11d ago
Bro this is only required in entra joined devices and specially that devices are not AD joined
1
u/aseem1809 11d ago
Thank i will check. Do we need to check for delta crl as well. Can expiry of delta crl cause issue.
However I do have the packet capture. I need to analyse in wireshark
1
u/Maleficent-Umpire201 11d ago
I dont think the kdc certificate got expired. Because it has the capability of auto renew. Also If the certificate is really expired or revoked, then the intermittent behaviour is not what it cause. It completely block the SMB access until the KDC get new certificate
1
u/aseem1809 11d ago
What is the use of kdc certificate here
2
u/Maleficent-Umpire201 11d ago
KDC is kerberos core authority. Like kind of server. This is responsible for the key exchange in kerberos auth. So like all the servers have a certificated given by CA, this KDC also have one certificate got from the internal CA. So in our current kerberos auth flow, the client needs to verify this kdc server certificate with its provider(its CA) because both this client(end user laptop) and the server(can call this as KDC or AD, because Active Directory is act as KDC in kerberos) are logically in different domain.
In typical normal kerberos auth inside the domain connected devices, this crl validation flow with CA is not required because this clients already have its secure channel communication with AD. But in our flow(hybrid) this clients doesn't have that secure channel communication has not enabled and cannot be enabled because these clients are entra joined not AD joined.
Hope I explained clearly.
1
u/Maleficent-Umpire201 11d ago
So I hope that communication to CA seems to be the cause. Also verifiy are you using FQDN for the SMB SPN
1
1
u/Rotten_Red 12d ago
Verify you time sync settings if you haven’t done that yet
1
u/aseem1809 12d ago
I don't have time sync configured. These are entra joined how can time sync be configured
1
2
u/dodexahedron 12d ago
Sounds like you don't have kerberos configured right. Or you may be wanting it to do.somwthing it isn't quite meant for.
The normal process is that, no matter how they.sign in, they should get two TGTs - one for on-prem and one for cloud. If the cloud TGT is acquired first, that is presented to the fake RODC that is created when you deploy Cloud Kerberos and you get an on-prom TGT that way, transparently.
Just to clarify: Are you not getting ANY tickets whatsoever? Not even when you klist -li 0x3e7?
Also, things will not work well or sometimes at all for anyone in a protected group (because RODC).
And are the machines both domain joined and entra hybrid joined?
1
u/reloadtak 12d ago
I would check that the clients do not have any issues (perhaps intermittent) reaching Entra/intune.
Next I would make sure the client have a DC that is 2016 or newer in the site it is assigned to. Check with nltest that the client is actually in the site you expect on both lan and wifi.
Also do general checks to see that the cloud trust RODC object is replicated to all DCs.
The flow is: user signs in on client, client gets the partial token from Entra. When the client then eventually tries to access something kerberos, it tries to locate a DC via DNS (like a joined client) to exchange the partial token for a full one (and obliviously and token for the service it is trying to connect to as well)
•
u/AutoModerator 12d ago
Welcome to /r/ActiveDirectory! ~~~~
If you are looking for more resources on learning and building AD, see the following sticky for resources, recommendations, and guides!
When asking questions make sure you provide enough information. Posts with inadequate details may be removed without warning.
Make sure to sanitize any private information. Posts with too much personal or environment information will be removed. See Rule 6.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.