Page MenuHomePhorge

admin role created in the wrong base_dn
Closed, ResolvedPublic

Description

I'm testing the new changes for hosted mode on Debian 10.

I've created a setup with mgmt domain and hosted domain. When creating a new domain (that gets created as OU underneath the hosted domain tree), the generic cn=kolab-admin doesn't get created.

When looking at the dirsrv logfile it gets a bit strange:

[08/Nov/2019:04:10:09.501229039 +0100] conn=314 op=3 ADD dn="associateddomain=example.net,ou=Domains,dc=dotlan,dc=info"
[08/Nov/2019:04:10:09.512371219 +0100] conn=314 op=5 ADD dn="ou=example.net,dc=hosted,dc=com"
[08/Nov/2019:04:10:09.518693000 +0100] conn=314 op=7 ADD dn="ou=Groups,ou=example.net,dc=hosted,dc=com"
[08/Nov/2019:04:10:09.521691763 +0100] conn=314 op=9 ADD dn="ou=People,ou=example.net,dc=hosted,dc=com"
[08/Nov/2019:04:10:09.527274248 +0100] conn=314 op=11 ADD dn="ou=Resources,ou=example.net,dc=hosted,dc=com"
[08/Nov/2019:04:10:09.531236889 +0100] conn=314 op=13 ADD dn="ou=Shared Folders,ou=example.net,dc=hosted,dc=com"
[08/Nov/2019:04:10:09.537894495 +0100] conn=314 op=15 ADD dn="cn=kolab-admin,dc=dotlan,dc=info" <<<<<<<<<

It looks like the role api service doesn't support the 'base_dn' = $domain_root_dn attribute and therefore trys to create the needed role in the mgmt_root_dn instead of domain_root_dn.

Details

Ticket Type
Task

Event Timeline

We're taking about this call:
https://git.kolab.org/diffusion/WAP/browse/master/lib/api/kolab_api_service_domain.php$413-418

Possible Fixes:

  1. Add an optional $domain parameter for role_add and which then gets forwarded to Auth::get_instances($domain) in the role api class
  2. Temporary overwrite $_SESSION['user'] (switch to the selected domain), create the role and restore old value of $_SESSION['user']. This way Auth::get_instance() will open a different Auth object for a different namespace
  3. when checking input arguments also allow the base_dn attribute for roles.

Current Workaround:

Create the kolab-admin role manually after domain creation.

Hi Daniel, Good catch. The 3rd option looks good to me. parse_input_attributes() should probably accept base_dn input for all kind of objects, not only 'ou' (except domain objects). https://git.kolab.org/diffusion/WAP/browse/master/lib/kolab_api_service.php$419

machniak claimed this task.

Fixed.