Bug 450122 - kprop fails after upgrade from 5.1 to 5.2
Summary: kprop fails after upgrade from 5.1 to 5.2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: krb5
Version: 5.4
Hardware: i686
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-05 14:17 UTC by John Sopko
Modified: 2011-01-13 23:32 UTC (History)
3 users (show)

Fixed In Version: krb5-1.6.1-47.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-13 23:32:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0098 0 normal SHIPPED_LIVE krb5 bug fix and enhancement update 2011-01-12 17:39:25 UTC

Description John Sopko 2008-06-05 14:17:29 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:

always

Steps to Reproduce:

run kprop script as I have for the last year under
rhel5 and rhel5.1 fails in rhel5.2

  
Actual results:

kprop from master k5 server:

bash-3.2# /usr/kerberos/sbin/kprop -d -r CSX.UNC.EDU -f
/var/kerberos/krb5kdc/slavedbxfr ksix.csx.unc.edu
/usr/kerberos/sbin/kprop: Server rejected authentication (during sendauth
exchange) while authenticating to server
Generic remote error: Wrong principal in request


kpropd debug from slave server:

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

Expected results:

kprop to work as it did under rhel5.1


Additional info:

Tried using the kprop and kpropd executables from the previous
krb5-server-1.6.1-17.el5_1.1.i386.rpm rpm that used to work and
it still fails.

Comment 1 John Sopko 2008-06-05 15:35:40 UTC
Forgot to mention both the server and the slave have been
upgraded to rhel5.2 krb5-server-1.6.1-25.el5.

Comment 2 John Sopko 2008-06-05 16:11:09 UTC
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.EDU for
host/ksix.csx.unc.edu.EDU

Comment 3 John Sopko 2008-06-05 19:04:46 UTC
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.



Comment 4 John Sopko 2008-06-05 20:05:47 UTC
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.



Comment 5 John Sopko 2009-02-24 18:45:55 UTC
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

Comment 6 John Sopko 2009-09-24 18:25:20 UTC
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.

Comment 7 John Sopko 2009-10-05 20:57:14 UTC
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.EDU, ...)
authenticated client: host/kfive.csx.unc.edu.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.

Comment 9 Nalin Dahyabhai 2010-06-17 19:58:44 UTC
(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.EDU, ...)
> authenticated client: host/kfive.csx.unc.edu.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.

Comment 10 Nalin Dahyabhai 2010-09-09 19:34:14 UTC
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.

Comment 14 errata-xmlrpc 2011-01-13 23:32:50 UTC
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


Note You need to log in before you can comment on or make changes to this bug.