[Kolab-devel] Cyrus and LDAP Groups ACLs problems in multidomain setup

[Daniel Hoffend]

Hello

this gets a bit longer, so I've started to write down a mail rather then 
chat in #kolab. I've digged deeper in into the ldap_* attribute used for 
canonification within cyrus,
especially in a multidomain scenario with multiple ldap name spaces. 
Most things that
can be totally ignored when running on a single ldap directory.

1)  ldap_base, ldap_member_base and ldap_group_base are behaving strange 
when using
     ldap_domain_base: cn=kolab,cn=config.

     *   I previously assumed it would use the wrong base to search in 
and thought it would
         be help full to use something similar like we do in roundcube 
kolab_auth when we
         modify the base to ou=People,%dc. But it's working different

     *   It's not documented in the manpage, but when using 
ldap_domain_base. If a result
         has been found, ldap*_base gets fully replaced with the base 
discovered.

         Before: ldap_member_base: ou=People,dc=example,org
         After:  ldap_member_base: dc=otherdomain,dc=org

         There's no way to limit this or adjust it to your needs. So it 
works in practice
         but it's not what you would expect when you configure things to 
get fully
         overwritten.

     *   Right now I can't decide if the current way to replacing 
ldap_base midflight is
         the best way or if it's better to configure the ldap_base to 
ou=People,%B and
         the case no domain has been found in ldap_domain_filter fall 
back to a configurable
         ldap_domain_default_base instead of the defaults imapd.conf. 
That's a design
         decision I currently can't make and won't make.

2)  Cyrus Groups are currently backed by LDAP 'Roles' in the default 
kolab installation

     *   Roles are currently assigned on user level and not comparable to 
membership based
         Objects like posixGroup or groupOfNames. That's different but 
okay if you know it.

3)  Cyrus Groups are assign on folders in the following format:

     *   sam <folder> group:<groupidentifier> <acl>

4)  Cyrus will lookup the group using his ldad_group_* parameters. If 
the group has been
     found the aci gets added.

5)  The lookup will use the ldad_group_base which detected by 
ldap_domain_base or falls
     back fo the default configured in imapd.conf

     *   If a user adds an ACI to one of his folder using roundcube 
(group:teamabc)
         the lookup for teamabc will be done in the context of user's 
ldap_base
         because group:teamabc doesn't contain a realm

     *   if cyrus-admin (trigger by kolab-webadmin) wants to add an aci 
to a shared folder
         the ldap_base will be the default one cause neither cyrus-admin 
nor the group
         have a @realm configured to his account

         *   If the folder exists in the non-primary domain the lookup 
for a role that
             only exists in the secondary domain space will fail because 
it can't be found
             in the primary domain (no realm was given)

         *   If you try to add group:teamabc at otherdomain.org the realm 
gets detected and the
             correct ldap_group_base gets used. But the lookup will fail 
cause there's no
             role with CN=group at domain.

             *   Workaround change your filter from %u to %U (todo: 
update pykolab defaults)

         *   with the workaround in place you can savely add the aci to 
the folder, but
             you'll not be able to access the folder because 
group:teamabc is not the same
             like group:teamabc at otherdomain.org

6)   Currently both group namings are valid an pass the ldap_lookup 
checks (if configured
      correct configured.

      *   Way1: group:teamabc
      *   Way2: group:teamabc at domain

      but only way1 works because the match within cyrus is matched 
against the CN of
      the nsrole object. And this object doesn't contains the @domain 
part

      *   Having a group object without the @domain part you don't know 
which domain
          you must check against. is teamabc in primary_domain the same 
teamabc in
          secondary_domain?

      *   Is it allowed to have cross-realm aci? Like john at example.org 
can access stuff
          shared by jane at otherdomain.org?

      *   If there's no cross-realm sharing you can savely use groupnames 
without @realm

      *   Summary:

          *   Cyrus Group Membership Lookup is broken when using 
ldap_domain_base discovery
          *   groupname != groupname at realm because the realm doesn't get 
stripped when
              checking the users group membership
          *   both naming conventions gets accepted by cyrus but both 
have their own problems.
          *   cyrus-imapd manpage is lacking information for ldap*base 
that the configured
              value gets replaced *if* ldap_domain_filter returns with a 
result.

7)   Again most things can be ignored or don't apply to single 
domain/ldap scenarios
      because this ldap_base switching doesn't happen.

      *   If you turn off ptloader these ldap_group_base checks are not 
done either,
          therefore you can add whatever you want into the aci without 
checks if a group
          exists or not.

      *   tbh. kolab-webadmin doesn't support check group: syntax as 
well. it would be
          helpfull if the IMAP ACL popup would have an option "Group: " 
similar to "User:".
          This way you can make checks and/or run auto completion.

      *   roundcube doesn't check the group: syntax either.




--
Best Regards
Daniel Hoffend