[37306] in Kerberos
Re: Incremental propagation when KDCs are clients of a different realm
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Fri Nov 6 19:07:52 2015
Date: Fri, 6 Nov 2015 19:04:57 -0500 (EST)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Toby Blake <toby@inf.ed.ac.uk>
In-Reply-To: <B9A026FD-6A85-4408-9F15-32F20383A3EC@inf.ed.ac.uk>
Message-ID: <alpine.GSO.1.10.1511061903300.26829@multics.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 <toby@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
