mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-06 09:09:38 +03:00
LDAP Authentication doesn't work #1521
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 @eferreira2 on GitHub (Feb 6, 2020).
Originally assigned to: @ssddanbrown on GitHub.
Running Ubuntu 18.04 on PHP version 7.2.24. Bookstack version is v0.28.
I've been trying to get LDAP authentication working for a few hours now.
I keep getting this error:
Argument 1 passed to BookStack\Auth\Access\LdapService::validateUserCredentials() must be of the type array, null given, called in /var/www/bookstack/app/Auth/Access/Guards/LdapSessionGuard.php on line 73This is what's in my .env file
@FreeTheTech101 commented on GitHub (Feb 6, 2020):
At a quick glance, I would place my bet on the LDAP_DN being incorrect. For that field, you need to use the common name of the user, followed by the organizational unit, then finally the domain. Based on the provided configuration, the line should look like the following:
LDAP_DN="CN=administrator,OU=My OU,DC=COMPANY,DC=com@eferreira2 commented on GitHub (Feb 6, 2020):
Tried adjusting my LDAP_DN which unfortunately had no effect whatsoever.
I also tried emulating this setup which did not work either:
https://mangolassi.it/topic/19780/configuring-bookstack-to-use-ldap/6
@FreeTheTech101 commented on GitHub (Feb 6, 2020):
Hm, that is a bit of an odd one. Just for reference I have attached a screenshot of the settings that I am using. This is for an AD enviroment, with LDAPS.
Instead of using an IP address, I used the FQDL. Hopefully that might help get the ball rolling.
@eferreira2 commented on GitHub (Feb 6, 2020):
I'm 100% confident that I have the correct BASE_DN and LDAP_DN. I've pulled these through dsquery and by looking at AD advanced attribute editor. I applied the other settings identically to the way you have it. Still same exact error.
Screenshots attached.
@lpar commented on GitHub (Feb 12, 2020):
In case it helps, LDAP works for me, settings:
@eferreira2 commented on GitHub (Feb 13, 2020):
Thanks, I tried those settings and still get the same error listed in the initial post. It's clearly a bug of some kind. I can't think of any other explanation after troubleshooting for 6+ hours.
@lpar commented on GitHub (Feb 13, 2020):
Well, based on your original settings and the presence of
sAMAccountNameI'm guessing your LDAP server is Microsoft Active Directory, yes? From the error message, the thing that's failing is that$userDetailsisn't an array, which suggests that the lookup isn't working at all.Can you try using (say) OpenLDAP to query the server? e.g.
If that fails for lack of authentication, add
-b administrator@domain.com -w passwordto the arguments before the final search argument, and see if that helps. Once you can perform the query successfully using OpenLDAP and dump out an example record it'll be much easier to work out what settings you need for BookStack.@eferreira2 commented on GitHub (Feb 13, 2020):
This works:
ldapsearch -x -H ldaps://[IPADDRESS]:636/ -b "OU=Admin,OU=Staff,DC=DOMAIN,DC=com"(sAMAccountName=mylogin)" -w 'password' -D 'administrator@domain.com'
Here's the edited result:
extended LDIF
LDAPv3
base <OU=Admin,OU=Staff,DC=DOMAIN,DC=com> with scope subtree
filter: (sAMAccountName=mylogin)
requesting: ALL
dn: CN=ME,OU=Admin,OU=Staff,DC=DOMAIN,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: My Name
sn: My Last Name
givenName: Me
distinguishedName: CN=My Name,OU=Admin,OU=Staff,DC=DOMAIN,DC=com
instanceType: 4
whenCreated: 20190108180627.0Z
whenChanged: 20200213033339.0Z
displayName: My Name
uSNCreated: 22519421
uSNChanged: 44790694
mDBUseDefaults: TRUE
mailNickname: mylogin
name: My Name
objectGUID:: [guid]
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 132254777907635326
lastLogoff: 0
lastLogon: 132260855764829396
pwdLastSet: 132253235342020866
primaryGroupID: 513
objectSid:: [sid]
adminCount: 1
accountExpires: 9223372036854775807
logonCount: 3530
sAMAccountName: mylogin
sAMAccountType: 805306368
userPrincipalName: mylogin@DOMAIN.COM
lockoutTime: 0
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=DOMAIN,DC=com
dSCorePropagationData: 20190528162504.0Z
dSCorePropagationData: 20190108185748.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 132260384197130507
mail: mylogin@domain.com
search result
search: 2
result: 0 Success
numResponses: 2
numEntries: 1
@lpar commented on GitHub (Feb 13, 2020):
Based on that, I would expect your original settings to work, so I'm afraid I'm out of ideas. My next step would be to hack on the source code and make LdapSessionGuard.php dump the contents of its local variables to a log file before it gets to line 73, to see what it's seeing that's different.
@ssddanbrown commented on GitHub (Feb 15, 2020):
@FreeTheTech101 @lpar Thank you both for trying to help on this issue.
@eferreira2 I've had a look and I can confirm there's a bug where I've made some of the function parameters more strict in the latest release. I've assigned this to the next bugfix release to fix that.
From what I can see, and from my testing, this issue will occur when BookStack cannot find anyone matching the user search. I think BookStack is connecting to your LDAP instance okay, it's just not locating any users in the search. Points towards invalid username being used on login or an issue with the
LDAP_USER_FILTER.Note, #1872 is currently also open (To also be addressed in next bugfix release) which could introduce issues around the
LDAP_ID_ATTRIBUTEin AD.@ssddanbrown commented on GitHub (Feb 16, 2020):
Okay, It's now worth updating to v0.28.2. The initial issue should now be sorted and support has been added for LDAP_ID_ATTRIBUTE. You'll likely need to use the follow LDAP_ID_ATTRIBUTE option:
(Due to how AD provides the value for this field in binary)
I suspect logins may still fail but instead with a friendlier "These credentials do not match our records." message. Let me know how it goes.
@ssddanbrown commented on GitHub (Mar 5, 2020):
Since there's been no response to the above 'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one, along with the up-to-date state of the issue.
@BenLangers commented on GitHub (May 31, 2020):
Hello!
I'm having the message "These credentials do not match our records." you describe above with an LDAP setup to Active Directory. Could this be the same issue? This was installed today with the latest stable build.
I'm using username@domain.tld for LDAP_DN, with the full DN I get an error about this variable when trying to log on. Is the LDAP conversation logged somewhere?
@twicechild commented on GitHub (Dec 11, 2020):
Hello!
I leave this here just for future reference.
I had the same problem with the "These credentials do not match our records." message just after "moving" my docker container to a new server. It seems that for my AD having the following worked:
LDAP_USER_FILTER=(&(memberOf=cn=group,ou=ou1,ou=ou2,dc=domain,dc=domain))I previously had added the
(&(sAMAccountName=${user}))before member of but I couldn't login!Hope this helps!
@ssddanbrown commented on GitHub (Dec 12, 2020):
@twicechild I'd have thought that now, with that user_filter, only one account can log-in (The first it finds within that group). Cant' see that working for multi-user setups.