Auth: AD auth broken >v0.6.2 #351
Comments
IncandescentChrysalis
added
status/triage
kapybro
bot
added
status/triage/manual
Haarolean
changed the title
|
Hi, you're missing two essential properties: Can you try it with the suggested properties? |
|
Further user feedback is requested. Please reply within 7 days or we might close the issue. |
|
I tried with those. Here is what I got: I N-checked the password which is the one working in On a side note, I saw those environment variables in https://github.com/kafbat/kafka-ui/blob/main/documentation/compose/ui-ldap.yaml, but is there other documentation about them? |
|
Thanks for the additional feedback! We'll get back to your issue soon. |
|
As this issue is exclusively AD related and is not affecting LDAP, reproducing it becomes quite complicated, as we don't have any AD set up. Let's try to find the exact commit which breaks this for you. Could you try these two? Let me know if it works with the first one and doesn't with the latter. |
|
Further user feedback is requested. Please reply within 7 days or we might close the issue. |
|
Something is worth mentioning about the two supplemental headers you indicated to me:
Using them on our image compiled from I tested both:
with and without those extra headers, and authentication failed everytime. |
|
Thanks for the additional feedback! We'll get back to your issue soon. |
|
This makes little to no sense honestly. But having both not working makes no sense, even less does the fact that adding properties required to make AD work it make it worse in your case. As setting up AD for debugging purposes is virtually impossible, and adding the fact that this is the first time I'm receiving such a report, we'd need either a test AD server provided to understand which changes might've affected it (if any) and/or other user reports on this matter. I'm putting this on hold until we get at least one of those. Please let me know if there's anything else I could do here. |
Haarolean
added
scope/backend
|
It might simply come down to the fact that the two environment variables you indicated to me are improperly configured on my end. I wrote earlier what I thought they should contain, based on guess work from their name only. The only other mention which would serve the purpose of docs in the codebase I found was a Docker Compose definition, not very verbose in itself. What strikes me most is that they are breaking the Considering this issue is on hold, I will send that matter further in our backlog too. |
|
One more case of AD auth broken after 0.6.2 |
|
Hey, I am struggling here, what's the correct configuration for 0.7.2 provectus kafka-ui for AD? oauth2:
ldap:
activeDirectory: false
activeDirectory.domain: my.domain.net
is this section correct do i miss something? the ldaps connection is in spring:
ldap:
urls: "ldaps://x.my.domain.net
... |
|
@Haarolean I got a solution for you! I can reproduce the problem with it:
|
|
To be crystal clear, authentication works in I found the commit breaking authentication between Several things are being done there:
The first item is important: as shown in my previous comment, despite interacting with an Active Directory instance, th protocol being used is LDAP. I am still fiddling with the details of the breaking commit, trying to understand what exactly broke things. If your expert eyes see something obvious to you, that could greatly speed things up! |
|
I found out why my LDAP authentication was now failing. Up to @Value("${spring.ldap.userFilter.searchBase:#{null}}")
private String userFilterSearchBase;
@Value("${spring.ldap.userFilter.searchFilter:#{null}}")
private String userFilterSearchFilter;meaning the corresponding environment variables were: SPRING_LDAP_USERFILTER_SEARCHBASE
SPRING_LDAP_USERFILTER_SEARCHFILTERStarting with @ConfigurationProperties("spring.ldap")
@Data
public class LdapProperties {
[…]
private String userFilterSearchBase;
private String userFilterSearchFilter;meaning the corresponding environment variables are: SPRING_LDAP_USERFILTERSEARCHBASE
SPRING_LDAP_USERFILTERSEARCHFILTERThose breaking changes were not documented in the As per the actual Active Directory configuration, refer to @tdudlak4918ab's question: so far I have never used RBAC. |
not really, taking spring boot's relaxed binding rules into consideration, both variants are equal. We have this LDAP compose which works perfectly fine. I'll take a look at your example repo once I get some spare time for this, thank you. |
|
@IncandescentChrysalis I couldn't quite run your compose on arm64 host: is that fixable or should I get an amd64 machine for this? |
I would kindly suggest to put the theory to the test (o: I confirm what I wrote in my comment, all my tests concur on that, and I even spent a lot of time debugging the code on the commit breaking the behaviour: those variables are not defined post-change. The configuration environment variables syntax change I highlighted (haven't tested the configuration file approach) is mandatory > It seems maybe the I only managed to make the commit working on the old configuration syntax by modifying the |
Make sure to have a Docker environment matching your kernel/architecture. |
|
I testes futher with This works indeed per the example you provided: SPRING_LDAP_USER_FILTER_SEARCH_BASE
SPRING_LDAP_USER_FILTER_SEARCH_FILTERAs stated before, this too: SPRING_LDAP_USERFILTERSEARCHBASE
SPRING_LDAP_USERFILTERSEARCHFILTERBut I confirm this does not: SPRING_LDAP_USERFILTER_SEARCHBASE
SPRING_LDAP_USERFILTER_SEARCHFILTERI am no pro at Spring nor its magic, so I'll leave you to understand what the Hell is going on 🤣 If you are interested, I know what code change could be done to support that <= |
|
Seems like the unexpected changes have been discussed here previously. Regarding the documentation:
|
Can you elaborate? I'm running the compose you provided which is built locally (for the ad part), so there's no image architecture to match. |
Issue submitter TODO list
main-labeled docker image and the issue still persists thereDescribe the bug (actual behavior)
As hinted in #254 (comment), LDAP backend towards Active Directory in non-RBAC mode does not seem to work anymore.
The last version this is still effective with the used configuration is
provectus/kafka-ui'sv0.6.2.Expected behavior
LDAP authentication is said to be seperate from RBAC par #254 (comment), and as such should continue working whatever state of implementation RBAC is.
RBAC for Active Directory is considered not implemented as of yet.
Your installation details
Previous test made long ago with Docker image compiled from
provectus/kafka-ui'sv0.7.1Current test made with Docker image compiled from
kafbat/kafka-ui'sv1.0.0Steps to reproduce
Minimal set of environment variables to reproduce:
Screenshots
No response
Logs
Existing session from HTTP authentication is not resumed; those are the logs after filling up the Web auth form:
Additional context
Working logs (
v0.6.2):The text was updated successfully, but these errors were encountered: