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" <ghud...@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...@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
