Problems with kpropd

Hi,

I have a working Kerberos master server, and am attempting to set up
replication via kpropd.

I've followed the steps in the MIT documentation, but then from this
command:

kprop -f test_kerb_slave_db rapanui.ph.ic.ac.uk

I get output:

kprop: Cannot resolve network address for KDC in requested realm while
getting initial ticket


Adding the realm, as follows:

kprop -r PH.IC.AC.UK -f test_kerb_slave_db rapanui.ph.ic.ac.uk

gives:

kprop: Client not found in Kerberos database while getting initial ticket

Adding the keytab location with -s /etc/krb5.keytab doesn't help (same
error about 'Client not found...').


Any suggestions as to what might be wrong or how I can get more
information? I'm running version 1.4.3-8 on Debian stable (sparc version)


Many thanks,

Juliet

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Ms Juliet Kemp +
+ Computer Manager [email]star@imperial.ac.uk[/email] +
+ Astrophysics Group +
+ Imperial College Tel: +44 (0)20759 47538 +
+ London. SW7 2AZ Fax: +44 (0)20759 47541 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

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

Other common propagation problems come from missing entries in kpropd.acl,
the kpropd service not running on the slave, or the port being blocked
with TCPwrappers or iptables

-Mike
[color=blue]
> Hi,
>
> I have a working Kerberos master server, and am attempting to set up
> replication via kpropd.
>
> I've followed the steps in the MIT documentation, but then from this
> command:
>
> kprop -f test_kerb_slave_db rapanui.ph.ic.ac.uk
>
> I get output:
>
> kprop: Cannot resolve network address for KDC in requested realm while
> getting initial ticket
>
>
> Adding the realm, as follows:
>
> kprop -r PH.IC.AC.UK -f test_kerb_slave_db rapanui.ph.ic.ac.uk
>
> gives:
>
> kprop: Client not found in Kerberos database while getting initial ticket
>
> Adding the keytab location with -s /etc/krb5.keytab doesn't help (same
> error about 'Client not found...').
>
>
> Any suggestions as to what might be wrong or how I can get more
> information? I'm running version 1.4.3-8 on Debian stable (sparc version)
>
>
> Many thanks,
>
> Juliet
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> + Ms Juliet Kemp +
> + Computer Manager [email]star@imperial.ac.uk[/email] +
> + Astrophysics Group +
> + Imperial College Tel: +44 (0)20759 47538 +
> + London. SW7 2AZ Fax: +44 (0)20759 47541 +
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ________________________________________________
> Kerberos mailing list [email]Kerberos@mit.edu[/email]
> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>[/color]
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

Mike Dopheide wrote:[color=blue]
>
> 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[/color]

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:
[url]http://mailman.mit.edu/pipermail/kerberos/2006-July/010082.html[/url]

& 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 [email]star@imperial.ac.uk[/email] +
+ Astrophysics Group +
+ Imperial College Tel: +44 (0)20759 47538 +
+ London. SW7 2AZ Fax: +44 (0)20759 47541 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

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).

So that's probably why you're seeing the key version number problem.
Every time you run ktadd it's going to randomize the key before writing it
out to the file.

But first you need to fix the identity crisis your server is having. I'm
guessing it doesn't have it's hostname set so it's defaulting to
localhost. What does 'hostname' return? Your systems should think of
themselves with a real hostnames and have those entries in /etc/hosts with
the fqdn listed first. ie, for your slave:

155.198.204.170 rapanui.ph.ic.ac.uk rapanui

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
[color=blue]
> Mike Dopheide wrote:[color=green]
>>
>> 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[/color]
>
> 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:
> [url]http://mailman.mit.edu/pipermail/kerberos/2006-July/010082.html[/url]
>
> & 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 [email]star@imperial.ac.uk[/email] +
> + Astrophysics Group +
> + Imperial College Tel: +44 (0)20759 47538 +
> + London. SW7 2AZ Fax: +44 (0)20759 47541 +
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ________________________________________________
> Kerberos mailing list [email]Kerberos@mit.edu[/email]
> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>[/color]
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

Mike Dopheide wrote:[color=blue]
>
> 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).[/color]

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

[color=blue]
> But first you need to fix the identity crisis your server is having.[/color]

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 (
[url]http://lists.debian.org/debian-devel/2005/10/msg00387.html[/url] ), 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.

[color=blue]
>
> 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
>[color=green]
>> Mike Dopheide wrote:[color=darkred]
>>>
>>> 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[/color]
>>
>> 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:
>> [url]http://mailman.mit.edu/pipermail/kerberos/2006-July/010082.html[/url]
>>
>> & 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[/color][/color]

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Ms Juliet Kemp +
+ Computer Manager [email]star@imperial.ac.uk[/email] +
+ Astrophysics Group +
+ Imperial College Tel: +44 (0)20759 47538 +
+ London. SW7 2AZ Fax: +44 (0)20759 47541 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

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
[color=blue]
> Mike Dopheide wrote:[color=green]
>>
>> 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).[/color]
>
> 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
>
>[color=green]
>> But first you need to fix the identity crisis your server is having.[/color]
>
> 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 (
> [url]http://lists.debian.org/debian-devel/2005/10/msg00387.html[/url] ), 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.
>
>[color=green]
>>
>> 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
>>[color=darkred]
>>> 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:
>>> [url]http://mailman.mit.edu/pipermail/kerberos/2006-July/010082.html[/url]
>>>
>>> & 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[/color][/color]
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> + Ms Juliet Kemp +
> + Computer Manager [email]star@imperial.ac.uk[/email] +
> + Astrophysics Group +
> + Imperial College Tel: +44 (0)20759 47538 +
> + London. SW7 2AZ Fax: +44 (0)20759 47541 +
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>[/color]
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]