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

[Tim Mooney]

In regard to: Re: CentOS attempting to set up Kerberos 5-tickets created & ...:

> I have now verified that I have connections working between the two
> test machines.  Unfortunately it appears that I can only connect from
> my server/kdc to the client machine utilizing kerberized services.
>
> SERVER:
> KVNO Principal
> -----------------------------------------
>   3 host/myclient.mydomain.com at MYDOMAIN.COM
>   3 host/myclient.mydomain.com at MYDOMAIN.COM
>   3 host/myclient.mydomain.com at MYDOMAIN.COM
>   3 host/myclient.mydomain.com at MYDOMAIN.COM
>
> CLIENT:
> KVNO Principal
> -----------------------------------------
>   8 host/myclient.mydomain.com at MYDOMAIN.COM
>   8 host/myclient.mydomain.com at MYDOMAIN.COM
>   8 host/myclient.mydomain.com at MYDOMAIN.COM
>   8 host/myclient.mydomain.com at MYDOMAIN.COM
>   4 host/myserver at mydomain.com@MYDOMAIN.COM
>   4 host/myserver at mydomain.com@MYDOMAIN.COM
>   4 host/myserver at mydomain.com@MYDOMAIN.COM
>   4 host/myserver at mydomain.com@MYDOMAIN.COM

You have several problems here.  Working in generalities, as you have
been, also hasn't made this issue any more straightforward to explain.

- the keytabs should only hold entries for the name(s) by which *that
   particular system* is known.

   Your kdc should NOT have an /etc/krb5.keytab with entries for any of
   your clients.  The kdc should only have entries in its keytab for
   any of its names.

   Likewise, each of your clients should only have entries for the name(s)
   by which that particular client is known.  They absolutely should NOT
   have the KDC's host/ entries in their /etc/krb5.keytab.

- Each time you extract a principal to a keytab (with ktadd), the key
   version number (kvno) is incremented.  That essentially invalidates
   the previous key version number.

   The current key version number can be seen by looking up the entry in
   the KDC.  It has to match what's in your keytab, or the keytab won't
   work.


So, you need to:

- delete all the host/myclient.mydomain.com entries from your server's
   keytab.  You might as well just rm the KDC's keytab and start over.

- delete all the host/myserver at mydomain.com entries in your client keytab,
   leaving just the kvno 8 host/myclient.mydomain.com entries in that
   keytab.  You do keytab manipulation with ktutil.  It has an odd
   interface.  You'll probably want to do something like

 	sudo /usr/kerberos/sbin/ktutil
 	# within ktutil, you do this

 	read_kt /etc/krb5.keytab
 	delent 5
 	delent 5
 	delent 5
 	delent 5
 	list
 	write_kt /etc/krb5.keytab
 	quit

- Your server's host principal looks wrong to me.  If the server's DNS
   name is myserver.mydomain.com and your only krb5 realm is MYDOMAIN.COM,
   then its host principal should be host/myserver.mydomain.com at MYDOMAIN.COM
   The host/myserver at mydomain.com@MYDOMAIN.COM is likely incorrect.

   Once you've created host/myserver.mydomain.com in the MYDOMAIN.COM
   realm (using kadmin), use getprinc on that entry, and note the kvno.
   It will likely be 1.  Note also how many keys there are for it (my
   guess is there will be four).

- On the kdc itself, extract that principal to the keytab, using the
   ktadd command within kadmin.  After you've extracted the keys to the
   keytab, use getprinc again on that principal, and note the kvno.  It
   should have incremented by one.

- Examine the keytab with ktutil.  It should have only entries for

 	host/myserver.mydomain.com at MYDOMAIN.COM

   and the kvno should match the kvno that you found with getprinc.

Once the keytab is correct on the KDC, the services that you've set up
on the KDC (krb5-telnet, eklogin, etc.) should now work.

Tim
-- 
Tim Mooney                              mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164