Today I am confronted with an interesting situation. A Kerberos protected website partially stopped working the way it was. I am asked to enter my Kerberos credentials manually. (If I do the site works as expected.)
The interesting thing about this issue is that this only happens if I try to access that particular website from a linux client. If I access the same site from a Windows client Kerberos auth is done automatically.
The second interesting thing is that another website configured exactly the same way does work without any issues. (Yes I do use the same user on Windows and Linux and I do have a valid TGT.)
What could possibly be the problem? Where should I take a closer look?
Cheers, Ronald
It looks like as if the browser is not aware of existing Kerberos credentials in /tmp/krb5cc_1000 in that specific case? But why does it work when accessing another website configured exactly the same way?
The browser behaviour could be verified with curl:
curl -s --negotiate -u : https://servicea.linux.mydomain.at does not work whereas curl -s --negotiate -u : https://serviceb.linux.mydomain.at works
Some minutes ago and without changing anything servicea started working again on my Linux client whereas the problem persists on the Linux client of a colleague.
On Tue, 2020-01-14 at 15:59 +0100, Ronald Wimmer via FreeIPA-users wrote:
Some minutes ago and without changing anything servicea started working again on my Linux client whereas the problem persists on the Linux client of a colleague.
There isn't much to go on here, however I would look in two directions initially. Check whether your client or the server are experiencing any clock skew. The max clock skew is 5 minutes, so if the clocks of the two systems difference is close to 5 minutes, small variations in communication time may affect access. The other thing may be related to DNS/discovery issues, esp for people roaming in and out of their "home" network, esp if the service in question use a DNS name (and therefore SPN) that is not part of the same AD Domain Name subdomain. to debug what is going on you could restart your browser from a terminal by first setting the KRB5_TRACE envrionment variable like so: $ KRB5_TRACE=/tmp/krb5.trace.log firefox
Or similar (not, for Firefox, if you call this cmdline while the browser is already open, the env var will not be set as firefox will ask the existing process to open a new window and then will exit).
Once you have a trace you can see if there were any specific errors in trying to get a ticket for the target server that give you a better clue.
HTH, Simo.
After reading the KRB5_TRACE logs I have a strong suspicion. The servers DNS entry is an A record on a loadbalancer IP address. This IP address does also have other (completely different) A records. And the krb log looks like as if these A records get mixed up in some cases.
Does this make sense to you?
Cheers, Ronald
freeipa-users@lists.fedorahosted.org