search

zammad / zammad

Zammad is a web based open source helpdesk/customer support system
https://zammad.org
GNU Affero General Public License v3.0
4.44k stars 756 forks source link

"Unable to retrive group information, please check your bind user permissions." #1602

Closed lpar closed 6 years ago

lpar commented 7 years ago

Infos:

Actual behavior:

Followup to issue #1422 so all other info (bind DN, base DN etc) is as per that ticket.

thorsteneckel commented 6 years ago

Hi @lpar - nice to see you again ;) To get an orientation please run the ruby code as follows:

1.) Create a file called debug_ldap.rb in your Zammad directory (usually /opt/zammad) 2.) Run the file from your Zammad directory via zammad run rails r debug_ldap.rb or rails r debug_ldap.rb as zammad user, depending on your installation source (package/source) 3.) Post the output here. Make sure all sensitive data is anonymized! If you want you can drop it as an email to support@zammad.com. Please refer to this issue and me :) 4.) Delete the debug_ldap.rb file

bind_dn    = 'dn here'
bind_pw    = 'password here'
filter     = '(objectClass=person)'
host       = 'bluepages.ibm.com'
port       = 636
base_dn    = 'ou=bluepages,o=ibm.com'
ssl        = true
ssl_verify = true

require 'ldap'

params = {
  host:       host,
  port:       port,
  ssl:        ssl,
  ssl_verify: ssl_verify,
  base_dn:    base_dn,
  bind_user:  bind_dn,
  bind_pw:    bind_pw,
}

ldap  = ::Ldap.new(params)
group = ::Ldap::Group.new(params, ldap: ldap)

p group.filter

This reproduces the behavior of Zammad trying to find the filter for listing all available groups. There is a list of default group filters. If a filter returns some entries it will be used. I think none of the filters matches for you. If there is no output of the script: What would be the filter you would use to list all groups in your bluepages.ibm.com setup?

lpar commented 6 years ago

It outputs nil.

Our groups are under a different base DN, ou=memberlist,ou=ibmgroups,o=ibm.com

For example, if I do:

ldap.search(:base => "ou=memberlist,ou=ibmgroups,o=ibm.com",
               :scope => Net::LDAP::SearchScope_SingleLevel,
               :filter => nil) do |entry|
                 pp entry
                 break
               end

I get

#<Net::LDAP::Entry:0x0055846991c830
 @myhash=
  {:dn=>["cn=admin,ou=memberlist,ou=ibmgroups,o=ibm.com"],
   :objectclass=>["groupOfUniqueNames", "top"],
   :o=>["ibm.com"],
   :cn=>["admin"],
   :ou=>["ibmgroups", "memberlist"],
   :uniquemember=>
    ["uid=REDACTED,c=us,ou=bluepages,o=ibm.com",
     "uid=REDACTED,c=us,ou=bluepages,o=ibm.com",
     "uid=REDACTED,c=us,ou=bluepages,o=ibm.com",
     "uid=REDACTED,c=us,ou=bluepages,o=ibm.com",
     "uid=REDACTED,c=us,ou=bluepages,o=ibm.com",
     "uid=REDACTED,c=us,ou=bluepages,o=ibm.com"]}>

where each uniquemember value is a DN of a user.

thorsteneckel commented 6 years ago

Could you please replace lib/ldap/group.rb with this file. Restart your Zammad services (Websocket, Scheduler and Application) afterwards. Then retry the import again via the admin interface. While doing so have a look at the log/production.log file and provide the generated, anonymized content in case of an error. 🤞

lpar commented 6 years ago

I'm afraid I don't get anything useful in the production.log:

