LDAP Mapping Problem

Infos:

  • Used Zammad version: 3.2
  • Used Zammad installation source: (source, package, …) Docker-Compose
  • Operating system: Debian 9
  • Browser + version: Chrome 84.0.4147.89

Expected behavior:

All LDAP mappings should be shown, even if the user Zammad uses for the setup has not filled in all attributes. Alternatively, you can select another user for configuration. Or configure the attributes in the rails console.

Actual behavior:

We can not map the following attributes, because the user (its a special system user) for the setup did not provide these:
sn
mail
telephonenumber

Its not a mapping limit problem, because we can only see 28 attributes in the selection.

Steps to reproduce the behavior:

Configure LDAP with the builtin wizard. See screenshots.

The LDAP mapping itself technically doesn’t have a limit, however, the attribute lookup for mapping does.
The responsible line is this one:

You can safely bumb that 50 up to a 1500 - you can go in highe2r than you theoretically have to. On some systems this is necessary if the first 50 accounts don’t have so many attributes set.

This change is not update safe and is only required during configuration of your ldap integration. No need to adjust the file after every update as long as you don’t want to re-configure ldap.

Changed it to 1500 but i dont see more attributes. Is a restart for the docker container neccessary? In my opinion it is not a limit problem. Any chance to configure the ldap settings in a file or per the console?`
If i set the attributes by hand in the wizard and save it, zammad ignores theses attributes and set it to a blank field.

Ensure that Zammad does find users where the attribute in question is set.
Zammad only display attributes that are actually set with values in the user.

Technically yes, but so damn error prone that I’d like to not suggest this step.
The reason I’m saying this is that it will be out of my scope if you have issues on that configuration part. I won’t be able to help you with my time I do have.

Ok i found the problem. We have an active directory with different OUs (User, Dienst-Gruppen …) In the OU “Dienst-Gruppen” we have different groups. For example “QS-ZammadComKunde” (role customers), “QS-ZammadComAgent” (role agents) and “QS-ZammadUser” (ldap user filter). These groups includes the different users for the permission assignment. OU “Users” includes the users and they are member of different groups. Maybe the screenshot helps to identify our structure:


In the ldap wizard we had setup our root OU “abc.xyz” for the Base DN. Now zammad tries to read our active directory and shows all mapping. As the result look at the screenshot in the first post. If we move our groups and users in only one OU and changed the Base DN to this OU everything works as expected. But to the disadvantage of the structure at our AD.
So is this a bug and are we the first with this problem?

Can you please post your complete user filter.
I’m struggling to understand where you want to lead me.

Here are my settings before the change:

And here are my new settings:

Thanks for the further input.
I can successfully use a root base within LDAP and several independent user accounts and security groups within different CNs. Everything works as expected on my end. Right now I don’t think that this is a bug.

Please ensure that you’re not using nested groups (so permission providence via several groups chained to each other) as this is not supported at the moment.

We do not use nested groups for zammad.

Odd.
I can’t reproduce this on my own LDAP.
As long as you don’t move objects (specially in terms of your security groups) to other OUs this should be no problem hat all.

Above does not apply for accounts because that works differently.
If you move a security group, you’ll need to adjust your ldap configuration in Zammad, because the referencing is direct not named.

Just in case I missed it and it’s your actual goal:
It’s not possible within Active Directory to restrict your LDAP query to specific OUs.

With my base dyn being “abc.xyz” I can successfully use any sub ou. It doesn’t matter it’s no issue of I have several accounts in different ous.

In case you use openldap:
Please note that by default the listing of objects is limited. If you do use it, you may need to raise that limit.