Forgot to mention both the server and the slave have been
upgraded to rhel5.2 krb5-server-1.6.1-25.el5.

I am doing the kprop command form master krb5 server host kfive.csx.unc.edu
to slave server ksix.csx.unc.edu.

If I look at the kdc log while doing the kprop command the logs shows the
following AS_REQ which appears to be successful:

Jun 05 12:06:15 kfive.csx.unc.edu krb5kdc[2751](info): AS_REQ (12 etypes {18 17
16 23 1 3 2 11 10 15 12 13}) 152.2.129.25: ISSUE: authtime 1212681975, etypes
{rep=16 tkt=16 ses=16}, host/kfive.csx.unc.edu@CSX.UNC.EDU for
host/ksix.csx.unc.edu@CSX.UNC.EDU

I am now rsyncing the "kdb5_util dump" from the server
to the client and doing "kdb5_util load" on the client so this is not
that critical for me. Feel free to lower the priority.

Note, I noticed that the "kdb5_util dump" is supposed to take
a filename for the database name but this version does not let
you, for example:

/usr/kerberos/sbin/kdb5_util load some_dump_file principal

will fail. You need to exclude the db filename and the
"/var/kerberos/krb5kdc/principal database is implied
as the filename.

I am now rsyncing the "kdb5_util dump" from the server
to the client and doing "kdb5_util load" on the client so this is not
that critical for me. Feel free to lower the priority.

Note, I noticed that the "kdb5_util dump" is supposed to take
a filename for the database name but this version does not let
you, for example:

/usr/kerberos/sbin/kdb5_util load some_dump_file principal

will fail. You need to exclude the db filename and the
"/var/kerberos/krb5kdc/principal database is implied
as the filename.

I updated our 2 krb5 master and slave server to rhel5.3,
krb5-server-1.6.1-31.el5, and still have the same problem with kprop,
the error message is the same as with rhel5.2

I updated our krb5 master and slave server from rhel5.3 to rhel5.4 same problem. Same error. I re-created /etc/krb5.keytab using ktadd on the master and slave.

One thing I noticed, it appears the slave running kpropd is not opening
/var/kerberos/krb5kdc/kpropd.acl. I tried to specify the kprod.acl file
with the -a option stillno luck. I used "strace" putting kpropd in debug
mode to see what files it opened on startup and while trying a kpop command
from the master and did not see an open file call for the access file.

Fixed problem with kpropd. The kpropd needs to have the REALM specified.
This used to work in rhel5.1 without the REALM. The kpropd man page says
"by default the realm returned by krb5_default_local_realm(3) is used".
I can find no info on "krb5_default_local_realm(3)" and do not know why
kpropd does not use the default_realm in /etc/krb5.conf.

Running kpropd in debug mode with NO REALM specified shows
host/ksix.cs.unc.edu@ has no REALM:

# /usr/kerberos/sbin/kpropd -S -d
Connection from kfive.csx.unc.edu
krb5_recvauth(4, kprop5_01, host/ksix.csx.unc.edu@, ...)


Running kpropd in debug mode with REALM specified shows the REALM
CSX.UNC.EDU and the kprop from the master works:

# /usr/kerberos/sbin/kpropd -S -d -r CSX.UNC.EDU
Connection from kfive.csx.unc.edu
krb5_recvauth(4, kprop5_01, host/ksix.csx.unc.edu@CSX.UNC.EDU, ...)
authenticated client: host/kfive.csx.unc.edu@CSX.UNC.EDU (etype == Triple DES cbc mode with HMAC/sha1)


The kprop client side has the same issue, you must specify the REALM else you get the error:

# /usr/kerberos/sbin/kprop -d -f /var/kerberos/krb5kdc/slavedbxfr ksix.csx.unc.edu
/usr/kerberos/sbin/kprop: Cannot resolve network address for KDC in requested realm while getting initial ticket

Specify the -r REALM option on both client and server and things work:

# /usr/kerberos/sbin/kprop -r CSX.UNC.EDU -f /var/kerberos/krb5kdc/slavedbxfr ksix.csx.unc.edu
Database propagation to ksix.csx.unc.edu: SUCCEEDED


It would be nice if someone could comment on why this may be
happening. Thanks.

(In reply to comment #7)
> Fixed problem with kpropd. The kpropd needs to have the REALM specified.
> This used to work in rhel5.1 without the REALM. The kpropd man page says
> "by default the realm returned by krb5_default_local_realm(3) is used".
> I can find no info on "krb5_default_local_realm(3)" and do not know why
> kpropd does not use the default_realm in /etc/krb5.conf.
> 
> Running kpropd in debug mode with NO REALM specified shows
> host/ksix.cs.unc.edu@ has no REALM:
> 
> # /usr/kerberos/sbin/kpropd -S -d
> Connection from kfive.csx.unc.edu
> krb5_recvauth(4, kprop5_01, host/ksix.csx.unc.edu@, ...)
> 
> 
> Running kpropd in debug mode with REALM specified shows the REALM
> CSX.UNC.EDU and the kprop from the master works:
> 
> # /usr/kerberos/sbin/kpropd -S -d -r CSX.UNC.EDU
> Connection from kfive.csx.unc.edu
> krb5_recvauth(4, kprop5_01, host/ksix.csx.unc.edu@CSX.UNC.EDU, ...)
> authenticated client: host/kfive.csx.unc.edu@CSX.UNC.EDU (etype == Triple DES
> cbc mode with HMAC/sha1)
> 
> 
> The kprop client side has the same issue, you must specify the REALM else you
> get the error:
> 
> # /usr/kerberos/sbin/kprop -d -f /var/kerberos/krb5kdc/slavedbxfr
> ksix.csx.unc.edu
> /usr/kerberos/sbin/kprop: Cannot resolve network address for KDC in requested
> realm while getting initial ticket
> 
> Specify the -r REALM option on both client and server and things work:
> 
> # /usr/kerberos/sbin/kprop -r CSX.UNC.EDU -f /var/kerberos/krb5kdc/slavedbxfr
> ksix.csx.unc.edu
> Database propagation to ksix.csx.unc.edu: SUCCEEDED
> 
> 
> It would be nice if someone could comment on why this may be
> happening. Thanks.    

I'm wondering if this is related to http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=5551, though I would have expected that problem to crop up here during the 5.0/5.1 transition, when we updated the package from 1.5 to 1.6.1, rather than between 5.1 and 5.2.

When I reproduce the error here, the patch in the above-mentioned RT entry fixes it.  The root cause appears to be that the server (kpropd in this case) is unable to determine the realm of the host on which it's running, so I'd expect that an entry in the kpropd host's krb5.conf's [domain_realm] section would also keep the error from cropping up.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0098.html