Apache Directory LDAP auth fail

[mariuspana]

Infos:

• Used Zammad version: 3.2.0-1576861015.528479ce
• Used Zammad installation source: package
• Operating system: CentOS Linux release 7.7.1908 (Core)
• Browser + version: Safari 13, Chrome 79, Firefox (not sure, latest)

Expected behavior:

• LDAP should connect as per documentation and allow further configuration of filters/parameters.

Actual behavior:

• After introducing the ldap URI (ldaps://ip|host) we instantly get an error “Can’t connect to ‘ds01.ldap.host’ on port ‘636’, Can’t bind to ‘ds01.ldap.host’, 49, Invalid Credentials”

Steps to reproduce the behavior:

• Enable LDAP integration and add Apache Directory LDAP URI

Hi,

We’re using Apache Directory (ldapv3 compliant server) as our source and when configuring the LDAP integration we never get past the intial screen which seems to try to bind without credentials.

The production.log shows “E, [2020-01-07T18:06:58.558776 #24255-47412182782020] ERROR – : Can’t bind to ‘ds01.ldap.host’, 49, Invalid Credentials (Exceptions::UnprocessableEntity)” and then a long stacktrace (I believe) but nothing regarding base/bind_dn which of course were never provided as we did not get to that screen.

Seeing the above behaviour I setup the ldap_config using zammad console and it does show-up in the UI but the results are exactly the same. Of interest is the fact that I did specify a correct bind_dn/user filters, etc.

We’re sure our ldap is working and the filters are correct but happy to take another look if someone could point us in the right direction. We’re at a bit of a loss as we’re getting failures without actually having gotten to the point (at least in the UI) where we specify the credentials.

Thanks!
Marius

Here is the ldap_config for reference:

Setting.get(‘ldap_config’)
=> {“host_url”=>“ldaps://ds01.ldap.host”, “ssl_verify”=>false, “base_dn”=>“ou=people,ou=ldap,o=host”, “bind_user”=>“uid=binder,ou=people,ou=ldap,o=host”, “bind_pw”=>“secretpass”, “user_uid”=>“uid”, “user_filter”=>“(&(objectClass=inetOrgPerson))”, “group_uid”=>“dn”, “group_filter”=>“(objectClass=groupOfNames)”, “user_attributes”=>{“uid”=>“login”, “cn”=>“firstname”, “sn”=>“lastname”, “mail”=>“mail”}, “group_role_map”=>{}}

[martin.von.wittich]

You’re using LDAPS, but Zammad apparently attempts to connect on port 636, which might be atypical for LDAP over SSL. Could this be the cause? Try:

ldaps://ds01.foobar.com:10636

This works for us with slapd.

[mariuspana]

Thank you for your input.
The port for ldaps is indeed 636 which is what I am using.
Something has changed since I posted however as I now see error logs with the names of my users in ldap:

Ill try to get a tcpdump running later see if that gives me some more information. In the meantime Ill search for an ldap_debug.rb script I saw mentioned in an issue on github as that may show more details.

Getting there

Thanks!

[mariuspana]

The sync issue was due to a mismatch in attribute from LDAP to Zammad: specifically I use mail in ldap and in zammad I thought it was the same when it should have been email.

To debug the issue I created a file named debug_issue.rb in zammad $root and ran it using zammad run rails r debug_issue.rb and read the generated log.

Here is what the file should contain, I cannot find the source for this but I am sure it was somwhere on zammad github issue tracker.

require 'mixin/rails_logger'

module Mixin
  module RailsLogger
    def self.logger
      @logger ||= Logger.new(log_to).tap do |logger|
        logger.level = :debug
      end
    end

    def self.log_to
      # STDOUT
      'debug_issue.log'
    end
  end
end


ImportJob.create(name: 'Import::Ldap').start

If anyone has any ideas on why from the GUI I cannot connect to map the attributes (which would be very helpful for group mapping) shoot them my way.

Cheers,
Marius

[MrGeneration]

You’re firewall doesn’t block outgoing ldaps right?
Can you connect to the LDAP server from your Zammad machine with e.g. ldapsearch?

Any Proxy settings active on your host by any chance?

[mariuspana]

Thank you for your thoughts.
There is no firewall on either end however there is an haproxy between zammad and our ldap server.

I can use ldapsearch just fine. Also zammad ldap integration is working, just not via the GUI.
There is no proxy configuration/settings on the zammad host.

As soon as I get a couple of free minutes I would like to get a tcpdump to see if there is anything I can identify there.

[mariuspana]

While running tcpdump -vv I performed an ldap search and then tried using the “Change” button from within Zammad -> Integrations -> LDAP to trigger a connection to our ldap server.

My understanding unfortunately fails here as I cannot see anything to indicate a problem. There is one noticeable difference in the volume of data generated by ldapsearch vs. the attempted connection via zammad but I believe this is due to the fact ldapsearch returns my list of users while connecting from zammad does not.

Here is the tcpdump output while using ldapsearch and here using the Zammad GUI.

[MrGeneration]

Maybe @thorsteneckel can help, I can’t.

[cpzengel]

@mariuspana

ldap_debug.rb

same problem here
logfile shows all ldap/ad information, but does notprocess it

cat debug_issue.log | grep failed | wc
33480 1184744 21907764

I am running AD Server 2016 and Zammad for UCS

[mariuspana]

I have not had time to look into it further. I am content that it is working, although the mapping using the rails console was not pleasant. Hopefully in the near future I can pick this up.

[MrGeneration]

@cpzengel I suggest resetting your ldap configuration to nothing.
Why? Because the Zammad-App for UCS configures the ldap configuration to work with univention which is using different uuid identifiers than Microsoft Active Directory does.

Technically speaking: Your use case is out of scope of the UCS app, while it technically will work, it requires you to do manual magic once.