kopano on active directory

fbartels

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 0x00020006 as the log_level in server.cfg

PS: and please use code blocks when posting logs and configuration files

henna02

I have already enabled the debug mode in server.cfg

fbartels

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.

robertwbrandt

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.

Bob

thctlo

Hai, sorry to drop in.

Same problem here.
im connecting kopano to a samba AD.
I’ve tested also with my postfix setup.
for example,

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.

setup used:
https://documentation.kopano.io/kopanocore_administrator_manual/configure_kc_components.html#id3
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.

Greetz,
Louis

fbartels

Hello @thctlo ,

his ldap_bind_user is already lowercase. Can you explain a bit more which part of the documentation had you reconsider the casing for your bind user?

thctlo

Sure,
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

@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 ;-)

thctlo

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.

fbartels

@thctlo for me (8.4.90.0-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.

thctlo

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 :
ldap.active-directory.cfg
ldap.propmap.cfg

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.

thctlo

uhm, review the topic starters setup.

Why is the topic starter not using :
!include /usr/share/kopano/ldap.active-directory.cfg
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.

tip.
https://realtimelogic.com/blog/2014/05/How-to-act-as-a-Certificate-Authority-the-Easy-Way
This site explains a simple CA tool for windows users. That dont know how to handle it on Linux.

henna02

etc/hosts

0_1501269512884_b0c2fb15-3fde-4eb7-9acc-aca4a8d01751-image.png

etc/resolve

0_1501268946701_68697f8d-659d-4cd3-875a-6774dd85c6c6-image.png

ldap.cfg

0_1501269000522_0b627d59-8d59-4495-a449-09283e2ae2f0-image.png
0_1501269376734_a69c4816-34d9-4314-b5bd-ca8e4928543a-image.png
0_1501269153973_20935b10-9430-4d2d-bc12-d5eb0ca01a9d-image.png

What’s wrong yet?

thctlo

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
to /etc/ldap/ldap.conf

i’ve also added my AD DC root Certificate to :
/etc/ssl/certs/ca-certificates.crt

and example how.
https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/