Get no users when ldap Active-directory plugin in use
lmensinck last edited by
Try to get kopano 11.0.1 server running with active directory users.
I already installed Active directory, bind user and ca ldapsearch to AD.
When running kopano-admin -l there are no users listed.
ldapsearch gets results from AD.
ldapsearch -H ldap://192.168.171.201 -D “cn=kopano-ldap,cn=Users,dc=ad,dc=***,dc=de" -b "DC=ad,DC=,DC=de” -x -w ***** “kopanoAccount=1”
with the search above I get ONE user as expected. Changing the search filter produces correct answers
kopano-admin -l got:
User list for Default(1):
Username Fullname Homeserver
SYSTEM SYSTEM Unknown
ldap_uri = ldap://192.168.171.201:389/ ldap_bind_user = cn=kopano-ldap,cn=Users,dc=ad,dc=*****,dc=de ldap_bind_passwd = ****** ldap_search_base = DC=ad,dc=*****,dc=de ....
I tried with different ldap attributes with no difference in ldap.cfg:
#ldap_user_search_filter = (&(objectCategory=Person)(kopanoAccount=1)) ldap_user_search_filter = (kopanoAccount=1) ldap_emailaddress_attribute = mail
Setting log_level in server.cfg to 0x00020003 I only get this in server.log
2021-04-09T09:54:58.443716: [ 20006] plugin: Issuing LDAP bind 2021-04-09T09:54:58.452084: [ 20006] plugin: ldaptiming [16012µs] connected to ldap
How can I raise a log level to see the actual ldap query send by kopano-server or any hint about configuration agains ActiveDirectory is apreciated.
the desired information can be found in the man page of kopano-server:
DIAGNOSTICS If you run into problems, check the log for any errors. If you made a mistake in the configuration of the log method, this will be reported on standard error. You can also restart the server with a higher log level. Also, before starting the server, always make sure the database server is running at the right location and no other server is listening on the configured TCP port. For extended diagnostics, there are special extended log options available for enhanced debugging capabilities. The parameter log_level has special or-ed values which can be set to investigate different modules within the server process: SQL: 0x00010000, User backend: 0x00020000, Server cache: 0x00040000, SOAP: 0x00100000, ICS: 0x00200000 For example, if you are using LDAP as the user plugin, you can set the log_level to 0x00020006 for extended LDAP logging (the last digit 6 enables extended verbose logging). To enable SQL and LDAP logging at the same time, set log_level to 0x00030006 WARNING: The log options create huge amounts of log entries in production environments, this results in abnormal large logfiles which can fill up available disk space very fast. Only use this with extreme caution.
So to get “user plugin” logging (which in your case is ldap) you have to set the following log level:
Did you uncomment the base configuration for ADS in your
lmensinck last edited by
Thanks for Your reply,. I already tried to set log_level 0x00020006 with no success.
But I now got it running to get answers from AD.
Do not know why, but apparmor was my favorite candidate.
So I reinstalled (whoo like working on Windows) the lates community builds on a fresh debian 10 without apparmor installed and got success to query AD.
On this I also get log entries in syslog as well as in any desired logfile I define.
I saw apparmor messages before on the first system regarding DENIED für /usr/lib/kopano/ files, but sorry, I did not document this before deleting the vm.