Problems with kpropd
Mike Dopheide
dopheide at ncsa.uiuc.edu
Tue Aug 15 15:29:44 EDT 2006
I'm stumped.
I still think there's something inconsistent with the hostname,
/etc/hosts, and/or DNS, but I'm not sure what else to suggest.
-Mike
> Mike Dopheide wrote:
>>
>> Hhmm.. okay. First of all, you don't want to have the same keys in
>> krb5.keytab on both systems. A system should really only have keys for
>> itself and any services it provides (like host/hostname, ftp/hostname,
>> etc).
>
> Ah, right, OK. Misapprehension there on my part; I'm still getting to grips
> with Kerberos.
>
> I've now managed to fix the initial identity/key problems, by appropriate
> removing/recreating of principals so I now have
>
> host/elysium.ph.ic.ac.uk in the master keytab,
> host/rapanui.ph.ic.ac.uk in the slave keytab
> & both with KVNO that match the database.
>
> The issue I'm now having is this error in the slave logs:
>
> kpropd: Incorrect net address while decoding database size from client
>
> I was hoping that this was related to the identity issue below, but I've now
> resolved that, so it seems not (unless it's another subtle difference? e.g.
> the ticket having a 127.0.0.1 address? Might that happen?). The only
> reference I can find in the list archives is to a multihoming issue, which
> doesn't apply here.
>
> [ Solution to identity problem is below, for reference ]
>
> Thanks very much for all the help given so far! Thoughts on the latest
> stalling point welcome.
>
>
> Regards,
> Juliet
>
>
>> But first you need to fix the identity crisis your server is having.
>
> hostname was returning correct; and /etc/hosts had:
>
> 155.198.204.57 elysium.ph.ic.ac.uk elysium
> 127.0.0.1 localhost.localdomain localhost elysium
>
> Googling revealed some discussion on the Debian lists about this (the
> standard Debian ordering) being the wrong order (
> http://lists.debian.org/debian-devel/2005/10/msg00387.html ), as a result of
> which I've now replaced that last line with
>
> 127.0.0.1 localhost localhost.localdomain elysium
>
> which works. host/localhost.localdomain principal has now been removed.
>
>
>>
>> The master should have it's host/master.ph.ic.ac.uk in it's
>> /etc/krb5.keytab and the slave should have host/rapanui.ph.ic.ac.uk. The
>> slave should also have a kpropd.acl with just the text
>> "host/master.ph.ic.ac.uk", not the actual key.
>>
>> Hopefully that will get you further.
>>
>> -Mike
>>
>>> Mike Dopheide wrote:
>>>>
>>>> My first guess is that the slave KDC doesn't have a host/ entry in the
>>>> principal database (and in it's krb5.keytab). Check your kerberos logs
>>>> and see if you're getting a client not found error for
>>>> host/rapanui.ph.ic.ac.uk
>>>
>>> Many thanks for this - it wasn't host/rapanui.ph.ic.ac.uk but
>>> host/localhost.localdomain (i.e. the requesting host) that was the
>>> problem.
>>>
>>> Adding this to the principal database (& extracting it to keytabs on
>>> both master & slave) fixed the immediate problem. However:
>>>
>>> a) I'd rather not have a host/localhost.localdomain principal. How
>>> should I ensure that the requesting host uses its proper name?
>>>
>>> b) I've now encountered another problem:
>>> kprop -d -r PH.IC.AC.UK -f test_kerb_slave_db rapanui.ph.ic.ac.uk
>>> gives
>>> kprop: Decrypt integrity check failed while getting initial ticket
>>>
>>> I found this thread:
>>> http://mailman.mit.edu/pipermail/kerberos/2006-July/010082.html
>>>
>>> & discovered a key number mismatch on the master. Curiously, it seems
>>> that on adding host/localhost.localdomain, its kvno was 4, but the first
>>> time I extracted it, its kvno was 3. Is this normal/correct? Anyway, I
>>> fixed that, but then got this error:
>>>
>>> kprop: Server rejected authentication (during sendauth exchange) while
>>> authenticating to server
>>> Generic remote error: Key version number for principal in key table is
>>> incorrect
>>>
>>> I tried to fix this by extracting the key to the slave keytab: after
>>> this I was back to the original error:
>>>
>>> kprop: Decrypt integrity check failed while getting initial ticket
>>>
>>> At this point, on the master, the kvno matches in keytab & main
>>> database; but it doesn't on the slave. I can't see how to fix this,
>>> since each extraction seems to +1 to the kvno.
>>>
>>> However, kinit as host/localhost.localdomain, using the relevant keytab,
>>> works on both master & slave.
>>>
>>> I'm kind of stuck at this point! Any suggestions would be much
>>> appreciated!
>>>
>>>
>>> Regards,
>>> Juliet
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> + Ms Juliet Kemp +
> + Computer Manager star at imperial.ac.uk +
> + Astrophysics Group +
> + Imperial College Tel: +44 (0)20759 47538 +
> + London. SW7 2AZ Fax: +44 (0)20759 47541 +
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
More information about the Kerberos
mailing list