Heres an update to the kerberos realm issue I am now seeing.
I want to use my secondary KDC (UVWX.YZ.EDU) rather than the primary
KDC (YZ.EDU), but amanda doesnt seem to know how to look for it. I
include the KDC realm in all of my config's. amanda.conf, and .k5login.
Here is my .k5login
backup/amandabackup AT UVWX.YZ DOT EDU
I am able to kinit with the secondary KDC on the client using the
keytab that I have on the server.
[ckotil@skip tmp]$ kinit backup/amandabackup AT UVWX.YZ DOT EDU -kt "/home/
ckotil/keytab-amanda"
[ckotil@skip tmp]$
This works just fine.
Here is what i have in my amanda.conf
krb5keytab "/etc/amanda/keytab-amanda"
krb5principal "backup/amandabackup AT UVWX.YZ DOT EDU"
The reason I think that amanda is ignoring the kerberos realm is
because of this error that I see on the client in /tmp/amanda/amandad.
1214918169.546254: amandad: gss_name host/skip AT YZ DOT EDU
1214918169.546587: amandad: critical (fatal): gss_server failed: can't
acquire creds for host key host/skip: No such file or directory
It claims the gss_name is host/skip AT YZ DOT EDU when it should be host/skip
AT UVWX.YZ DOT EDU
Any ideas?
Thanks,
--Chad
On Jun 26, 2008, at 9:37 PM, Chad Kotil wrote:
Ian,
Jean-Loiuis provided me with a patch that fixed this problem. The
patch was posted to the list.
I now face a new problem. I need to use my secondary kdc REALM to
authenticate, and not my default realm. The keytab on the server is
from the second kdc realm and the principal is from this realm too.
But, the client tries to authenticate with the default realm.
Any idea how I can tell the client to use the secondary kerberos
realm?
Thanks,
--Chad
On Jun 26, 2008, at 6:46 PM, Ian Turner wrote:
Chad,
This is a bug in Amanda. I have filed a bug report. As a
workaround, you can
probably make it work by compiling --without-force-uid.
I don't think we have any kerberos users who test out daily builds,
so
sometimes things break and nobody notices right away. Maybe if you
have a
spare machine, you can become the community kerberos tester. :-)
Cheers,
--Ian
On Thursday 26 June 2008 10:36:56 you wrote:
When i run spawn amandad via xinetd as root, i get this error.
1214490832.259079: amandad: critical (fatal): running as user "root"
instead of "amandabackup"
In the kerberos wiki it says amandad will relinquish root
permissions
after reading the keytab. It doesnt seem to be doing that.
Also, What keytab on the client needs to be read as root?
--Chad
On Jun 25, 2008, at 5:29 PM, Jean-Louis Martineau wrote:
xinetd must be configured to run amandad as root.
Jean-Louis
Chad Kotil wrote:
I am trying to setup krb5 auth on amanda 2.6.0p1. I built the
server and client --with-krb5-security, added a new principal to
my
KDC (amandabackup@KERBEROS REALM), and wrote a keytab file and
placed it on the server. It is locked down so only amandabackup
(the user that runs amanda) can read it. The clients have
a .k5amandahosts file containing the following:
amandabackup@KERBEROS REALM
backupmaster.f.q.d.n amandabackup@KERBEROS REALM
my amanda.conf file contains
krb5keytab "/etc/amanda/krb5.keytab-amanda"
krb5principal "amandabackup@KERBEROS REALM"
On both of my krb5 auth clients I am seeing this error:
1214425629.641678: amandad: critical (fatal): gss_server failed:
real uid is 10036, needs to be 0 to read krb5 host key
10036 is the UID for amandabackup, 0 is the UID for root.
Both clients work fine if I just use bsdtcp auth. I am using ssh
auth everywhere else but for these two particular hosts I cannot
use ssh keys.
Any ideas?
Thanks,
--Chad
Chad E. Kotil
Global Research NOC
ckotil AT grnoc.iu DOT edu
Phone: 812 855-5288
--
Forums for Amanda discussion: http://forums.zmanda.com/
Chad E. Kotil
Global Research NOC
ckotil AT grnoc.iu DOT edu
Phone: 812 855-5288
|