LDAP structure

Richard Lucassen

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.

fbartels

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.

Richard Lucassen

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.

fbartels

@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.

Richard Lucassen

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.

fbartels

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)

Richard Lucassen

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.

Richard Lucassen

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.