On Thu, 5 Nov 2015, Toby Blake wrote: > To close off the thread I started...
Thanks for doing so. > > On 2 Nov 2015, at 14:48, Toby Blake <t...@inf.ed.ac.uk> wrote: > > > > Hello, > > > > I'm trying to set up incremental propagation on a master-slave KDC > > configuration where the KDCs are clients of a different realm to the one > > they > > serve. > [...] > > I've done some hacking on this and the conclusion is that it's possible to do > what I want, but it does require code changes. > > Just pointing the slave and master at an alternative krb5.conf with > default_realm set accordingly is not enough. > > The changes required are in src/slave/kpropd.c:do_iprop > > Specifically, the iprop_svc_princstr and master_svc_princstr strings. > > When kadm5_init_with_skey is called, iprop_svc_princstr is set to > "kiprop/slave.domain@DOMAIN" > > This comes from iprop_svc_principal - it looks like the DOMAIN part is > generated via krb5_sname_to_principal/krb5_get_host_realm - so it's determined > from the host name itself. > > master_svc_princstr is set to "kiprop/master.domain" - i.e. no realm, so it > must be filled in subsequently. > > If I set iprop_svc_princstr and master_svc_princstr to > kiprop/host.domain@KDCDOMAIN explicitly then iprop works correctly. > > Hopefully the above is clear. It's largely for my benefit to write down what > I've discovered so I can work on a patch to do what I want properly when I > have a bit more time. Did you investigate putting a domain_realm mapping to KDCDOMAIN in the alternate krb5.conf during your testing? I would expect that to allow the krb5_sname_to_principal behavior to be changed. -Ben ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
