Zammad: LDAP Integration Improvements

addition:
Make it possible to filter based upon a given OU

Currently a workaround for changing the BaseDN is:

• Switch into admin console
• execute command Setting.get('ldap_config')
• copy the printed string which looks something like: {"host_url"=>"ldaps://127.0.0.1", "ssl_verify"=>false, "base_dn"=>"DC=domain,DC=tld", "bind_user"=>"user", "bind_pw"=>"pw", "user_uid"=>"samaccountname", "user_filter"=>"(&(objectClass=user)(samaccountname=*)(!(samaccountname=*$)))", "group_uid"=>"dn", "group_filter"=>"(objectClass=group)", "user_attributes"=>{"samaccountname"=>"login", "givenname"=>"firstname", "sn"=>"lastname", "mail"=>"email", "telephonenumber"=>"phone", "title"=>"note"}, "group_role_map"=>{}}
• change the value of the base_dn attribute as you need
• copy the new string and execute the following command in the admin console Setting.set('ldap_config', *new_string*) - __DON'T QUOTE THE STRING__, just copy past it. It's actually Ruby syntax 🤓 Should look like this: Setting.set('ldap_config', {"host_url"=>"ldaps://127.0.0.1", "ssl_verify"=>false, "base_dn"=>"OU=...,DC=domain,DC=tld", "bind_user"=>"user", "bind_pw"=>"pw", "user_uid"=>"samaccountname", "user_filter"=>"(&(objectClass=user)(samaccountname=*)(!(samaccountname=*$)))", "group_uid"=>"dn", "group_filter"=>"(objectClass=group)", "user_attributes"=>{"samaccountname"=>"login", "givenname"=>"firstname", "sn"=>"lastname", "mail"=>"email", "telephonenumber"=>"phone", "title"=>"note"}, "group_role_map"=>{}})

Please double check that you have only changed only the base_dn attribute to avoid unwanted and unexpected behavior.

Short update on how we will proceed:

• [X] Activity Stream
  We discussed this and came to conclusion that in cases with a lot of users it can be a information flood on the initial import but we don't want to skip (logging) information. On future imports this should be much less noise in the ActivityStream. A possible general feature would be a custom filter for the ActivityStream but is not planned yet.

• [X] Hide ms-attributes
  We discussed this and came to conclusion that in cases with a lot of attributes it can be a information flood on the initial import but we don't want to hide information that some people might need. So the ms-attributes will be shown. Since the mapping field is autocompleted it should be makeable to work around those ms-attributes.

• [x] Preview applies role assignments
  If a preview / dry run is performed the roles already get assigned which should not be done until the full import gets started.

• [x] Zero data error
  Currently there is an error shown when entering the LDAP integration admin interface for the first time. There should be nothing like this.

• [x] Changeable BaseDN / OU filter
  We will change the current BaseDN selection from a DropDown field to more of a proposal which can be used or changed however needed. This gives the possibility to extend the BaseDN and add a OU filter as needed. So there is no need for an additional always filter 🤓 for the BaseDN.

• [x] Changeable User filter
  The user filter is currently not changeable via the interface. This will be changed to provide an input field with the detected filter which then can be changed as desired.

• [x] Improving performance

  • [x] There is a performance bottleneck while importing the LDAP users. Zammad tries to fetch avatars from the configured webservices (if activated). This should get disabled for the for the LDAP runs. Tests showed that the performance will likely increase by over 50%.
  • [x] Another performance improvement will to limit the entry result attributes to only the ones we need.

• [x] Default behavior for users without role assignments
  As proposed by @chrklo there should be an option to decide how to proceed with users that have no roles assigned. Current behavior is that they are assigned the sign in roles. The option should decide if users without an assigned role should get the sign in roles assigned or if they should get skipped.

• [ ] Avatars from LDAP attribute thumbnailPhoto
  We discussed this and found out that there are various attributes where images could be stored in, e.g. thumbnailPhoto, jpegPhoto and photo (at least). There are different types of storage formats here (Binary, Base64, single value, multi value ...). These make it hard to find a proper way of abstracting things. So it still is a nice feature but we lowered the priority since the effort is currently to high for the benefits. Help is highly appreciated here!

@Julian0o About your your other point:

Ability to do a LDAP Filter on additional Attributes. Example: We have the attribute "ProxyAdresses" wich holds many values. To display the Fax Number of the user we have to pipe some data in this attribute.

I'm not sure if I got it correct. Can you please provide some practical example on how this should work and how the data looks?

my suggestion for the filter:

use the roles that you have allready in the ldap Mapping and make an button "always_filter" on/off

On: Only Users that match one of the roles/ldap Group will be synced
Off: Sync Everything

