Hi all, i've seem to come across some unexplainable behaviour (at least for me).
Situation sketch: Linux Slackware KRB server A: MIT Kerberos 1.8.2 KDC/Kadmind Linux Slackware HTTP server A: Apache 2.2.9 + mod_auth_kerb Linux Slackware SSH server A: Openssh 5.3p1 + openssh-5.3p1-gsskex-all-20100124.patch Linux Slackware client A: MIT Kerberos 1.8.2 Client libraries/software MAC OS X Snow Leopard client A: MIT Kerberos Libraries Windows XP client A: Firefox browser / Putty development snapshot 2010-07-05:r8971 / KFW 3.2.2 + NiM 1.3.1 Now, from what i've understood, a usual KRB(5) transaction (soemwhat) goes as follows: (Assuming 'MAC OS X Snow Leopard client A' makes a SSH connection to 'Linux Slackware SSH Server A') MAC OS X Snow Leopard client A$ AS_REQ to KRB5KDC requesting krbtgt/re...@realm Linux Slackware KRB server A$ Requests PREAUTH MAC OS X Snow Leopard client A$ AS_REQ to KRB5KDC requesting krbtgt/re...@realm <-- After PREAUTH Linux Slackware KRB server A$ Issues krbtgt/re...@realm to 'MAC OS X Snow Leopard client A' MAC OS X Snow Leopard client A$ TGS_REQ to KRB5KDC requesting host/f...@realm Linux Slackware KRB server A$ Issues host/f...@realm ticket to 'MAC OS X Snow Leopard client A' Focussing on the TGS_REQ specifically for the krbtgt/re...@realm we can conclude the following: A normal KRB(5) transaction will generate: - 1 TGS_REQ for krbtgt/re...@realm - 1 TGS_REQ for host/f...@realm Within the limits of the ticket expiration window these TGS_REQ should generate a local credentials cache sufficient to reconnect from 'MAC OS X Snow Leopard client A' to 'Linux Slackware SSH server A' without another TGS_REQ for krbtgt/re...@realm or a TGS_REQ for host/f...@realm. Meaning that during ticket validity only 1 TGS_REQ for both krbtgt/re...@realm and host/f...@realm is made, despite of amount of SSH connections requested. This very basic KRB ticket issuance process sketch is true in reality. During my tests, when connecting with the local SSH client from 'MAC OS X Snow Leopard client A' to 'Linux Slackware SSH server A' this is exactly what happens. Now for the possible 'misbehaviour' Repeating the same actions (making an SSH connection from kerberized SSH client to kerberized SSH server) from 'Linux Slackware client A' to 'Linux Slackware SSH server A' generates a TGS_REQ for krbtgt/re...@realm every time a new SSH connection is initiated to 'Linux Slackware SSH server A'. The same goes for SSH Putty connections from 'Windows XP client A' to 'Linux Slackware SSH server A'. Every new SSH connection generates another TGS_REQ for krbtgt/re...@realm. Can anybody explain me this behaviour ? Is it expected ? I myself would not expect another TGS_REQ for krbtgt/re...@realm every time a SSH connection is initiated, because it can use the local credentials cache for the krbtgt/re...@realm ticket. Also, the behaviour from 'MAC OS X Snow Leopard client A' is as expected (described above), which could indicate that the "issue/misconfiguration" would be on the client side, and not on the server side. Now, to mix yet another chain in this picture. When initiating a HTTPS session with Safari as well as Firefox from 'MAC OS X Snow Leopard client A' to 'Linux Slackware HTTP server A', i see a expected KRB ticket issuance conversation. Per HTTPS virtual host 1 TGS_REQ for HTTP/f...@realm and 1 TGS_REQ for krbtgt/re...@realm regardless of amount of HTTPS TCP connections. On the other hand, when initiating a HTTPS session with Firefox from 'Windows XP client A' to 'Linux Slackware HTTP server A' a TGS_REQ for krbtgt/re...@realm is processed for every single HTTPS TCP connection made. Imagine opening a website containing 100 pictures. This would mean 100 TGS_REQ for krbtgt/re...@realm. The strangest behaviour i've seen so far must be that when i close NetidMgr 1.3.1, -after-, receiving a ticket for HTTP/f...@realm and krbtgt/re...@realm, the excessive TGS_REQ's are not showing in the MIT Kerberos logs anymore. Would anyone be so kind to elaborate on this behaviour or point out that this is a bug/misconfiguration ? The frustration here is that the 'MAC OS X Snow Leopard client A' seems to be doing it all right whereas the other clients don't. The most annoying about all this must be the thousands of TGS_REQ (krbtgt/re...@realm) log entries for every single HTTPS connection... On a final note i would like to share some configuration files: Linux Slackware KRB server A: kdc.conf -> http://pastebin.com/ETd6MKya krb5.conf -> http://pastebin.com/uaKAsikf Linux Slackware HTTP server A: krb5.conf -> http://pastebin.com/uaKAsikf https-syslog.svh.domain.tld.vhost -> http://pastebin.com/fHy0F7wj (Apache HTTPD virtual host configuration) Linux Slackware SSH server A: krb5.conf -> http://pastebin.com/tc50XqKj sshd_config -> http://pastebin.com/s6JqZgiY ssh_config -> http://pastebin.com/wm3TvJ3V Linux Slackware client A: krb5.conf -> http://pastebin.com/tc50XqKj ssh_config -> http://pastebin.com/wm3TvJ3V MAC OS X Snow Leopard client A: /Library/Preferences/edu.mit.Kerberos -> http://pastebin.com/T1srBwaa /etc/ssh_config -> http://pastebin.com/JVg3itrd Windows XP client A: C:\windows\krb5.ini -> http://pastebin.com/w9FtmEVH All the best, Pavlovski ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
