Users get deactivated after LDAP-Sync

[daku1]

Infos:

Important:
If you are a Zammad Support or hosted customer and experience a technical issue, please refer to: support@zammad.com using your zammad-hostname / or company contract.

• Used Zammad version: 2,4
• Used Zammad installation source: (source, package, …)
• Operating system: OpenSuse 42.3
• Browser + version: Firefox

Wir haben synchronisieren über LDAP unsere User bzw. wenn diese in einer bestimmten Gruppe sind. Aber 2 User werden immer wieder deaktiviert. Wie kann ich das verhindern?

Expected behavior:

Actual behavior:

Steps to reproduce the behavior:

[MrGeneration]

Thanks for posting in the community. Please, for the next time, write english to the community, because we are international and other people (that don’t speak German) may not find a solution, even if there is.

The best idea is to see what those special two users have in common what the “working” users don’t have. Mostly it may be a missing login attribute or even deactivated accounts.

Please note that changes to synced LDAP-Users within Zammad will be overwritten by the next LDAP-Sync (because the LDAP-Source is always supposed to be right).

Also, your information is missing the Elasticsearch information and you’re using an outdated Zammad-Version. The current version is 2.6.

Bests

[thorsteneckel]

It might be the case that those users where once synced from the LDAP and now are not part of the result set of the search. In such cases Zammad assumes that the users got deleted/deactivated from the LDAP so they should get deleted in Zammad too. As @MrGeneration already stated correctly the LDAP is the leading source of truth for user accounts.

[daku1]

Elastic Search Version: 5.6.10-1
Zammad has now been updated to v2.6.

The 2 users are neither deactivated in the LDAP directory nor deleted. In addition, the two users are in the same LDAP group as the other active users. The 2 deactivated users can log them into OTRS without problems with the LDAP connection.

[thorsteneckel]

Hi @daku1 - to get to the root cause of this I need to debug further. Could you please follow the steps:

1.) Create a file called debug_issue.rb in your Zammad directory (usually /opt/zammad)
2.) Run the file from your Zammad directory via zammad run rails r debug_issue.rb or rails r debug_issue.rb as zammad user, depending on your installation source (package/source)
3.) Send the generated debug_issue.log file to support@zammad.com and let also name the email/login of those accounts that are affected. Please refer to this topic and me Make sure all sensitive data is anonymized!
4.) Delete the debug_issue.rb file

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

[thorsteneckel]

Hi @daku1 - thanks for providing that file. It seems like your mapping table is messed up. The table is used to build a connection between a Zammad and a LDAP user. It uses the LDAP objectguid which is unique. However, somehow some of your accounts got connected to different Zammad accounts.
This would be usually a support case if you had a support contract. We would clean things up in a remote session and make sure everything works as expected.
However, as a free alternative you could remove all entries in that mapping table and Zammad will try it’s best to recreate them. I can’t guarantee that this works as expected but should. If you do this make sure to do this is a maintenance window and have your backup ready.
Run the following line via the Zammad rails console:

::ExternalSync.destroy_all(source: "Ldap::User")

and restart your LDAP sync. Double check that everything works as expected.