> Date: Tue, 08 Jun 2010 13:20:17 +0530
> To: kerberos@MIT.EDU
> From: Rahul Amaram <ra...@synovel.com>
> Subject: Re: Getting two service principals, one of them with an empty realm
>
> Hi,
> I did not get any response for this query. If nobody has an idea, I was
> planning to submit this a bug report. Looking forward to a response.
>
> Thanks,
> Rahul.
>
> On Wednesday 02 June 2010 11:59 AM, Rahul Amaram wrote:
> > Hi,
> > I am strangely getting two service principals for every service I use
> > and one of them has an empty realm. Below is a sample output.
> >
> > $ klist
> > Ticket cache: FILE:/tmp/krb5cc_1001_Xc3DVv
> > Default principal: xxx...@synovel.com
> >
> > Valid starting Expires Service principal
> > 06/02/10 11:45:07 06/02/10 21:45:07 krbtgt/synovel....@synovel.com
> > renew until 06/03/10 11:44:57
> > 06/02/10 11:45:27 06/02/10 21:45:07 imap/scs.synovel.com@
> > renew until 06/03/10 11:44:57
> > 06/02/10 11:45:27 06/02/10 21:45:07 imap/scs.synovel....@synovel.com
> > renew until 06/03/10 11:44:57
> >
> >
> > Kerberos 4 ticket cache: /tmp/tkt1001
> > klist: You have no tickets cached
> >
> >
> > The hostname to realm mapping and realm kdc details are obtained
> > completely through DNS (using TXT and SRV records).
> >
> > Any help in this regard would be appreciated.
> >
> >
> > Regards,
> > Rahul.
> > ________________________________________________
> > 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
Ok. I have some suggestions, but I was really hoping somebody else could
give you a better answer. Here's how I would go about investigating this,
/1/ collect together all relevant krb5.conf and dns information. That is,
*everything* your client sees should be in one concise report.
So, contents of krb5.conf
dns SRV records for {_kerberos,_kerberos-master}.{_tcp,_udp}.SYNOVEL.COM
/2/ verify this happens with "kvno" too, not just applications.
You report "every service"--what's important here is
the library that application is calling. Since "kvno" does no
application stuff whatsoever, it's the purest way to reproduce this problem.
/3/ do one, or better yet, both of the following:
strace (or truss, or ktrace, or ... depending on your OS).
tcpdump (or snoop, or ...)
For tcpdump, use -tt -p -s 2000 -X -v
do this for both kinit and kvno.
Look at:
/a/ what krb5.conf(s) did it *really* open?
Most libraries will try several places.
/b/ k5 traffic. What kdcs did it try to talk to?
What did it get back?
/c/ DNS traffic - what did it really try to lookup?
The k5 stuff is wire encoded as ASN.1. It is possible to decode
this using some perl glop and "openssl asn1parse".
See ``/afs/umich.edu/user/m/d/mdw/bin/tcp2pem.pl'' for an out-dated
and badly documented example of how to do this. (you might have to use
tcpdump -x not -X if you use this script without changes.)
/4/ Now look at the logs on each kdc it talked to. What's recorded there?
The entry with an '@' and no domain looks like a weird referal record.
Points to consider:
is windows involved here?
do you have "domain_realm" records in krb5.conf?
is there something consistently weird about the service host
to realm mapping?
/4a/ kdb and kdc data
does the service principal with no realm actually exist in your kdb?
What's in krb5.conf and kdc.conf on the kdc?
/5/ experiment with crafting a krb5.conf file with "dns_fallback" false,
and seeing if varying the contents can reproduce the behavior,
or suppress the behavior. Both cases are of interest.
/6/ At this point, if the answer is not somehow obvious to me,
I'd be resorting to "gdb" on whichever part(s) were doing something
I didn't understand. I'd be hoping that something in krb5.conf
dns, tcpdump, or strace would be looking "weird" and would give me a
clue about where to look. The results of varying krb5.conf
should certainly give me a starting point: the dns logic at the very
least if I can't cause the behavior to appear.
In your case - if you are not a C programmer, well, I told you my
answer might suck.
/8/ when reporting problems, for klist, do "klist -fea".
Also consider doing:
getprinc on client principal
getprinc on service principal(s).
/9/ when reporting problems, include: exact client software version and
architecture. Ie, if an rpm, what rpm. If building from source, which
version of MIT source. Also host operating sytem version and cpu architecture.
/10/ when reporting problems, include: exact server software version and
architecture. Ie, if an rpm, what rpm. If building from source, which
version of MIT source. Also host operating sytem version and cpu architecture.
/11/ when reporting *bugs*, you should include sufficient details
that somebody else can reproduce your problem.
/12/ when reporting problems you don't understand or reproduce,
you have a problem: in order for anybody else to understand what's
going on, you'll have to include log contents, trace output, etc.
Care is required here! You have secrets! You must decide what
you are willing to share.
What is safe to reveal: network traffic. most log output. command output
and prompts. command input that is echoed.
What is mostly safe: expired tickets and session keys.
What is less safe: most passwords. unexpired tickets and session keys.
encrypted kdb contents.
What is not safe: admin passwords. service keys. master key.
unencrypted contents of kdb.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
