Used Zammad installation source: (source, package, …) Docker-Compose
Operating system: Debian 9
Browser + version: Chrome 84.0.4147.89
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.
We can not map the following attributes, because the user (its a special system user) for the setup did not provide these:
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.
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?
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.
Thanks for your reply!
We do not move any kind of objects and we do not reference directly accounts. We only work with groups.
Our goal is to use our root base dn to setup everthing at the ldap wizard. Especially that the ldap wizard finds all LDAP attributes of our users. The users are in a sub OU.
We do not use openldap but we use Microsoft Active Directory.
You can safely only refer your DC as Base-DN and can remove the CN=Users if that’s one level too deep. Apart from that, if it still doesn’t work I may not understand the issue and thus can’t help you further.
I’m sorry. I could successfully use several OU Levels with a proper set Base-DN on root level.