Kadmin GSS-API Error
Marcus Watts
mdw at umich.edu
Fri Sep 17 17:31:55 EDT 2004
Lynn Zhang <lyzhang at umich.edu> writes:
> Date: Fri, 17 Sep 2004 16:32:52 -0400 (EDT)
> From: Lynn Zhang <lyzhang at umich.edu>
> To: Tom Yu <tlyu at mit.edu>
> In-Reply-To: <ldvbrg491ks.fsf at cathode-dark-space.mit.edu>
> Message-ID: <Pine.SOL.4.58.0409171453040.12317 at hypatia.lsait.lsa.umich.edu>
> References: <Pine.SOL.4.58.0409170748430.14347 at hypatia.lsait.lsa.umich.edu>
> <Pine.SOL.4.58.0409171039120.29760 at hypatia.lsait.lsa.umich.edu>
> <ldvbrg491ks.fsf at cathode-dark-space.mit.edu>
> MIME-Version: 1.0
> cc: kerberos at mit.edu
> Subject: Re: Kadmin GSS-API Error
>
> On Fri, 17 Sep 2004, Tom Yu wrote:
>
> > >>>>> "lyzhang" == Lynn Zhang <lyzhang at umich.edu> writes:
>
> >
> > lyzhang> Should the kadmin form 1.3.4 talks to kadmind from 1.2.8? Or
> > lyzhang> I may ignore the error, just upgrade the KDC first, then the
> > lyzhang> client, so the kadmin client and server will be the same
> > lyzhang> version.
> >
> > The kadmin client from 1.3.4 should be able to talk to the kadmind
> > from 1.2.8. If it can't, it could be a bug.
> >
> > ---Tom
> >
>
> That's what I hope. Because from the same machine, I could use
> kadmin (which is from 1.2.8, and it is same version as the KDC) to
> contact the same KDC without a problem. The client and the KDC 's environment
> are not changed, except the kadmin's version is different.
>
>
> I would like to get more useful error msgs, maybe in the future I could do
> thing like "kadmind -D" or "kadmin -D"
> The next is the out put of the snoop command, hope you could find some
> hints from it.
>
> Using device /dev/eri (non promiscuous)
>
> hyp is the client machine, fly is the KDC.
>
> Thanks so much,
> Lynn
>
> The next will get the "GSS-API (or Kerberos) error while initializing
> kadmin interface"
>
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu TCP D=749 S=32876 Syn
> Seq=3893305037 Len=0 Win=32850 Options=<nop,wscale 1,nop,nop,tstamp 63001
> 0,nop,nop,sackOK,mss 1460>
> fleming.lsa.umich.edu -> hypatia.lsait.lsa.umich.edu TCP D=32876 S=749 Syn
> Ack=3893305038 Seq=1319902512 Len=0 Win=33304 Options=<nop,nop,tstamp
> 694866642 63001,nop,wscale 1,nop,nop,sackOK,mss 1460>
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu TCP D=749 S=32876
> Ack=1319902513 Seq=3893305038 Len=0 Win=33304 Options=<nop,nop,tstamp
> 63001 694866642>
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu RPC C XID=1095061077
> PROG=2112 (?) VERS=2 PROC=1
> fleming.lsa.umich.edu -> hypatia.lsait.lsa.umich.edu TCP D=32876 S=749
> Ack=3893305594 Seq=1319902513 Len=0 Win=33304 Options=<nop,nop,tstamp
> 694866647 63006>
> fleming.lsa.umich.edu -> hypatia.lsait.lsa.umich.edu RPC R (#11)
> XID=1095061077 Success
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu TCP D=749 S=32876
> Ack=1319902733 Seq=3893305594 Len=0 Win=33304 Options=<nop,nop,tstamp
> 63008 694866649>
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu RPC C XID=1095061076
> PROG=2112 (?) VERS=2 PROC=13
> fleming.lsa.umich.edu -> hypatia.lsait.lsa.umich.edu RPC R (#15)
> XID=1095061076
> hypatia.lsait.lsa.umich.edu -> fleming.lsa.umich.edu TCP D=749 S=32876
> Ack=1319902885 Seq=3893305778 Len=0 Win=33304 Options=<nop,nop,tstamp
> 63019 694866649>
>
>
> This is connecting OK
>
> hyp.language.umich.edu -> fly.language.umich.edu TCP D=749 S=32876 Syn
> Seq=3893305037 Len=0 Win=32850 Options=<nop,wscale 1
> ,nop,nop,tstamp 63001 0,nop,nop,sackOK,mss 1460>
> fly.language.umich.edu -> hyp.language.umich.edu TCP D=32876 S=749 Syn
> Ack=3893305038 Seq=1319902512 Len=0 Win=33304 Option
> s=<nop,nop,tstamp 694866642 63001,nop,wscale 1,nop,nop,sackOK,mss 1460>
> hyp.language.umich.edu -> fly.language.umich.edu TCP D=749 S=32876
> Ack=1319902513 Seq=3893305038 Len=0 Win=33304 Option
> s=<nop,nop,tstamp 63001 694866642>
> hyp.language.umich.edu -> fly.language.umich.edu RPC C XID=1095061077
> PROG=2112 (?) VERS=2 PROC=1
> fly.language.umich.edu -> hyp.language.umich.edu TCP D=32876 S=749
> Ack=3893305594 Seq=1319902513 Len=0 Win=33304 Option
> s=<nop,nop,tstamp 694866647 63006>
> fly.language.umich.edu -> hyp.language.umich.edu RPC R (#11)
> XID=1095061077 Success
> hyp.language.umich.edu -> fly.language.umich.edu TCP D=749 S=32876
> Ack=1319902733 Seq=3893305594 Len=0 Win=33304 Option
> s=<nop,nop,tstamp 63008 694866649>
> hyp.language.umich.edu -> fly.language.umich.edu RPC C XID=1095061076
> PROG=2112 (?) VERS=2 PROC=13
> fly.language.umich.edu -> hyp.language.umich.edu RPC R (#15)
> XID=1095061076
> hyp.language.umich.edu -> fly.language.umich.edu TCP D=749 S=32876
> Ack=1319902885 Seq=3893305778 Len=0 Win=33304 Option
> s=<nop,nop,tstamp 63019 694866649>
>
>
>
>
> *=======================================*
> * Lynn Zhang *
> * LS&A System Services Team *
> * lyzhang at umich.edu *
> *=======================================*
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Debugging kadm5 GSS-API errors is possible, but tricky.
It is possible to trace problems from snoop output, but
probably not with the level of detail you have. You might try this:
snoop -P -v -r -x 0
(perhaps with -V or omitting -v). Much of the content is encrypted.
You'll need to know the service keys for all principals used to decrypt
it. You'll also have to capture the companion conversation between
kadmin & krb5kdc to get the ticket data with the service keys, and then
the fun starts. You'll have to dig through the k5 source to figure out
key usage, encryption algorithms, and other information to decrypt
everything. If you're lucky, the kdc traffic itself will show you the
problem. You can use openssl's asn1parse command to decode the asn.1
in the ticket exchange proper, which will save you a bit of work.
Basically, very doable, but a LOT of work.
Another good resource is the kdc logs themselves. That will include
a record of the encryption types issued, which may be of interest,
especially if you can compare "1.2.8 client <-> 1.2.8 server"
and "1.2.8 client <-> 1.3.4 server". kadmind also keeps a log,
which may have interesting complaints.
If the easy things fail, I generally try these 3 things:
#0 experiment with kinit, krb5.conf, etc., -- when
these problems are configuration issues dealing with
key types, *sometimes* zen works on it.
#1 build a copy of the kadmin & libraries that
have debugging code enabled. For instance,
in
krb5/src/lib/rpcauth_gssapi_misc.c
defining DEBUG_GSSAPI to 1 or 0 produces a binary
that always or or by asking the debugger to set
misc_debug_gssapi will sometimes
dump more useful information.
#2 use a debugger such as adb, dbx, gdb, ...
Besides setting misc_debug_gssapi it's also possible
to put breakpoints in lots of more interesting places.
I often find problems in
krb5/src/lib/gssapi/krb5/{k5seal.c,k5unseal.c}
but that's because I've asked for it big time - I've put
experimental encryption support there for the fun of fixing
it. You might find the routines in
krb5/src/lib/gssapi/krb5/init_sec_context.c
krb5/src/lib/gssapi/krb5/gssapi_krb5.c
krb5/src/lib/gssapi/krb5/acquire_cred.c
to be of more interest; that appears to be where
most of the k5 glue lives.
gssapi errors have a "major" and a "minor" error field;
once you find where you're failing and get this number, you can start looking
through the code to see where those numbers are produced. There's
some sort of complicated masking algorithm that goes on,
part of which is contained in
krb5/src/lib/gssapi/generic/gssapi.hin
if it's a k5 error, though, you'll need to dig down to a deeper layer.
-Marcus Watts
UM ITCS Umich Systems Group
More information about the Kerberos
mailing list