CentOS attempting to set up Kerberos 5-tickets created & destroyed successfully, now an issue

[Damo Gets]

Regarding CentOS4 server kerberos5 setup w/Ubuntu client

On Mar 19, 5:02 pm, Tim Mooney <moo... at dogbert.cc.ndsu.NoDak.edu>
wrote:

> On your client system, what you probably want to do is something like:
>
>         sudo kadmin -p username/admin
>
> (where username is whatever user account you previously created).  If
> that works, your client has enough information to connect to the kadmind
> that's running on your KDC.

Okay I've managed to get past my previous stumbling block with Ken
Raeburn's help and your own.  I'd like to state that I really
appreciate it, too.  :)

Unfortunately I've hung at this point.  Both my server and client
machines are now configured to do an /etc/hosts lookup before
attempting DNS and resolve each other perfectly.  My server machine
has the kdc running on port 88, verified in /etc/services, and
kerberos admin running on 749.  Yet when I attempt to execute kadmin
on my client machine, even specifying the server on the command line,
I'm receiving the following error:

linuxdamon:~$ kadmin -p dgets/admin -s kdc.mydomain.com
Authenticating as principal dgets/admin at MYDOMAIN.COM with password.
kadmin: Cannot contact any KDC for requested realm while initializing
kadmin interface

I have copied /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf from
the server machine to my ubuntu client.  I'm pretty sure I only needed
the kdc.conf transferred over, but I wanted to make sure that I wasn't
missing anything so I went with the overkill.

Again I'm a little lost...  I simply edited the kdc.conf that came
with the distribution replacing EXAMPLE.COM and other applicable
instances with my realm & domain or host information.  I'm looking
through the options right now but I still haven't seen anything that
seems to be applicable.  Any suggestions?

-Damon

>
> If it works, you'll be at a prompt.  From there you can do
>
>         addprinc -randkey host/your.clients.fqdn
>
> Note that the "host" is literal -- it's not to be replaced with something
> else.  It's the type of principal that many of the krb5-workstation
> daemons look for (ftpd being an exception).
>
> Once that's done, you need to extract the principal into a local keytab.
> You do that via ktadd, still within admin.  That's why I recommended
> "sudo" in front of your kadmin auth -- you'll have permission to write
> to /etc/krb5.keytab.
>
> So, still within kadmin, you type
>
>         ktadd -k /etc/krb5.keytab host/your.clients.fqdn
>
> The '-k /etc/krb5.keytab' probably isn't needed, but doesn't hurt.
>
> Once that's done, you can exit from kadmin, and your client now has what
> it needs for you to be able to run the Kerberized daemons from the
> krb5-workstation package.  You should be able to do something like
>
>         sudo chkconfig xinetd on
>         sudo chkconfig eklogin on
>         sudo service xinetd start
>
> If you kinit from somewhere else, you should then be able to do
>
>         /usr/kerberos/bin/rlogin -x your.clients.fqdn
>
> and get in without being prompted for a password.
>
> > If not that, I have a few other ideas...  Second was that the host
> > name for the ubuntu machine will not resolve from the primary KDC.
>
> That's a problem, but it's not what's causing your current issue.
> It will definitely be an issue down the road.
>
> >  To
> > get around this I added an /etc/hosts entry for my machine.
>
> That's enough, as long as nsswitch.conf on the KDC is right.