kopano on active directory

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/