[36577] in Kerberos
Re: Help interpreting wireshark traces
daemon@ATHENA.MIT.EDU (Lars Hanke)
Sat Oct 25 19:00:12 2014
Message-ID: <544C2B62.60109@lhanke.de>
Date: Sun, 26 Oct 2014 00:59:46 +0200
From: Lars Hanke <debian@lhanke.de>
MIME-Version: 1.0
To: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <3A85C0A2-8ADB-463D-AC59-EAE3E746583D@openfortress.nl>
Cc: kerberos@mit.edu
Reply-To: debian@lhanke.de
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hi Rick,
> Disclaiming any experience with AD; but this sounds like the domain join
> might have replaced the keytab that held the old service ticket, or perhaps
> it is now unreachable because AD has renamed the realm.
Well, sometimes strange things happen, but I can do exactly the same
(intended) access using a ldapsearch, which essentially draws on the
same SASL library. So I suspect that python-ldap is doing something else
- but I have no idea what.
Messing up the default keytabs would also silence my speakers
immediately, since the music is served by kerberized NFS4.
> SASL traces should be visible, at least if you’re not running inside TLS, which
> is not necessary for GSS-API (but it is for data privacy since SASL apps usually
> don’t use the C_Wrap() facilities).
My SASL GSSAPI even prohibits running TLS for some reason.
And, yes I see SASL bind requests and a success response. I just don't
know which principal was used. Since if it was the one I thought it
should be, the query should succeed.
My question was about extracting the principal used for authentication
from the SASL trace. This hopefully is not AD specific.
Thanks,
- lars.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
