LDAP, Debug, and Dumping User Details
TopCheddar27 opened this issue · 7 comments
Hello,
Setting this up in a corporate environment, with Active Directory LDAP. BookStack without LDAP enabled works great. I could simply turn it off, make a couple of account for the users that need access, and be happy. However, I've sunk too much time into LDAP connections with this to just let it go. Maybe I'm just wrong in my assumptions that something is broke.
When enabling ldap, I get the following message:
Note: I took the user out for security purposes.
This is WITH APP_DEBUG=true and LDAP_DUMP_USER_DETAILS=true. Why am I not getting detailed LDAP debug info? On your video for LDAP, you see nice Debug feedback. I see nothing. They are not in the logs presented by "sudo docker logs -f container_name" either.
I have also tried to exec into the container, but there are no logs present in "/var/www/bookstack" anywhere. The logs folder in "/var/www/bookstack/storage/" is also empty. Am I wrong in the assumption that the application does not log in a container?
And this is before even trying to troubleshoot LDAP. I am quite certain everything is correct. I have followed the common docker-compose advice of using a extra "$" in LDAP_USER_FILTER. I know exactly what my LDAP endpoint is, I configure LDAP all the time. My DNs are all solid, got them straight from the attribute editor in AD. Let me know what you think.
relevant sections of docker-compose.yml (details scrubbed):
bookstack:
image: solidnerd/bookstack:latest
depends_on:
- mysql
environment:
- APP_PROXIES=***************
- APP_DEBUG=true
- LDAP_DUMP_USER_DETAILS=true
- DB_HOST=mysql:3306
- DB_DATABASE=***************
- DB_USERNAME=**********
- DB_PASSWORD=***************
- AUTH_METHOD=ldap
- LDAP_SERVER=:389
- LDAP_BASE_DN="CN=BookStack,OU=Users,OU=CH-IT,OU=,OU=,DC=,DC="
- LDAP_DN="CN=bookstack,OU=Service Accounts,DC=****,DC="
- LDAP_PASS="*********"
- LDAP_VERSION=3
- LDAP_THUMBNAIL_ATTRIBUTE=thumbnailPhoto
- LDAP_USER_FILTER=(&(sAMAccountName=$${user}))
Any help would be greatly appreciated. Like I stated before, I have no problem letting this rip without ldap. Just wanted to exhaust all my options before deployment.
Hi @TopCheddar27,
Why am I not getting detailed LDAP debug info? On your video for LDAP, you see nice Debug feedback. I see nothing.
Just an FYI, this project is for a docker image of BookStack, not BookStack itself, so this team don't really have responsibility for the inners works of the LDAP auth, and i'm assuming it was one of my videos that you watched.
BookStack won't dump via that option if it doesn't find anything to dump. I would assuming you're currently not matching against any records in the LDAP system.
If I had to guess at the issue here, it would be the LDAP_BASE_DN value.
It looks very specific right now, and I can't remember if it's an issue if the DN user is not a part of the base DN.
Try moving that up to the OU=,OU=,DC=,DC=" level, at least temporarily, to see if that returns and dumps a match.
Oops. Sorry to the dev (@solidnerd) of this container! Let me know if you would like me to close this, and I can migrate my problem elsewhere.
@ssddanbrown That is the full distinguished name of the Security Group which houses the users. Are you implying that the bookstack service account should be part of the Security group? That would seem kind of irregular no?
Or are you saying that my security group is too deep down the AD tree, and that could be confusing the parsing of the environment variable? I can certainly just migrate the location of the security group up and give that a try. However it seems a bit odd if explicitly stated.
Note that it seems to be editing the LDAP_BASE_DN a bit weird in the comments. Those are fully specified on my end all the way down the chain.
@TopCheddar27 I don't mean to imply anything about your LDAP setup, or mean to advise moving security groups.
Based on you not experiencing other errors, It implies most config is good, including the user DN and password.
It really just leaves, as far as I can think, the LDAP_BASE_DN and LDAP_USER_FILTER vars as things that would affect finding users, So i was starting with the LDAP_BASE_DN since it looks quite long and could be scoping things in.
My recommendation was just to set the LDAP_BASE_DN sting value itself (Not the LDAP group) to a common high point up the chain to rule that out as an issue.
@ssddanbrown Oh okay. I think I misinterpreted. I can try that when I touch the server again for testing!
I've flagged this one as a wontfix, as (as mentioned by @ssddanbrown) this is for the Docker image for Bookstack, not Bookstack itself.
However, I'll leave it open for the time being - from the look of things, there's been some good advice on the thread, and it'd be good to be sure there's no issues with the container's LDAP variables.
This issue has been automatically marked as stale because it has not had any activity for the last 30 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.
Hello,
Just getting back to this. Apologies for letting it go stale.
Using the Parent OU and not using a specified group within a OU fixed this issue.