[39122] in Kerberos
Re: Help with replication
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Jul 18 15:37:44 2022
From: Russ Allbery <eagle@eyrie.org>
To: Bill MacAllister <bill@ca-zephyr.org>
CC: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <kerberos@mit.edu>
In-Reply-To: <2ec4e1247f558f3b27bd74b6f931a0d9@ca-zephyr.org> (Bill
MacAllister's message of "Mon, 18 Jul 2022 10:47:09 -0700")
Date: Mon, 18 Jul 2022 12:34:16 -0700
Message-ID: <871quikyfb.fsf@hope.eyrie.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Bill MacAllister <bill@ca-zephyr.org> writes:
> The KDC logs revealed that indeed the principal did not exist. I had
> updated the krb5.conf to use a cname for the admin principal and kpropd
> is using the entry in the krb5.conf without canonicalization. I changed
> the krb5.conf file to use host names that matched the principals that I
> had created. That along with making sure kadm5.acl and kpropd.acl had
> the appropriate entries solved my problem. Thanks for the pointer.
> (Who would have thought to look in the logs? Certainly now me.)
Is this the thing where kpropd always uses exactly the hostname you have
listed and doesn't do any DNS canonicalization? If so, I've run into that
before and I think I just put keys for all of the principals that could be
formed from all the possible replica names in the keytab file for the
replicas and my recollection is that worked, although it's been a few
years.
> I guess one what would be to create principals for the cnames.
Right, yeah, that. Similar to what we had to do with LDAP servers.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
