On 2022-07-18 12:34, Russ Allbery wrote:
Bill MacAllister <[email protected]> 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.
Yes, that is it exactly, kpropd was using exactly the hostname listed
for admin_server in the krb5.conf. When I "updated" admin_server to
use a cname instead replication broke. I have decided that on the KDCs
I would use a krb5.conf that uses only FQDNs. We have marginally
tighter
controls on FQDNs than cnames. For the krb5.conf used on all other
systems I will leave the cnames in place since it makes shuffling KDCs
without impacting clients simpler.
I didn't notice the LDAP similarity until you mentioned it.
Bill
P.S. I continue to be astonished by the word salad that I tend to emit.
Thanks everyone for figuring out my meaning.
--
Bill MacAllister <[email protected]>
"Can't sing louder than the guns when I'm gone,
so I guess I'll have to do it while I'm here."
Phil Ochs
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
