I'm a newbie and had a similar issue, in order to find out the right
principal for a service, I executed Wireshark on client or server node in a
test env... Wireshark kerberos dissector works quite well and tuo can see
details of requests, principals too. Perhaps this ke obvious but.. Not for
me :-(
Il 13 gen 2018 17:46, "Greg Hudson" <ghud...@mit.edu> ha scritto:
> 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
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
