WIP: Trying to make LDAP login search subtrees for accounts to log into#11041
WIP: Trying to make LDAP login search subtrees for accounts to log into#11041uberbrady wants to merge 2 commits intogrokability:developfrom
Conversation
|
Ok, I've now added a setting - default-on - that will append the "," and the baseDN - which is classically how Snipe-IT has worked in the past. Anyone who's doing this subtree login business will probably want to turn that off, I figure? |
snipe
added
🆘 testers-needed
|
I should make sure to take into considerations the changes in #11303 - that affects some LDAP stuff and I want to make sure this reflects those. Hopefully they'll come up in the conflict-hell that I expect will result. |
|
Are we still going in this direction? Should we merge or close? |
|
Yes, this is still a going concern and still affects some of our users. I'll see if there's some way to get it out of WIP. |
|
This comment is really interesting: #9903 (comment) - and I am wondering if we can just do that small change and leave out the other stuff - like, would that work for everyone, or is that just for OpenLDAP people? Maybe I'm being too over-cautious here. |
|
@uberbrady Are we still looking to work on this or should it be closed? |
|
@uberbrady is this still relevant? |
|
I'm happier with how I implemented this same functionality here: #17832 - so I'll close this one. |
2 participants
Possible fix for #9903 - allowing logins to access the entire subtree.
Since we already do a query to grab the attributes for the user in question, but we do so after we have bound as that user, we can flip that around, and do a search first, and then do the 'bind', as that found user, and that should work.
As I was thinking about it, I figured that I might be able to do this as just one change that modifies how the current system works. But I think it's going to break too many people - way too many - and is going to set our helpdesk (and GitHub) on fire. So I'm probably going to have to add that "Classic-vs-Subtree" mode-switch in there somewhere, anyways. I hate that, because I hate to hold on to that bit of complexity - but I also don't want to break existing, working configs.
But, regardless, if you want to see what the subtree logic might look like, this would be it.
Lots of
TODOandFIXMEand tons of debugging that I should rip out, and definitely a few unanswered questions that I should probably handle, too. But, this is what I got so far. Just would love some eyes on this to see if it possibly handles some use cases that are out there.