Help with replication

[Bill MacAllister]

On 2022-07-18 12:34, Russ Allbery wrote:
> Bill MacAllister <bill at 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.

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 <bill at ca-zephyr.org>

"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