Hi @all - I've updated my post above with the current state and how we will proceed. Feedback is welcome. @chrklo do you think the exclusion is still needed when the user filter and BaseDN is changeable?

Changeable BaseDN is a good thing.
But in our tree Design not the solution because of parallel OUs.

What do you mean with OU filter?
Will it be possible to add more than one OU to the filter?

BaseDB
|-OU1-please-sync-me
|-OU2-please-sync-me
|-OU3-please-sync-me
|-OU4-please-dont-sync-me
|-OU5-please-dont-sync-me

If more filters are possible that would be a solution for me.
But I think many companys have system-users and external-user etc. wich they don't want to be synced.

Therefore my suggestion to (optionaly) only sync the the users that are in the matched role <--> ldap_group would be the accuratest solution.

Just a short update: The checked points from above are available in the latest stable package in round about 1 hour from now. There were some minor improvements, too. Feel free to test 🔨 Feedback would be great.

I'm currently working on the open points and keep you updated 🚀

Hi folks! Please have a look at the updated list. There are several other minor changes that are listed above with the commits I made. Feedback would be great!

This is the state that will probably get into the next release version if there are no major issues.

There is still an issue when stopping/restarting the Zammad scheduler/worker while an import job is running as described in #1008. We have a plan to how to fix that and I'm working on the implementation. I try to get this into the next release, too. 🚀

works perfekt!
thank you.

As stated in #350 the LDAP integration is now ready for Zammad version 1.6 and already (in about 30 minutes from now) in the latest 1.5 version, too 🎉

Thanks at you great folks for the comprehensive and valuable feedback. I think we added some extra sugar on top because of you and the feedback you gave 🍰

Feel free to create new issues if you have any troubles with the integration. 🤞

@Julian0o - would be cool if you could create a new issue for the image import functionality since its complexity and estimated effort to implement is currently out of our scope.

@thorsteneckel : I just tried LDAP as this was one of my day-zero-wishes :-))

Unfortunately I run into an issue: It connects perfectly, it finds my groups, I did the assignments - but finally after the text "Counting entries" it always gives me the error message "Invalid filter syntax".

I kept the "user filter" field empty in "Expert" - do I miss anything here?

When this is solved and I'm finally able to sync the users - I have already the users in the system without LDAP. If Zammad now finds users with matching email addresses in the LDAP server - will it automatically switch these users from local to LDAP authentication?

Hi @jacotec - What you are describing reads like an issue to me 🤕 Could you please create a new issue and add the following information:

• Your LDAP software vendor name and version
• The user filter that would be right / which you would use when connecting with some other client than Zammad. Usually it looks something like (objectClass=user)

Seems Zammad isn't able to detect the user filter for your LDAP automatically.

Regarding your other question: As stated in #1169 the users can either authenticate with the local DB or LDAP, both are checked. 🚀

Hi @thorsteneckel ,

I made it basically work by entering (objectClass=person) as user filter. It's worrying that it's not prefilled with anything, so I thought it would be fine to be empty, especially as it's listed as expert config. ;-)

However, the integration still has bugs unfortunately. I have two groups where users should become Agent, I've configured not to sync users which are not in these groups. Short summary:

• Existing users are merged by matching email addresses and Agent settings are kept, that's good!
• Non-existing users which are in at least one of the groups are imported, but they have no role assigned (that's a bug) - not even as a customer.
• Users which are not in any of my groups are also imported even I had selected not to sync them. They are not assigned to any role (not even as a customer). Sounds also like a bug for me.

I have my relevant users packed into a locality, is there a way to add this into the base? For now Zammad grabs also the users which are outside of the locality like my search and admin users.

I'll give it a test run again tonight (take a snapshot, put Zammad into maintenance mode and play around). Will Zammad continue to fetch mails in maintenance mode (because I'll restore the snapshot after testing and won't loose tickets which are coming in via mail in this time)?
If you tell me what kind of debugs/logs you need, I can take care of this in advance. I'll then file a new issue.

I'm using OpenLDAP with Fusion Directory https://www.fusiondirectory.org on Debian 8.

Hi @thorsteneckel ,

I've files issues #1179 and #1180 which are my showstoppers right now. I tried to describe these as good as possible, including several screenshots.

Enjoy ;-))

Hi @jacotec - you are great! I took a peak at them and that will help me a lot. Bot are bugs and should work as you are expecting them to work. However I will create some debugging scripts I need you to run if possible to get to the ground of these issues. I will try to provide them on monday. Thanks so far!

Hi @thorsteneckel ,

I'm happy to help. Let me know about your debugscripts ... as that's a VM it's easy for me to run them without harm ;-)