Cross-realm Trust Principals with LDAP

[Kemper, Stephan]

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 at 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 at 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 at 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.