There's a problem; The code will only consider other domains to be child if both domain entrys have a inetdomainrootbasedn attribute. If the main one is missing the attribute, the list is not gonna get compiled correctly

I tested the code and can confirm that it works. Apart from the $result which is not used (in return or log statement).

The only edge case is when the main entry is missing the inetdomainbasedn attribute.

Example1:

• associateddomain=example.org,cn=kolab,cn=config
  • associateddomain=example.org
  • associateddomain=example.com
• associateddomain=domain.org,cn=kolab,cn=config
  • associateddomain=domain.org
  • associateddomain=domain.com
  • inetdomainbasedn=dc=example,dc=org

list of valid domains (when primary_domain = example.org):

• example.org
• example.com

Example 2:

• associateddomain=example.org,cn=kolab,cn=config
  • associateddomain=example.org
  • associateddomain=example.com
  • inetdomainbasedn=dc=example,dc=org
• associateddomain=domain.org,cn=kolab,cn=config
  • associateddomain=domain.org
  • associateddomain=domain.com
  • inetdomainbasedn=dc=example,dc=org

list of valid domains (when primary_domain = example.org):

• example.org
• example.com
• domain.org
• domain.com

Possible Workround

There could be a workaround to strip the primary domain from the inetdoman object and construct the calculated basedn. But tbh. This is a edge case. You can also enforce/say/request/define: If you merge multiple inetdomain objects into the same basedn, all related inetdomain objects must have the inetdomainbasedn attribute set.

In D10#212, @dhoffend wrote:

The only edge case is when the main entry is missing the inetdomainbasedn attribute.

Example1:

• associateddomain=example.org,cn=kolab,cn=config
  • associateddomain=example.org
  • associateddomain=example.com

In this case, the example.com domain is considered an alias domain name space of the parent domain name space example.org, and without a inetdomainbasedn attribute value, will cause both to result in dc=example,dc=org.

• associateddomain=domain.org,cn=kolab,cn=config
  • associateddomain=domain.org
  • associateddomain=domain.com
  • inetdomainbasedn=dc=example,dc=org

This case could occur in combination with the former entry, but is not a real-life scenario -- the former entry would already result in dc=example,dc=org, it already holds alias domain name spaces, so this "child" domain name space (not to mention it having its own "alias" domain name space).

The intention is to facilitate either alias domain name spaces or child domain name spaces. Child domain name spaces are separate LDAP entries specifically, so that they may be confirmed ownership for separately from any parent domain name space.

Please also note that the "parent" domain name space becomes ubiquitous since there is no routine to resolve any domain name space back to it's original parent domain name space unless a dc=example,dc=org base dn is also directly correlated with the domain name space example.org.