mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
LDAP over TLS: Unable to bind to server: Can't contact LDAP server #990
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 @Mant1kor on GitHub (Jan 15, 2019).
Describe the bug
Login via Active Directory account.
Sometimes I've got error:
ldap_bind(): Unable to bind to server: Can't contact LDAP serverScreenshots
Your Configuration (please complete the following information):
Additional context
.envoptionsAD level: 2008 R2
@Mant1kor commented on GitHub (Jan 15, 2019):
Update: the issue reproduce only when connected to LDAP_SERVER over TLS
LDAP_SERVER=ldaps://dc.domain.com:636
@ssddanbrown commented on GitHub (Jan 15, 2019):
Sorry to hear you're having issues @Mant1kor,
Just to confirm is this a new BookStack/Ldap setup you're experiencing this on or are you just experiencing this after performing an update?
Does this mean it sometimes does work as expected, without error?
@Mant1kor commented on GitHub (Jan 15, 2019):
It's a new BookStack/Ldap setup.
Yep, error occurs in ~50% of attempts. I'll try to record video proof.
@Mant1kor commented on GitHub (Jan 15, 2019):
Looks like that's solve my problem:
LDAP_USER_FILTER=(&(objectCategory=Person)(sAMAccountName=${user}))Give me a ~day to check in detail.
@Mant1kor commented on GitHub (Jan 16, 2019):
@ssddanbrown still something wrong with ldap auth
@ssddanbrown commented on GitHub (Jan 16, 2019):
This sounds very similar to #1069 and perhaps #247.
If I'm honest, I'm not really sure how to diagnose such an issue.
@Mant1kor commented on GitHub (Jan 16, 2019):
I'm not a specialist, but some people(googled) recommends to use ldap_start_tls() instead of ldap_bind()
It's not critical, I'll use ldap:// to avoid the problem.
And I remind you again: the issue reproduce only with ldaps://
@FreeTheTech101 commented on GitHub (Jan 17, 2019):
I personally believe there is something going wrong with verified LDAPS. Despite enabling trust my personal CA, I still encountered this issue. The "temporary" work around which I ended up using (which I cannot solely recommend) is changing the following lines:
to
@cenix102 commented on GitHub (Jan 21, 2019):
Hello to everyone!
I have the same problem. Maybe my configuration is wrong or something else. (PS: I tried the configuration from this issue).
Config:
AUTH_METHOD=ldap
@Mant1kor commented on GitHub (Jan 21, 2019):
@cenix102 use ldap:// to avoid the problem. And waiting for the fix...
LDAP_SERVER=ldap://172.25.60.10:389And one more thing:
Using admin credentials is not necessary and secure. Use a normal user account.
@cenix102 commented on GitHub (Jan 21, 2019):
@Mant1kor thanks for your answer. Now I have some credential errors...
PS: ldap.admin is just a the name. The user have not admin access. :-)
@christophert commented on GitHub (Feb 6, 2019):
Setting
LDAP_TLS_INSECUREis the equivalentTLS REQCERT neverin/etc/ldap/ldap.conffor the session so this might be unrelated.I personally haven't run in to this issue with our AD infrastructure (2012R2/2016). Are there any log entries in the DC's auth log that indicate authentication failure? What OS is BookStack running on?
@Mant1kor commented on GitHub (Feb 7, 2019):
It's strange, but I can't reproduce the problem any more.
The difference is:
OS: CentOS 7
@Duan-fei commented on GitHub (Mar 12, 2019):
@Mant1kor
I also met this kind of problem, have you solved this problem，Can you help me？
This is my ldap configuration：
@Mant1kor commented on GitHub (Mar 14, 2019):
@Duan-fei
You don't use encryption. Did you get the same error "Can't contact LDAP server"?
@ssddanbrown commented on GitHub (May 18, 2019):
An issue was found in how BookStack handles LDAP URI's. A fix was applied for release v0.26:
c24764018aIf anyone is still experiencing issues it's work updating to the latest release as you may find your issue has been fixed.