Used Zammad version: 6.3.1-1717494961.ae2be7a4.jammy
Used Zammad installation type: (source, package, docker-compose, …) Package
Operating system: Ubuntu 22.04
Browser + version:
Expected behavior:
Users (customers) stay as they are
Actual behavior:
Users (customers) keep getting deactivated
Steps to reproduce the behavior:
Manually activate all users over cli
Actually, yes, I did read the LDAP toppics, but obviously I don’t understand correctly.
I would like to use LDAP for Admins and Agents. Therefore I added some extension to my LDAP user-filter. The user filter now only includes users, which are either in the AD Zammad-Admin or AD Zammad-Agent group.
Customers can be internal or external (meaning from AD or also external) therefore, I decided to import them from csv.
What I understood from other LDAP-related posts, if a user is not found in LDAP, Zammad won’t touch the user. (Is that correct?)
Actually, I have 6 AD-Users that are Agents and two are Admins. Then I have 230 AD-Users that are customers, but LDAP does not find them (In the last sync, I have there LDAP Users to Zammad Users: 6/6).
So, why is the system continouusly deactivating my 230 cutomers??
Customers were created from CSV import. But it could be, that LDAP did find those customers also in AD. (As my LDAP Filter did not work as expected at the beginning, and Zammad could also ‘see’ the user objects from AD, which are customers, imported over CSV).
Is there any way over CLI, to flag these users as NON-LDAP? Otherwise I’d need to delete all these users and re-create them again?
Is it sure, that if I do so, I will be able to have LDAP only for Agents and Admins running while customers are handled static?
I’m not sure if re-creating would solve your issue.
I thought, that only creation through ldap-sync would behave like this.
But it’s possible, that it will always deactivate your users, as long as they are in your AD but ignored cause of filter settings.
That’s why I would create some way to identify those with special rights in your ldap-sync.
These would be your agents and admins.
The easiest way is to create AD-groups (“zammad-agent”, “zammad-admin”) and make your agents/admins members of these.
Now you can map your agents and admins directly to your agent/admin-roles and all users missing these groups will be normal customers.
Thanks, for you reply. This is what I did, which seems to work, as Admins and Agents are not being disabled.
I assume, that because Zammad could ‘see’ the customers for a short time in AD (until I fixed my filter), and they matched by email-address to the CSV-imported ones, it started to look at them as if they were synced from LDAP.
I find it a bit uncommon, that the baseline cannot be set to an OU but only to the root of the AD. Therefore I have to filter out unwanted objects instead of setting the baseline to an OU where only admins and agents were located. But I can handle this, as long as I understand what the system is doing and why.