In a hosted deployment, using the original design for multi-domain Kolab, each registered (parent) domain is assigned a separate root dn / database for its LDAP hierarchy.
This means that with thousands of domains being registered, the LDAP server spends a lot of time maintaining way too many databases, for otherwise separate legal entities that are not at all sufficiently large to justify the overhead.
A new structure for this would be to:
- in the domain base dn for the management domain:
```
dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s,dc=hosted,dc=com
```
should result in `*@%s` being resolved to use `ou=%s,dc=hosted,dc=com`.
Additional domains (aka. alias domains) should be considered child domains -- the parent domain is the boss over it, but the child domains are aliases that can separately be given a status of active (means ownership confirmed);
- in the domain base dn for the management domain:
```
dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
objectclass: extensibleObject
inetdomainbasedn: ou=%s,dc=hosted,dc=com
inetdomainstatus: active
dn: associatedDomain=%s2,associatedDomain=%s1,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s1,dc=hosted,dc=com
inetdomainstatus: new
```
This structure could ultimately also allow resellers (tenants) to specify the child domain is to be administered separately:
- in the domain base dn for the management domain:
```
dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
objectclass: extensibleObject
inetdomainbasedn: ou=%s,dc=hosted,dc=com
inetdomainstatus: active
dn: associatedDomain=%s2,associatedDomain=%s1,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s2,dc=hosted,dc=com
inetdomainstatus: active
```
The question is how various pieces of infrastructure need to be modified in order to be able to address this new structure.