Auth: AD auth broken >v0.6.2

[IncandescentChrysalis]

Issue submitter TODO list

• I've looked up my issue in FAQ
• I've searched for an already existing issues here
• I've tried running main-labeled docker image and the issue still persists there
• I'm running a supported version of the application which is listed here

Describe 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's v0.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's v0.7.1
Current test made with Docker image compiled from kafbat/kafka-ui's v1.0.0

Steps to reproduce

Minimal set of environment variables to reproduce:

#LOGGING_LEVEL_ROOT: debug

AUTH_TYPE: "LDAP"
SPRING_LDAP_URLS: "ldaps://<AD URL>"
SPRING_LDAP_ADMINUSER: "CN=<CN>,OU=<OU1>,DC=<DC>"
SPRING_LDAP_ADMINPASSWORD: "<admin password>"

SPRING_LDAP_USERFILTER_SEARCHBASE: "OU=<OU2>,DC=<DC>"
SPRING_LDAP_USERFILTER_SEARCHFILTER: "<AD filter>"

Screenshots

No response

Logs

Existing session from HTTP authentication is not resumed; those are the logs after filling up the Web auth form:

kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:39:52,977 DEBUG [reactor-http-epoll-4] o.s.h.c.FormHttpMessageReader: [613b0092-5] Read form fields [username, password] (content masked)
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:39:52,982 DEBUG [boundedElastic-1] o.s.s.l.a.BindAuthenticator: Failed to bind with any user DNs []
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:39:52,991 DEBUG [boundedElastic-1] o.s.s.w.s.a.AuthenticationWebFilter: Authentication failed: Les identifications sont erronées
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:39:52,992 DEBUG [boundedElastic-1] o.s.s.w.s.DefaultServerRedirectStrategy: Redirecting to '<path>/login?error'

Additional context

Working logs (v0.6.2):

kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,381 DEBUG [boundedElastic-2] o.s.s.l.a.BindAuthenticator: Failed to bind with any user DNs []
[…]
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,580 DEBUG [boundedElastic-2] o.s.l.c.s.AbstractContextSource: Got Ldap context on server 'ldaps://<AD>'
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,621 DEBUG [boundedElastic-2] o.s.s.l.SpringSecurityLdapTemplate: Found DN: CN=<CN>,OU=<OU>,DC=<DC>
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,623 DEBUG [boundedElastic-2] o.s.s.l.s.FilterBasedLdapUserSearch: Found user '<user>', with FilterBasedLdapUserSearch [searchFilter=<AD filter>; searchBase=OU=<OU>,DC=<DC>; scope=subtree; searchTimeLimit=0; derefLinkFlag=false ]
[…]
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,860 DEBUG [boundedElastic-2] o.s.l.c.s.AbstractContextSource: Got Ldap context on server 'ldaps://<AD>'
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,861 DEBUG [boundedElastic-2] o.s.s.l.a.BindAuthenticator: Bound cn=<CN>,ou=<OU>,dc=<DC>
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,862 DEBUG [boundedElastic-2] o.s.s.l.u.LdapUserDetailsMapper: Mapping user details from context with DN cn=<CN>,ou=<OU>,dc=<DC>
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-06 07:33:46,862 DEBUG [boundedElastic-2] o.s.s.l.a.LdapAuthenticationProvider: Authenticated user

[Haarolean]

Hi, you're missing two essential properties:

     OAUTH2.LDAP.ACTIVEDIRECTORY: true
     OAUTH2.LDAP.ACTIVEDIRECTORY.DOMAIN: "memelord.lol"

Can you try it with the suggested properties?

[kapybro]

Further user feedback is requested. Please reply within 7 days or we might close the issue.

[IncandescentChrysalis]

I tried with those.
By domain, I suppose you meant the capitalised name of the AD notion, no the domain name used as combination of DC

Here is what I got:

kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,334 DEBUG [Thread-9] j.e.security: X509Certificate: Alg:SHA256withRSA, […], Cert Id:334072978,  […]
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,335 DEBUG [Thread-9] j.e.security: X509Certificate: Alg:SHA256withRSA, […], Cert Id:-996611390, […]
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,340 DEBUG [Thread-9] j.e.security: ValidationChain: 1128928943, -996611390
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,345 DEBUG [Thread-9] j.e.security:  TLSHandshake: <AD>:636, TLSv1.3, TLS_AES_256_GCM_SHA384, -996611390
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,497 DEBUG [boundedElastic-1] o.s.s.l.a.a.ActiveDirectoryLdapAuthenticationProvider: Authentication for <user>@@null failed:javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09050E, comment: AcceptSecurityContext error, data 52e, v4f7c]
kafka-ui-config_kube-kafka-ui-demo-1  | 2024-05-07 15:03:47,499 INFO  [boundedElastic-1] o.s.s.l.a.a.ActiveDirectoryLdapAuthenticationProvider: Active Directory authentication failed: Supplied password was invalid

I N-checked the password which is the one working in v0.6.2

---

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?

[kapybro]

Thanks for the additional feedback! We'll get back to your issue soon.

[Haarolean]

@IncandescentChrysalis

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?
provectuslabs/kafka-ui:541e4018ec251ea371fd64b198b916b9fd198d99
provectuslabs/kafka-ui:744bdb32a310306eefe8641923d712db697b1c70

Let me know if it works with the first one and doesn't with the latter.

[kapybro]

Further user feedback is requested. Please reply within 7 days or we might close the issue.

[IncandescentChrysalis]

Something is worth mentioning about the two supplemental headers you indicated to me:

• OAUTH2.LDAP.ACTIVEDIRECTORY
• OAUTH2.LDAP.ACTIVEDIRECTORY.DOMAIN

Using them on our image compiled from provectus/kafka-ui v0.6.2 breaks authentication. It is working without them.
Are you sure about those?

---

I tested both:

• provectuslabs/kafka-ui:541e4018ec251ea371fd64b198b916b9fd198d99
• provectuslabs/kafka-ui:744bdb32a310306eefe8641923d712db697b1c70

with and without those extra headers, and authentication failed everytime.

[kapybro]

Thanks for the additional feedback! We'll get back to your issue soon.

[Haarolean]

This makes little to no sense honestly.
541e4018ec251ea371fd64b198b916b9fd198d99 dates back to this issue, where the changes have been tested by the other users and it's confirmed that it did work back then.
744bdb32a310306eefe8641923d712db697b1c70, on the other hand, dates back to this issue, which is about supporting LDAP in RBAC. This is one of the only PRs that could affect this and it was my best guess.

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.

[IncandescentChrysalis]

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.
Maybe more insights on what is expected there could help.

What strikes me most is that they are breaking the 0.6.2 provectus/kafka-ui, otherwise working, environment.
I suppose it is not, but is this expected?

---

Considering this issue is on hold, I will send that matter further in our backlog too.