espocrm / espocrm-docker

Official Docker Image for EspoCRM
https://hub.docker.com/r/espocrm/espocrm
GNU Affero General Public License v3.0
56 stars 34 forks source link

LDAP authentication #8

Closed jasonheffner closed 2 years ago

jasonheffner commented 2 years ago

EspoCRM 6.1.10, and 6.1.9

LDAP authentication not working in Docker Hub image. LDAP Authentication working fine when I build using...

docker-compose.yml

image: crm-webapp:${espo_version}
build:
  context: ./docker/apache
  dockerfile: Dockerfile

CI job

- cd ./docker/apache
- docker build --no-cache -t crm-webapp:${espo_version} -f Dockerfile .

Ldap authentication has been working for multiple versions. I wanted to switch to Docker Hub image. When trying to use docker hub image authentication will not work. I can easily swap in/out docker hub image and going from working to not working and vice versa. Here was the image I tried...

docker-compose.yml

image: espocrm/espocrm:6.1.10-apache

I'm not sure what the differences are/or if you are missing ldap libraries in the docker hub version.

jasonheffner commented 2 years ago

more info: I use port 389 over TLS for ldap authentication with a user login filter

jasonheffner commented 2 years ago

This one has me stumped .. updated and tested with espocrm/espocrm:7-apache .. I'm not sure the difference in the docker-compose build vs buildkit dockerhub image.

tmachyshyn commented 2 years ago

Please let me know what LDAP (AD, OpenLDAP) server do you use? Screenshots of your LDAP settings in EspoCRM are appreciated.

jasonheffner commented 2 years ago

Hi,

I attached a screenshot. The error message from the DEBUG log was

ERROR: LDAP: Could not connect to LDAP server [XXXXXXXXXX], details: 0x5b (Connect error; (unknown error code)): XXXXXXXXXX:389 [] []

In case there was a compatibility problem I also updated docker and docker-compose on the host server. If I docker-compose build the resulting image works fine. If I use the one from docker hub it can't connect to ldap.

ldap_settings

We use an OpenLDAP server

Mexonizator commented 2 years ago

It seems you have the same problem as me. The docker hub image has some problems with establishing a secure connection (or perhaps with locating the CA cert).

When you try connecting using an encryption, it can't locate the CA cert, hence the error. If you try an unsecure connection, most likely it'll succeed...

jasonheffner commented 2 years ago

@Mexonizator We don't have the option of using an insecure connection; that would be irresponsible anyway. Do you get the same message in your DEBUG logs? I'm curious if building the image would also work for you then? I'm not certain it's a certificate error.

Mexonizator commented 2 years ago

Agree, as for production, I wouldn't use an unsecure connection either.

Yes, if I try TLS, I get the same as you:

Error 500: 0x5b (Connect error; (unknown error code))

If try SSL, it's slightly different:

Error 500: 0x51 (Can't contact LDAP server; (unknown error code))

So, the error basically is the same. As for the building I haven't tried it yet. If I have time, I'll test it. But I hope the devs would investigate and fix the image.

jasonheffner commented 2 years ago

Yeah, It's most likely the same issue then. I haven't compared the resulting images yet, but was comparing image layers in the containers and they seem the same. I'm thinking it may be something with the multi-platform build and the detection for the php ldap libraries install. I haven't had a chance to dig deeper yet.

jasonheffner commented 2 years ago

I did a quick image comparison and found that the docker hub image was updated to Debian bullseye. The image in the apache build is still buster. I did a quick test by using the php:7.4-apache-bullseye image and found that is the culprit. The install script probably needs updated for bullseye.

jasonheffner commented 2 years ago

I'm still going through the bullseye updates needed for the default image switch in the php:7.4-apache image. A quick fix is to use php:7.4-apache-buster for now in your docker hub images. The first hurdle was referenced here ...

https://github.com/docker-library/php/issues/1194

and solved by adding libldap-common. This alone didn't fix the TLS issue yet in the new docker hub images.

jasonheffner commented 2 years ago

@tmachyshyn

The php:7.4-apache updated from buster to bullseye. It no longer includes libldap-common by default (link above). You can either use php:7.4-apache-buster or add libldap-common to the base image. I would suggest adding that package at the beginning to avoid the apt-purge later or add in both to your "install php libs" and "install required libs" code blocks.

jasonheffner commented 2 years ago

Some quick additional testing shows you only need to add it for the "install required libs" and isn't needed for the php install.

Mexonizator commented 2 years ago

@jasonheffner

Thank you! With the help from the lib you mentioned I finally found a quick and dirty way to fix the problem. So, all you need is to:

1) Install libldap-common; 2) Put the CA certificate of the LDAP server to /etc/ssl/certs/ca-certificates.crt

And it'd work like a charm!

But of course I'd like to see a proper fix from the devs...

jasonheffner commented 2 years ago

@Mexonizator

Yeah, It's simply missing that package. I'm using this Dockerfile right now till it's added to the docker images.

FROM espocrm/espocrm:7-apache

RUN apt-get update && apt-get install -y --no-install-recommends \ libldap-common \ && rm -rf /var/lib/apt/lists/*

Our CA cert is already installed with debian so we didn't need that.

tmachyshyn commented 2 years ago

Thanks for your suggestion. Fixed https://github.com/espocrm/docker/commit/417b529c5b7be54e409848a4a9edf5835ba794d8.

jasonheffner commented 2 years ago

@tmachyshyn

Unfortunately that doesn't fix it as you are using apt-mark and apt-get purge with auto-remove. The package doesn't end up in the final docker image. You need to install it here

https://github.com/espocrm/docker/blob/master/Dockerfile-debian.template#L65

or put it outside of your apt-mark.