[27443] in Kerberos
Re: kadmin problem
daemon@ATHENA.MIT.EDU (Marcus Watts)
Wed Feb 14 03:35:31 2007
Message-Id: <200702140835.DAA14152@quince.ifs.umich.edu>
To: scotty adams <scotty.adams@yahoo.com>
In-reply-to: Your message of "Tue, 13 Feb 2007 21:46:31 PST."
<462343.24123.qm@web55301.mail.re4.yahoo.com>
Date: Wed, 14 Feb 2007 03:35:10 -0500
From: Marcus Watts <mdw@umich.edu>
Cc: kerberos@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
various wrote:
...
> Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote: >Then what is the problem???
> >How can it be solved? i am really stuck
>
> Sigh. If nothing useful appears in kadmind or kdc logs ... well, the only
> way I know of to debug this problem is to run kadmin under the debugger
> and trace down the problem. One thing comes to mind: it looks like you
> have NAT involved somewhere. kadmin doesn't work from behind a NAT.
...
I often have good luck finding problems with gdb (or dbx on solaris).
But I would hesitate to go at that first.
Here's some cases you might find interesting:
First run.
spam% /usr/sbin/kadmin -p mdw@DOGS.UMICH.EDU
Authenticating as principal mdw@DOGS.UMICH.EDU with password.
Password for mdw@DOGS.UMICH.EDU:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface
spam%
Resulting kdc log messages:
Feb 14 02:24:54 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: SERVER_NOT_FOUND: mdw@DOGS.UMICH.EDU for kadmin/fear.ifs.umich.edu@DOGS.UMICH.EDU, Server not found in Kerberos database
Feb 14 02:24:54 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: ISSUE: authtime 1171437894, etypes {rep=18 tkt=16 ses=16}, mdw@DOGS.UMICH.EDU for kadmin/admin@DOGS.UMICH.EDU
nothing in kadmin's log.
2nd run.
spam% /usr/sbin/kadmin -p mdw@DOGS.UMICH.EDU -r DOGS.UMICH.EDU
Authenticating as principal mdw@DOGS.UMICH.EDU with password.
Password for mdw@DOGS.UMICH.EDU:
kadmin:
Resulting kdc log messages,
Feb 14 02:25:10 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: SERVER_NOT_FOUND: mdw@DOGS.UMICH.EDU for kadmin/strawdogs.ifs.umich.edu@DOGS.UMICH.EDU, Server not found in Kerberos database
Feb 14 02:25:10 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: ISSUE: authtime 1171437910, etypes {rep=18 tkt=16 ses=16}, mdw@DOGS.UMICH.EDU for kadmin/admin@DOGS.UMICH.EDU
and this time a message in kadmin's log:
Feb 14 02:25:12 Request: kadm5_init, mdw@DOGS.UMICH.EDU, success, client=mdw@DOGS.UMICH.EDU, service=kadmin/admin@DOGS.UMICH.EDU, addr=141.211.1.36, flavor=6
Kinda similar command, sorta the same log messages in kdc,
quite different results.
So things I think might be interesting:
What does /etc/krb5.conf contain on the machine where kadmin is run?
What does /etc/krb5.conf (might live elsewhere) contain on the machine
where kadmind runs?
What does /etc/krb5kdc/kdc.conf (probably lives elsewhere) contain on
the machine where kadmind runs?
If krb5.conf lacks entries, mit kerberos 5 is likely to get them
fron DNS. So what does _kerberos-adm._tcp.<REALM> map to?
What does _kerberos._udp.<REALM> map to? Maybe also interesting,
what does krb5_get_host_realm() return for your admin server?
Also would be interesting to compare forward & reverse arpa
mappings for your admin host -- anything strange there?
I found these, but I don't know if these actually relate
to what you're trying to do:
_kerberos._udp.scottie.company.com. 1h1s IN A 216.52.184.240
_kerberos_adm._tcp.scottie.company.com. 1h1s IN A 64.74.96.243
_kerberos._tcp.scottie.company.com. 3601 IN A 63.251.92.195
those sure look like wildly different IP addresses. Umm...
actually all of dns[1-5].name-services.com return different answers.
Also, these are "A" records not "SRV" records so they don't actually
matter. And what's up with ANY and those dns servers?
It looks very odd, so I hope that's nothing to do with you.
You should definitely run this with strace (well, probably truss if you're
doing this on solaris 9), and see what it tries to connect to.
On linux (strace), if I do "grep -w 749" on the strace output, the bad
kadmin shows this:
4745 connect(4, {sa_family=AF_INET, sin_port=htons(749), sin_addr=inet_addr("141.211.1.32")}, 16) = 0
141.211.1.32 = fear.ifs.umich.edu - this is the admin_server for UMICH.EDU,
so it won't have anything nice to say to a client that hands it a DOGS.UMICH.EDU
service ticket.
and the good kadmin shows this:
4762 connect(4, {sa_family=AF_INET, sin_port=htons(749), sin_addr=inet_addr("141.213.229.83")}, 16) = 0
141.213.229.83 = strawdogs.ifs.umich.edu is the admin_server for
DOGS.UMICH.EDU - so yes it should and does work.
tcpdump (or on solaris 9, snoop) can be used to capture
network traffic with overlapping diagnostic capabilities to gdb or
strace.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
