mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
LDAP over SSL not working - ldap_bind(): Unable to bind to server: Can't contact LDAP server #1559
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @joaomezzari on GitHub (Feb 27, 2020).
Describe the bug
LDAP authentication when using LDAPS is not working. I get this error:
Already added the CA to the trust store on the server. LDAP configs:
General auth
AUTH_METHOD=ldap
LDAP_SERVER=ldaps://dc02-srv2016.ad.mydomain.com:636
LDAP_BASE_DN=DC=ad,DC=mydomain,DC=com
LDAP_DN=bookstack.connector@domain...
LDAP_PASS=mypasshere
LDAP_USER_FILTER=(&(sAMAccountName=${user}))
LDAP_VERSION=3
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_DISPLAY_NAME_ATTRIBUTE=cn
LDAP_ID_ATTRIBUTE=BIN;objectGUID
APP_DEBUG=true
If I change to ldap and port 389, it works perfectly... any ideas?
@ssddanbrown commented on GitHub (Feb 28, 2020):
@joaomezzari Is the certificate self-signed?
You can try adding:
to your
.envwhich opens BookStack to allow un-trusted certificates.@joaomezzari commented on GitHub (Feb 28, 2020):
@ssddanbrown Yes, the certificate is self-signed. Edited the .env file with the parameter but I'm still getting the same result.
@ssddanbrown commented on GitHub (Feb 28, 2020):
Ah, Damn. I'm a bit in the dark myself here since I don't have an LDAPS server to test with.
Are you able to connect from the BookStack system to the LDAPS server via another tool, Like directly on the command line? Just to ensure that port isn't blocked somewhere for all?
@joaomezzari commented on GitHub (Feb 28, 2020):
I use other applications with LDAPS aswell. Just tested the connection from the server to be sure and it's ok aswell. I'm kinda lost too, I don't know if other people are having issues since LDAPS is not that commonly used.
@joaomezzari commented on GitHub (Feb 28, 2020):
I'm using Active Directory btw
@ssddanbrown commented on GitHub (Feb 28, 2020):
This might be due to how PHP can be a bit awkward with providing the connection details.
Could you find this line:
01b95d91ba/app/Auth/Access/LdapService.php (L197)(Line 197 in app/Auth/Access/LdapService.php)
and update it to the following:
and see if that helps?
@kanlas-net commented on GitHub (Feb 28, 2020):
@joaomezzari try adding to /etc/openldap/ldap.conf this line:
TLS_REQCERT neverThis will turn off certificate validation by openldap
You can also use self-signed certs with validation by adding TLS_CACERT directive with path to domain ca cert file (requires system reboot) like this:
TLS_CACERT /etc/openldap/certs/domain.crtI have tried this with centos 7 and it works
@joaomezzari commented on GitHub (Feb 28, 2020):
@ssddanbrown Updated it as you suggested, getting this error now:
Symfony\Component\Debug\Exception\FatalThrowableError
Too few arguments to function BookStack\Auth\Access\Ldap::connect(), 1 passed in /var/www/bookstack/app/Auth/Access/LdapService.php on line 197 and exactly 2 expected
@joaomezzari commented on GitHub (Feb 28, 2020):
I already have this in my file: TLS_CACERT /etc/openldap/certs/domain.crt
Already tried with the
TLS_REQCERT neveranswell, same error that it can't contact the ldap server.@kanlas-net commented on GitHub (Feb 28, 2020):
@joaomezzari Oh, sorry, I misread this. What distro do you use?
Can you try to change
LDAP_DN=bookstack.connector@domainto distinguished name? I mean something likeLDAP_DN=cn=bookstack.connector,ou=users,dc=mydomain,dc=com@joaomezzari commented on GitHub (Feb 28, 2020):
@kanlas-net Ubuntu 1804. If I change the LDAP_DN to the DN instead of the UPN, Bookstack for some reason won't even load...
@kanlas-net commented on GitHub (Feb 28, 2020):
@joaomezzari this is strange... In my configuration only DN works. Maybe this is because you have dot in username? LDAP does not have issues with dots by itseft, but maybe there is some parsing problem at php backend side.
@joaomezzari commented on GitHub (Feb 28, 2020):
For me, it only works with the UPN. The configs are working with LDAP in plain text, so I don't think the issue is really in the ``LDAP_DN
parameter... I could be wrong tho.@joaomezzari commented on GitHub (Mar 2, 2020):
Any other clue?
@homotechsual commented on GitHub (Mar 2, 2020):
Anything in your logs (see:
storage/logs/*)?@joaomezzari commented on GitHub (Mar 2, 2020):
Same error displayed on the web page
production.ERROR: ldap_bind(): Unable to bind to server: Can't contact LDAP server {"exception":"[object] (ErrorException(code: 0): ldap_bind(): Unable to bind to server: Can't contact LDAP server at /var/www/bookstack/app/Auth/Access/Ldap.php:93)@homotechsual commented on GitHub (Mar 2, 2020):
Can you manually contact the LDAP server over LDAPS from the hosting server?
@joaomezzari commented on GitHub (Mar 2, 2020):
Yes
@homotechsual commented on GitHub (Mar 2, 2020):
If you don't mind "tinkering under the hood" adding
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);beforereturn ldap_connect($hostName, $port);in ldap.php might give you a more verbose PHP/LDAP debug error to go off.@joaomezzari commented on GitHub (Mar 2, 2020):
Added the line, still getting the same error in the logs...
@homotechsual commented on GitHub (Mar 2, 2020):
Anything in your main PHP logs - sorry should have been clearer that the LDAP debug should give you output to PHP logs not the application logs.
@joaomezzari commented on GitHub (Mar 2, 2020):
Not sure I'm actually checking the correct file, but php7.4-fpm.log.1 on /var/log has nothing about ldap
@homotechsual commented on GitHub (Mar 2, 2020):
I would expect it to be php-fpm.log - the numbered versions are the old logs.
@joaomezzari commented on GitHub (Mar 2, 2020):
Whoops, sorry, I copied the name from the wrong file. Looks like the log is empty tbh. This is the only content:
NOTICE: error log file re-opened@homotechsual commented on GitHub (Mar 2, 2020):
Apache or Nginx?
@joaomezzari commented on GitHub (Mar 2, 2020):
Nginx
@homotechsual commented on GitHub (Mar 2, 2020):
Nginx error logs? (
/var/log/nginx)@joaomezzari commented on GitHub (Mar 2, 2020):
It's empty...
@homotechsual commented on GitHub (Mar 2, 2020):
I can try and reproduce/play with this on my side if it's helpful? What kind of LDAPS server are you using and can you provide some more info on your setup/config?
@joaomezzari commented on GitHub (Mar 2, 2020):
Yes, that would be helpful. I'm using AD... not much to add I guess. Using Ubuntu 16.04, installed BookStack using the install script. As I said, if I change for LDAP on port 389, everything works like a charm. I added the CA to the trust store aswell.
@homotechsual commented on GitHub (Mar 2, 2020):
I'll give this a go later this week. Away for a couple of days but then have some time!
@joaomezzari commented on GitHub (Mar 2, 2020):
Thank you very much, really appreciate your help so far =)
@ssddanbrown commented on GitHub (Mar 2, 2020):
@joaomezzari I've just pushed a branch named
ldaps_1922to hopefully fix this. It's off of thereleasebranch so can should be able to just check it out and test.Can you do a
git fetchand agit checkout ldaps_1922then see if that fixes this? Should work with your original config and file state.@joaomezzari commented on GitHub (Mar 2, 2020):
@ssddanbrown I tried but I'm getting
error: pathspec 'ldaps_1922' did not match any file(s) known to git.@ssddanbrown commented on GitHub (Mar 2, 2020):
Damn, git repo is in
--single-branchmode from the install.@joaomezzari You could try the following in order:
@homotechsual commented on GitHub (Mar 2, 2020):
You can also undo the
--single-branchmode entirely:https://stackoverflow.com/questions/17714159/how-do-i-undo-a-single-branch-clone
@joaomezzari commented on GitHub (Mar 2, 2020):
Ok, I created a new test environment from scratch to test it. Still getting the same error in branch
ldaps_1922. I didn't add the cert to the trust store this time, but I edited the .env and added theLDAP_TLS_INSECURE=trueparameter just in case, but seems that it's not working...@joaomezzari commented on GitHub (Mar 9, 2020):
@MikeyMJCO Hey, just checking if you were able to reproduce the possible issue in your environment
@homotechsual commented on GitHub (Mar 9, 2020):
Hey :-)
Haven't been able to reproduce this despite trying a couple of times. Running a new test with the updated branch now - just for the sake of completeness.
@joaomezzari commented on GitHub (Mar 9, 2020):
So, that means that it's working for you?
@homotechsual commented on GitHub (Mar 10, 2020):
So I think I'm narrowing this down - I can reproduce reliably now.
Looks like using the LDAPS and port 636 is what's causing the issue.
That's an LDAP over SSL connection - not supported by Active Directory (not part of the LDAP standard either!)
We should be doing LDAP to port 389 and issuing an
[ldap_start_tls()](https://www.php.net/manual/en/function.ldap-start-tls.php)call for the connection to switch to TLS, Then issuing the bind command and authenticating.@joaomezzari commented on GitHub (Mar 10, 2020):
I'm pretty sure AD supports LDAPS on port 636, especially because I use it on other applications... I'm 100% sure about this.
We should be doing LDAP to port 389 and issuing an [ldap_start_tls()](https://www.php.net/manual/en/function.ldap-start-tls.php) call for the connection to switch to TLS, Then issuing the bind command and authenticating.That works too, some apps actually only support this. Seems like BookStack is the case?
@homotechsual commented on GitHub (Mar 10, 2020):
Have you configured the certificate etc for LDAPS on your Domain Controller?
@joaomezzari commented on GitHub (Mar 10, 2020):
Yes, otherwise, it wouldn't work. LDAPS is not standard on AD environment.
@FreeTheTech101 commented on GitHub (Apr 28, 2020):
Just out of curiosity, have you used IISCrypto or otherwise changed the cipher suite on your DC? It seems that this error will occur if at least one of the following ciphers are not enabled:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
If you are unsure, you are best to either use Wireshark to see if it is negotiating a TLSv1 session, as well as checking the event viewer for schannel related issues.
The only reason I am suggesting this is I had this exact issue for the last two days, and this was the solution I was able to come up with to get things working again.
@llawwehttam commented on GitHub (Jun 8, 2020):
I am experiencing exactly the same issue in my environment when attempting to set up BookStackApp with LDAPS against a Windows Server 2016 domain controller.
In my environment the cipher suite has not been changed on the DC in any way.
I successfully have LibreNMS and Netbox both authenticating against the DC via LDAPS.
BookStackApp will work but only when using plan LDAP on port 389 which we cannot do for compliance reasons.
I am able to use ldapsearch from the commandline of the BookStackApp server with no problems so suspect this is occurring somewhere within the application.
@ghost commented on GitHub (Dec 27, 2020):
@llawwehttam and @joaomezzari I had the same problem and after I enabled debugging on domain controller with command nltest /dbflag:FFFFFFFF and tried to login it started working for some reason. I have disable logging with nltest /dbflag:0x0 and it still works. Right now I have LDAP_TLS_INSECURE=true but I will fix that later. With the same config it did not work before so I really have no idea how enabling debugging did anything here. If anyone has a clue let me know. I would like to know.
File C:\Windows\debug\netlogon.log
12/27 01:31:44 [LOGON] [1904] domain: SamLogon: Network logon of example\bookstack from DC01 Entered
12/27 01:31:44 [LOGON] [1904] domain: SamLogon: Network logon of example\bookstack from DC01 Returns 0x0
Source how to enable debugging:
https://www.windowstechno.com/how-to-enable-netlogon-debugging-log-for-domain-controller/
@jbuenomagdalena commented on GitHub (Jan 20, 2021):
@llawwehttam and @joaomezzari I had the same problem but i have found a bug reported (https://gist.github.com/aderixon/01ee459155a5f51264cb0f029c4b6f87) in the version of PHP used in the script for installing BookStackApp that cause intermittent problems with PHP LDAP against a TLS connection using a self-signed server certificate.
I have filled openssl.cafile in php.ini and this doesn´t work, i think is the problem you are describing. I am using PHP-FPM too.
In order to solve we need to set CA file path directly in the OS, for example (testing in CentOS 8, 7 should be the same and other Linux flavours similar)
- Openldap client config:
Edit file /etc/openldap/ldap.conf
Add / change
- OS settings (best practices)
By last restart httpd and php-fpm services.
I hope this is useful.
@ssddanbrown commented on GitHub (Jun 15, 2021):
Thanks to all that have provided their thoughts and/or findings. Since there's not been any further recent activity on this I'll close it off.