LDAPs

[BeateLerch]

I am currently evaluating Leantime as a docker container, version 2.4.8 I try to attach it to our AD/LDAP, but it wont work. I think it is because LDAPs is either not supported or just not documented.

Debug reports only "can not connect to LDAP Server".

But here it is: modern AD will not accept insecure standard LDAP on Port 389, instead it accepts only LDAPs on Port 636. So, which is the issue and how can I fix it?

Thanks, Beate

[MIPMHannes]

Hi. Had the same issue. I run the docker container FYI.

Problem

The issue seems to be that leantime docker container tries to validate the ldaps certificate. The container is unable to do this. This was my assumption at least. I tested a bit and here is what I found (I found an open issue from an other unrelated project that propsed this solution. I just modified it a bit. I would love to reference this issue but sadly I can not find it anymore).

The workaround

Add - ./config_data:/etc/openldap to your docker-compose.yml under volumes section. Create a file called ldap.conf in the config_data folder. The file has following contents:

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.
TLS_REQCERT     never
#TLS_CACERT      /etc/openldap/domain.crt

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

The option TLS_REQCERT never seems to disable the certificate check. You can see the option #TLS_CACERT /etc/openldap/domain.crt. This option specifies the root certificate to check against. It was used in the issue where I pasted this file from but I commented it out. I think its not needed here. Seems to work without it. Note: This is a workaround a not a long term solution

Long Term Solution

I would recommend to add support for a option LDAP_CACERT to the .env file. So you can specify the root CA. Maybe add a LDAP_INSECURE option as well?

[BeateLerch]

Thank you Hannes for this workaround. I might try this in the future just to verify. However, this was not what I did just yesterday evening. Since I could not get the docker container to work, I did a non-docker-install, and having just the same problem there, I turned on debug mode and crawled my way forward through the log- and scriptfiles. It seemed that the bind process was not what our domain (running version 2016, by the way) expected and thus returned authentication errors and later even unspecific errors. Since another ldap-test-php file running on the very same apache had no problems, i suspected the ldap.php file to have some glitch.

After changing one command in ldap.php and adding two variables to config.php it works now.

Added variables: public $ldapUri = 'ldaps://myDomainServerHere:636'; public $ldapDomain = 'myDomainName';

Change for ldap.php line 144. Whatever the @ does to the command, in my testfile that did the trick so I tried here as well and "et voilà". $bind = @ldap_bind($this->ldapConnection, $usernameDN, $passwordBind);

Please could this be investigated further by the developer team?

[MIPMHannes]

Sorry I did not realize I was this off topic with my suggestion.

Whatever the @ does to the command, in my testfile that did the trick so I tried here as well and "et voilà".

@ seems to silence the error, see here. So it still fails but it does so silently. If my understanding is correct then this does not seem like a good fix to this problem 😃

[BeateLerch]

Ah, not so far off. Certificates would have been my first guess too, and is is important that those are taken care of as well. The other thing... okay, well, since the script walks on and then binds/authenticates nicely with the next command, just using a slightly different syntax, i have not really a problem with that.