LDAP structure



  • Is there somewhere an overview how a companies/groups/users are best organized in LDAP for use with Kopano?

    dc=example,dc=com
      \__ ou=company1,dc=example,dc=com
          \__ ou=sales,ou=company1,dc=example,dc=com
          \__ ou=management,ou=company1,dc=example,dc=com
          \__ ou=users,ou=company1,dc=example,dc=com
              \__ uid=user1,ou=users,ou=company1,dc=example,dc=com
              \__ uid=user2,ou=users,ou=company1,dc=example,dc=com
              \__ uid=user3,ou=users,ou=company1,dc=example,dc=com
      \__ ou=company2,dc=example,dc=com
          \__ ou=sales,ou=company2,dc=example,dc=com
          \__ ou=management,ou=company1,dc=example,dc=com
          \__ ou=users,ou=company2,dc=example,dc=com
              \__ uid=user4,ou=users,ou=company2,dc=example,dc=com
              \__ uid=user5,ou=users,ou=company2,dc=example,dc=com
              \__ uid=user6,ou=users,ou=company2,dc=example,dc=com
    

    I think something like this? Or should I work with group membership? I just ask this because I’m not familiar with this kind of use of LDAP and the docs do not show a preferred setup for Kopano. Groupware software is new to me and there are many many ways to organize an LDAP tree.

    Richard.


  • Kopano

    Hi @Richard-Lucassen ,

    from this and your other posts it seems you are planning a bigger installation. I would therefore recommend to get in contact with our sales team. They will be happy to provide you with information and recommendations for building your platform.



  • For the moment it is all very small, just a few users. Two, to be
    exact. I’m just playing with the product as you might have noticed, and
    there are several components (such as iCal/Z-push) that do not work yet
    due to lack of experience (and time). For the moment I’m just
    eager to know if I can run it supervised under runit (answer: yes) and
    how the product behaves (looks and feels good)

    And as I mentioned before, I’m new to groupware. The reason that I
    asked this LDAP question is that I have a multi realm LinOTP server
    that has it’s own LDAP and LDAP tree and I was just wondering if I
    could be able to combine the LinOTP RADIUS realm tree with a Kopano
    LDAP tree. Of course I can, but then the question popped up if such an
    LDAP tree is Kopano friendly.

    So from my posts it looks like it’s going to be big if you look at the
    components that I use, but for the moment I’m just having a glance at
    it.

    Richard.


  • Kopano

    @Richard-Lucassen said in LDAP structure:

    And as I mentioned before, I’m new to groupware.

    Even more important then to get professional help ;-)

    I cannot speak about LinOTP, but for a multi tenant Kopano installation the only thing that matters is that the element under which you store you items in the tree has objectclass defined in ldap_company_type_attribute_value.



  • I can of course give Kopano a call tomorrow, but normally I must be able to set up these sort of things. Mucking about with the software is part of a steep slope learning curve, as usual with Linux. And don’t forget Linux docs only become comprehensible when you don’t need them anymore ;-)

    Anyway, the LinOTP is very flexible, for each RADIUS realm I can use separate servers, search bases and bind DNs. So I’m always able to adopt the LinOTP to the Kopano LDAP tree. The question remains what the LDAP tree should look like. The structure I posted in the OP should work, as the tenants are placed in a separate OU. But AFAIUI Kopano searches for the uid attribute in the search base, and thus the attribute uid must be unique across all tenants, right or wrong?

    R.


  • Kopano

    In the default configuration uid would be the value for:

    https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/ldap.m4#77-80

    I would say the name of the option should explain what it is utilized for (hence should be unique).

    https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/ldap.m4#50-60 should be unique as well (there may be others, but this and the group equivalents, is what i can think of at the moment)



  • I have this in /etc/kopano/ldap.cfg:

    !include /usr/share/kopano/ldap.openldap.cfg
    ldap_search_base = ou=users,dc=example,dc=com
    ldap_uri = ldap://localhost:389/
    ldap_user_search_filter = (kopanoAccount=1)
    

    A question about the uidNumber, this is in the /usr/share/ ldap config:

    ldap_user_unique_attribute = uidNumber
    

    Is the uidNumber attribute taken into account when adding a store to a user? I ask this because I just fsck’d up my account because I have 2 users with uid=richard, but in a different ou and with a different uidNumber. I was astonished because that other user “richard” was outside the “ldap_search_base”. When running

    kopano-admin --details richard
    

    the uidNumber is not mentioned.

    Another thing: while trying to re-hook the store to my account (I succeeded), I tried to clear the cache:

    kopano-admin --clear-cache
    Error reading config file /etc/kopano/admin.cfg
    [crit   ] Config error: Cannot normalize path "/etc/kopano/admin.cfg": No such file or directory
    

    I can’t find a sample file in /usr/share/ (remember: Debian Buster packages). Is this file necessary and if yes, is there a sample on the net?

    Sorry to bother you again with my noob questions.

    R.



  • I stumbled upon the answer:

    “The unique user attribute is the mapping between a mailbox in the database and the actual user in LDAP. Make sure this field is never changed as Kopano will perceive that as a user being deleted (and created), and will therefore orphan the user’s store.”

    R.


Log in to reply