Hide Forgot
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.
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 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