My best guess is that there is a disagreement between the server
principal name passed to kinit -S ("kafka/host") and the server
principal name chosen by SASL GSSAPI. At least, that's the most obvious
way I can find to get a "Matching credential not found" error message
from MIT krb5's GSSAPI library. It's hard for me to be sure since I'm
not seeing any krb5 trace logs resulting from the SASL operation, only
from the kinit operation. (I would expect to see at least trace logs
like "Getting credentials <clientprinc> -> <serverprinc> using ccache
<ccache>" and "Retrieving <clientprinc> -> <serverprinc> from <ccache>
with result: ...")
If you can configure rdkafka to acquire a TGT from the keytab instead of
directly acquiring a service ticket (by removing "-S kafka/host" from
the kinit command line), you could verify that this is the problem and
to determine (using klist) what service ticket is acquired during
authentication.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
