kopano on active directory
I was hooking up dig in active directory on windows server 2016 r2. I modified the ldap.cfg file, but when I make copy-admin -l it returns the following error:
Unable to list users, object not found
Using the -v option (possibly multiple times) may give more hints.
Logs on server.log are as follows:
Thu Jul 20 22:15:37 2017: [crit ] Cannot instantiate user plugin: Failure connecting any of the LDAP servers Thu Jul 20 22:15:37 2017: [crit ] Unable to instantiate user plugin Thu Jul 20 22:17:17 2017: [warning] Log connection was reset Thu Jul 20 22:27:12 2017: [warning] Previous message logged 2 times Thu Jul 20 22:27:12 2017: [warning] LDAP (simple) bind failed: Can't contact LDAP server Thu Jul 20 22:27:12 2017: [crit ] Cannot instantiate user plugin: Failure connecting any of the LDAP servers Thu Jul 20 22:27:12 2017: [crit ] Unable to instantiate user plugin Thu Jul 20 22:32:59 2017: [warning] LDAP (simple) bind failed: Can't contact LDAP server Thu Jul 20 22:32:59 2017: [crit ] Cannot instantiate user plugin: Failure connecting any of the LDAP servers Thu Jul 20 22:32:59 2017: [crit ] Unable to instantiate user plugin
The file ldap.cfg is this:
############################################################## # LDAP DIRECTORY USER PLUGIN SETTINGS # # Select implementation. # If you have any reason to override settings from /usr/share/kopano/*.cfg, # do so at the end of this (/etc-resident) config file. # !include /usr/share/kopano/ldap.openldap.cfg #!include /usr/share/kopano/ldap.active-directory.cfg # LDAP host name/IP address ldap_host = 192.168.1.12 # LDAP port # Optional, default = 389 # Use 636 for ldaps ldap_port = 636 # LDAP protocol # Optional, default = ldap # use 'ldaps' for Implicit SSL encryption. Make sure /etc/ldap/ldap.conf is # configured correctly with TLS_CACERT ldap_protocol = ldaps # LDAP URI # Optional, override ldap_host, ldap_port and ldap_protocol if set # e.g. ldaps://servername:port. You may also specify multiple space-separated # URIs #ldap_uri = # The charset that strings are stored in on the LDAP server. Normally this # is utf-8, but this can differ according to your setup. The charset specified # here must be supported by your iconv(1) setup. See iconv -l for all charset #ldap_server_charset = utf-8 # The DN of the user to bind as for normal operations (not used for # authentication if ldap_authentication_method is set to "bind". # When empty, uses anonymous binding. # The userPassword attribute must be readable for this user if the # ldap_authentication_method option is set to password. ldap_bind_user = cn=administrator,cn=users,dc=fabrizio,dc=local # LDAP bind password ldap_bind_passwd = ***password**** ldap_authentication_method = bind # The timeout for network operations in seconds #ldap_network_timeout = 30 # ldap_page_size limits the number of results from a query that will be downloaded at a time. # Default ADS MaxPageSize is 1000. ldap_page_size = 1000 ########## # Object settings ldap_object_type_attribute = objectClass ldap_user_type_attribute_value = User ldap_group_type_attribute_value = Group ldap_contact_type_attribute_value = Contact ldap_company_type_attribute_value = ou ldap_addresslist_type_attribute_value = kopano-addresslist ldap_dynamicgroup_type_attribute_value = kopano-dynamicgroup ldap_user_search_filter = (kopanoAccount=1) ldap_user_unique_attribute = objectGUID ldap_user_unique_attribute_type = binary ldap_fullname_attribute = cn ldap_loginname_attribute = sAMAccountName ldap_emailaddress_attribute = mail ldap_emailaliases_attribute = otherMailbox ldap_password_attribute = ldap_isadmin_attribute = kopanoAdmin ldap_nonactive_attribute = kopanoSharedStoreOnly # Top level search base, every object should be available under this tree ldap_search_base = dc=fabrizio,dc=local # Use custom defined LDAP property mappings # This is not a requirement for most environments but allows custom mappings of # special LDAP properties to custom MAPI attributes #!propmap /etc/kopano/ldap.propmap.cfg
can you help me?
Hello @henna02 ,
the way it looks at the moment you have a mistake in your bind credentials. Maybe enabling the debug logging of the user plugin turns up more details. set
PS: and please use code blocks when posting logs and configuration files
I have already enabled the debug mode in server.cfg
I would check if you can list your users with ldapsearch, if that succeeds then there is no reason for kopano to not be able to connect you ads.
Is there a reason you are using SSL? I know it is more secure, but if the two servers are sitting right next to each other in a switched environment, it might be worth disabling it. SSL adds about 4x the network traffic. While I use ALWAYS use SSL between the servers and user, I never use SSL between two servers if I can help it.
The reason I mention it, is that I wonder if there might be a certificate error. Is the domain Root CA installed on the Kopano box? However, the easiest way is to just not use SSL. @fbartels is right, a LDAPSEARCH should duplicate any problems.
Also, I would use a custom bind user with more limited rights then Administrator.
Hai, sorry to drop in.
Same problem here.
im connecting kopano to a samba AD.
I’ve tested also with my postfix setup.
postmap -q root ldap:/etc/postfix/kopano-ads-local-redirects.cf
This test, makes that my “local root” email adres, is redirected to an email adres in my public folder.
if i run kopano-admin -l
kopano-admin -l Unable to list users, object not found Using the -v option (possibly multiple times) may give more hints.
i did enable log level 6 ( debug ), which shows.
Thu Jul 27 13:27:16 2017: [ notice] Starting server version 8,4,0,1103, pid 16041 Thu Jul 27 13:27:16 2017: [info ] Using select events Thu Jul 27 13:27:16 2017: [notice ] Listening for TCP connections on port 236 Thu Jul 27 13:27:16 2017: [notice ] Listening for SSL connections on port 237 Thu Jul 27 13:27:16 2017: [notice ] Listening for priority pipe connections on /var/run/kopano/prio.sock Thu Jul 27 13:27:16 2017: [notice ] Listening for pipe connections on /var/run/kopano/server.sock Thu Jul 27 13:27:16 2017: [notice ] Connection to database 'db_kopano' succeeded Thu Jul 27 13:27:16 2017: [notice ] Querying database for searchfolders. This may take a while. Thu Jul 27 13:27:16 2017: [notice ] Loading search folders. Thu Jul 27 13:27:16 2017: [notice ] Done loading search folders. Thu Jul 27 13:27:16 2017: [notice ] Startup succeeded on pid 16041 Thu Jul 27 13:27:16 2017: [debug ] Started priority thread c31b5700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c29b4700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c21b3700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c19b2700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c11b1700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c09b0700 Thu Jul 27 13:27:16 2017: [debug ] Started thread c01af700 Thu Jul 27 13:27:16 2017: [debug ] Started thread bf9ae700 Thu Jul 27 13:27:16 2017: [debug ] Started thread bf1ad700 Thu Jul 27 13:27:23 2017: [warning] LDAP (simple) bind failed: Invalid credentials Thu Jul 27 13:27:23 2017: [crit ] Cannot instantiate user plugin: Failure connecting any of the LDAP servers Thu Jul 27 13:27:23 2017: [crit ] Unable to instantiate user plugin
the postfix bind_dn is exact the same as what i use in the ldap.conf as is the password.
now, the link also provide the solution for me, and imo, this is a minor bug.
I also found the solution for me and this was my fix.
For Zarafa ( 7.2.1 ) this worked.
ldap_bind_user = CN=secret-user,OU=Service-Accounts,OU=COMPANY,DC=internal,DC=domain,DC=tld
but this is not working for kopano…
i changed that line to this :
ldap_bind_user = cn=secret-user,ou=Service-Accounts,ou=COMPANY,dc=internal,dc=domain,dc=tld
And now kopano-admin -l works again, and i see all i want to see…
I hope this helps the topic starter also.
Hello @thctlo ,
ldap_bind_useris already lowercase. Can you explain a bit more which part of the documentation had you reconsider the casing for your bind user?
chapter, 5.16.2. Configuring KC for ADS.
there i saw:
ldap_bind_user = cn=administrator,cn=users,dc=example,dc=com
i noticed the lowercased cn=
so i tried that and that worked.
I just checked again and im sure that zarafa 7.2.1 ( last i was running ), and that worked fine with the upper cased version .
@thctlo give me a few mint to add something, i need to check something for the topic starter.
and give you my reputation back, with what it was in the zarafa forum, please
ok, the topic starter needs to do the following.
( as already suggest)
create a new user. (bind2ldapuser) for example.
I also suggest create a OU for these “service accounts” and add them there.
Set in the Account tab, at account options:
check , password never expires.
check, user cannot change password
check, Do not require Kerberos preauthenticaion.
that should fix it, and dont set these options on your Administrator account.
@thctlo for me (126.96.36.199-0+4.1) it works regardless of the casing of the bind user. running openldap though, so the actual ldap server may differ in behaviour.
Then i might be worth to mention more of my setup.
Debian Linux ( mixed jessie and stretch servers )
2 x Samba AD DC version : 4.6.6 (The zarafa setup was working with 4.5.x AD)
I installed kopano and i did not install any kopano schema anywhere, i still use the latest 7.2.1 zarafa schema in my Samba AD.
i copied these files :
to my /etc/kopano and change there where needed the kopanoXXXX to zarafaXXXXX
and same for the propmap.cfg
so maybe the mix of zarafa/kopano with the "bind user = CN or cn " is wat my caused my problem.
uhm, review the topic starters setup.
Why is the topic starter not using :
but he is using the openldap setup.
he used : ldap_host = 192.168.1.12 but connects with ldaps ?
so he must first make sure his server is using the DC DNS. ( resolv.conf)
make sure /etc/hosts is correct.
remove 127.0.1.1 lines
and check for the line if it exists, if not add it.
server_ip hostname.example.com hostname
and change : ldap_host to the server hostname.
Correct resolving helps a lot.
About 50% of the samba problems are due to incorrect resolvings and people ignoring that the world is changing to ssl ( and samba case kerberos ) and both kerberos and ssl rely on resolving.
This site explains a simple CA tool for windows users. That dont know how to handle it on Linux.
What’s wrong yet?
I can say the following about your config.
Dont use user Adminstrator, create a new user for ldap_bind_users.
why, see https://forum.kopano.io/post/2605
Also you cant set Do not require Kerberos preauthentication on Administator.
( you can but dont do that! )
Do configure and setup ssl for you Linux client so client <=> server works with ldaps.
add : TLS_REQCERT allow
i’ve also added my AD DC root Certificate to :
and example how.