[37836] in Kerberos
Re: Cross-realm Trust Principals with LDAP
daemon@ATHENA.MIT.EDU (Kemper, Stephan)
Mon Jan 23 19:04:14 2017
From: "Kemper, Stephan" <stephan.kemper@viasat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Tue, 24 Jan 2017 00:03:53 +0000
Message-ID: <A797FD68-3140-4A62-8C86-46CB7468F38E@viasat.com>
In-Reply-To: <2b240d55-00ef-971b-fc55-6c3c43ca38ee@mit.edu>
Content-Language: en-US
Content-ID: <3B7B1E66A0BABB43A29A9D8847491799@viasat.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hi Greg,
Thanks for the suggestion – I had completely forgotten this would show up in the LDAP logs. After running that down, it turns out (surprise!) to be a case of user error. The search base for the VIASAT.IO principals was wildly different from the base for our subrealms. One of our engineers had inadvertently configured our parent realm with a krbSubTrees of our root DIT, which is why it was always returning all possible principals. We removed the attribute from the realm container, and things are working as expected now.
Thanks for your help!
Stephan Kemper
Cloud Engineering
ViaSat, Inc.
On 1/23/17, 7:44 AM, "Greg Hudson" <ghudson@mit.edu> wrote:
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