[37835] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Cross-realm Trust Principals with LDAP

daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jan 23 10:44:17 2017

To: "Kemper, Stephan" <stephan.kemper@viasat.com>,
        "kerberos@mit.edu" <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <2b240d55-00ef-971b-fc55-6c3c43ca38ee@mit.edu>
Date: Mon, 23 Jan 2017 10:44:00 -0500
MIME-Version: 1.0
In-Reply-To: <A4F23F18-7B17-4A63-BEA3-473725A0B88F@viasat.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

On 01/22/2017 07:11 PM, Kemper, Stephan wrote:
> Sorry for the spam, but after continuing to investigate, it looks like this database shortcut only works for vertical trusts.  A krbtgt/A.VIASAT.IO@B.VIASAT.IO principal only shows up in the realm it’s created in.  That definitely pushes me toward the “unintended/bug” end of the spectrum, because otherwise the interface wouldn’t be uniform.

The libkdb_ldap is_principal_in_realm() excepts cross-realm TGT
principals because otherwise there would be no way to store krbtgt/B@A
in realm A, but I don't think there was any intent to allow them to be
shared between databases for different realms.

I don't currently understand why the sharing seems to happen between
A.VISITAT.IO and VISITAT.IO, but not between A.VISITAT.IO and
B.VISITAT.IO.  The structure of your LDAP database as you described it
doesn't seem to have a vertical relationship between VISITAT.IO and
A.VISITAT.IO, so I wouldn't expect the searches to behave any
differently.  Investigating the LDAP server logs to look at the searches
performed by kadmind might be helpful.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post