kadmin problem

[Marcus Watts]

various wrote:
...
> Ken Hornstein <kenh at 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 at DOGS.UMICH.EDU
	Authenticating as principal mdw at DOGS.UMICH.EDU with password.
	Password for mdw at 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 at DOGS.UMICH.EDU for kadmin/fear.ifs.umich.edu at 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 at DOGS.UMICH.EDU for kadmin/admin at DOGS.UMICH.EDU
nothing in kadmin's log.

2nd run.
	spam% /usr/sbin/kadmin -p mdw at DOGS.UMICH.EDU -r DOGS.UMICH.EDU
	Authenticating as principal mdw at DOGS.UMICH.EDU with password.
	Password for mdw at 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 at DOGS.UMICH.EDU for kadmin/strawdogs.ifs.umich.edu at 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 at DOGS.UMICH.EDU for kadmin/admin at DOGS.UMICH.EDU

and this time a message in kadmin's log:
	Feb 14 02:25:12 Request: kadm5_init, mdw at DOGS.UMICH.EDU, success, client=mdw at DOGS.UMICH.EDU, service=kadmin/admin at 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