I, [2017-11-03T11:20:16.655036 #517]  INFO -- : Started POST "/api/v1/integration/ldap/bind" for 9.80.198.211 at 2017-11-03 11:20:16 -0400
I, [2017-11-03T11:20:16.667944 #517]  INFO -- : Processing by Integration::LdapController#bind as JSON
I, [2017-11-03T11:20:16.668207 #517]  INFO -- :   Parameters: {"base_dn"=>"ou=bluepages,o=ibm.com", "bind_user"=>"uid=L13490897,c=us,ou=bluepages,o=ibm.com", "bind_pw"=>"[FILTERED]", "host_url"=>"ldaps://bluepages.ibm.com/", "ssl_verify"=>true}
I, [2017-11-03T11:20:17.019961 #519]  INFO -- : 2017-11-03T11:20:17-0400: [Worker(host:techelp.dfw.ibm.com pid:519)] Job Observer::UserDeviceLogJob (id=403) RUNNING
I, [2017-11-03T11:20:18.968583 #519]  INFO -- : 2017-11-03T11:20:18-0400: [Worker(host:techelp.dfw.ibm.com pid:519)] Job Observer::UserDeviceLogJob (id=403) COMPLETED after 1.9482
I, [2017-11-03T11:20:20.876715 #519]  INFO -- : Scheduler running...
thorsteneckel commented 6 years ago

What happened in the admin interface?

lpar commented 6 years ago

The same "Unable to retrive group information, please check your bind user permissions" error message.

thorsteneckel commented 6 years ago

Hi @lpar - we did some changes regarding the LDAP groups via issue #1664 which might affect your issue, too. Could you please check if your issue still persists in the latest version of the develop branch? Thanks!

lpar commented 6 years ago

No improvement. "Unable to retrive group information, please check your bind user permissions."

AchuM commented 6 years ago

I had this issue before and I fix it by including the default OpenLDAP objectclass.

After upgrading to 2.3 the group file was restored back and experienced the same issue.

So under /opt/zammad/lib/ldap/group.rb on line 115 it should be something like this to get ride of this issue:

@filter ||= lookup_filter(['(objectClass= organizationalUnit)', '(objectClass=group)', '(objectClass=posixgroup)', '(objectClass=organization)', '(ou=memberlist,ou=ibmgroups,o=ibm.com)'])

lpar commented 6 years ago

That does indeed get me past the error!

thorsteneckel commented 6 years ago

Great @AchuM - thank you very much for your input! We will refactor the group filter detection very soon to chose the correct one. We will use the filter with the most entries found. That should work. Any feedback is appreciated.

lpar commented 6 years ago

So what is the next thing Zammad does? Because once I get past the error that it locks up performing some sort of processing. I think it might be trying to iterate through entries, which isn't going to work well because there are over 386,000 of them.

thorsteneckel commented 6 years ago

Could you post a screenshot of the dialog. I'm lost trace where we are currently.

lpar commented 6 years ago

I get a dialog asking for LDAP sync mappings, so I provide some:

zam1_opt

At the bottom of that dialog I click Continue. It says analyzing structure briefly, then presents a dialog saying it's counting entries, which may take a while:

zam2_opt

Since I haven't asked it to do any mapping between LDAP groups and Zammad roles, the only thing I can think of is that it's counting the users. If that's the case, it's not going to go well.

thorsteneckel commented 6 years ago

Hi @lpar - We have done some performance improvements in the LDAP sync which reduce the overall runtime by up to 30%. However, sorry to say but 386.000 entries is still not a use case we aim to cover. Just out of curiosity: Why do you need all these users in your Zammad?

lpar commented 6 years ago

I don't need all of those users. What I need is some way to have directory information populated for the ones who actually use Zammad, and to have them able to log in with their enterprise credentials. The OAuth2 authentication seems to be buggy and ignores some fields, so I was hoping the LDAP integration might fill out the missing information, or even allow for authentication via LDAP.

thorsteneckel commented 6 years ago

Which way do you prefer? For the LDAP sync I would recommend to have some distinguishing feature that can be used in a LDAP filter (in the expert block below). The size of the result set is responsible for the duration of the import. Which size would it be in your setup after applying such filter? We have multiple customers syncing round about 20.000 users into Zammad without any issues. The first sync takes some time but after that only diffs are applied which speeds up the process lot.

lpar commented 6 years ago

Would it be possible to sync from LDAP only for accounts which are created on the fly via (say) OAuth2 login or some other method? That would avoid the initial long sync and avoid having tens of thousands of unnecessary accounts in the database — which is a liability given GDPR.

thorsteneckel commented 6 years ago

There are two possible LDAP integrations in general: Bulk sync or on the fly. We already had experience with on the fly syncs before designing Zammads LDAP integration and decided against it because of the negative side effects it brings with it. To avoid unnecessary accounts in the database a proper LDAP filter should be used. So the OAuth2 way would be preferable for your use case I guess then. We will have a look at the issue 👍 I'm closing here now since we can't go further from here. Correct me if I'm wrong. Thanks for your great support getting this far.