starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #415] Simple auth fails with Perl LDAP library (Convos.chat) #160

New issue

Closed

opened 2026-02-27 08:15:36 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 08:15:36 +03:00

Owner

Originally created by @poVoq on GitHub (Jan 10, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/415

Hard to say where exactly it fails but I can't get Convos.chat to work with LLDAP.

The support is rather simple, see the LDAP auth plugin documentation here.

It seems like the request is made as I see this in the LLDAP logs:

LDAP session [ 71.8µs | 45.06% / 100.00% ]
2023-01-10T18:00:51.845875506+00:00 INFO     ┕━ LDAP request [ 39.4µs | 54.94% ]

But Convos.chat side it claims the user or password are wrong

I made an very unspecific bug report on the Convos.chat issue tracker but I think neither me or anyone there might have an idea what is going wrong: https://github.com/convos-chat/convos/issues/815

Is there a way to narrow it down further on the LLDAP side? Thanks!

Edit; ah, verbose logging tells a better story (actual user replaced with user@example.com):


2023-01-10T18:13:39.267121011+00:00 INFO     LDAP session [ 110µs | 39.39% / 100.00% ]
2023-01-10T18:13:39.267339254+00:00 INFO     ┕━ LDAP request [ 66.8µs | 52.07% / 60.61% ]
2023-01-10T18:13:39.267349334+00:00 DEBUG       ┝━ 🐛 [debug]:  | msg: LdapMsg { msgid: 8, op: BindRequest(LdapBindRequest { dn: "uid=user,dc=example,dc=com", cred: Simple("********") }), ctrl: [] }
2023-01-10T18:13:39.267352398+00:00 DEBUG       ┝━ do_bind [ 9.41µs | 8.54% ]
2023-01-10T18:13:39.267355679+00:00 DEBUG       │  ┕━ 🐛 [debug]: DN: uid=user,dc=example,dc=com
2023-01-10T18:13:39.267372701+00:00 DEBUG       ┕━ 🐛 [debug]:  | response: BindResponse(LdapBindResponse { res: LdapResult { code: NamingViolation, matcheddn: "", message: "Unexpected DN format. Got \"uid=user,dc=example,dc=com\", expected: \"uid=id,ou=people,dc=example,dc=com\"", referral: [] }, saslcreds: None })

Originally created by @poVoq on GitHub (Jan 10, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/415 Hard to say where exactly it fails but I can't get [Convos.chat](https://convos.chat) to work with LLDAP. The support is rather simple, see the [LDAP auth plugin documentation here](https://convos.chat/doc/Convos/Plugin/Auth/LDAP). It seems like the request is made as I see this in the LLDAP logs: ``` LDAP session [ 71.8µs | 45.06% / 100.00% ] 2023-01-10T18:00:51.845875506+00:00 INFO ┕━ LDAP request [ 39.4µs | 54.94% ] ``` But Convos.chat side it claims the user or password are wrong I made an very unspecific bug report on the Convos.chat issue tracker but I think neither me or anyone there might have an idea what is going wrong: https://github.com/convos-chat/convos/issues/815 Is there a way to narrow it down further on the LLDAP side? Thanks! Edit; ah, verbose logging tells a better story (actual user replaced with `user@example.com`): ``` 2023-01-10T18:13:39.267121011+00:00 INFO LDAP session [ 110µs | 39.39% / 100.00% ] 2023-01-10T18:13:39.267339254+00:00 INFO ┕━ LDAP request [ 66.8µs | 52.07% / 60.61% ] 2023-01-10T18:13:39.267349334+00:00 DEBUG ┝━ 🐛 [debug]: | msg: LdapMsg { msgid: 8, op: BindRequest(LdapBindRequest { dn: "uid=user,dc=example,dc=com", cred: Simple("********") }), ctrl: [] } 2023-01-10T18:13:39.267352398+00:00 DEBUG ┝━ do_bind [ 9.41µs | 8.54% ] 2023-01-10T18:13:39.267355679+00:00 DEBUG │ ┕━ 🐛 [debug]: DN: uid=user,dc=example,dc=com 2023-01-10T18:13:39.267372701+00:00 DEBUG ┕━ 🐛 [debug]: | response: BindResponse(LdapBindResponse { res: LdapResult { code: NamingViolation, matcheddn: "", message: "Unexpected DN format. Got \"uid=user,dc=example,dc=com\", expected: \"uid=id,ou=people,dc=example,dc=com\"", referral: [] }, saslcreds: None }) ```

kerem closed this issue

2026-02-27 08:15:36 +03:00

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 10, 2023):

Sure! Could you run lldap in verbose mode and post the logs?

On Tue, 10 Jan 2023, 19:06 poVoq, @.***> wrote:

Hard to say where exactly it fails but I can't get Convos.chat
https://convos.chat to work with LLDAP.

The support is rather simple, see the LDAP auth plugin documentation here
https://convos.chat/doc/Convos/Plugin/Auth/LDAP.

It seems like the request is made as I see this in the LLDAP logs:

LDAP session [ 71.8µs | 45.06% / 100.00% ]

2023-01-10T18:00:51.845875506+00:00 INFO ┕━ LDAP request [ 39.4µs | 54.94% ]

But Convos.chat side it fails to recognize the user or password.

I made an very unspecific bug report on the Convos.chat issue tracker but
I think neither me or anyone there might have an idea what is going wrong:
convos-chat/convos#815 https://github.com/convos-chat/convos/issues/815

Is there a way to narrow it down further on the LLDAP side? Thanks!

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/415, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWLHSFHPADDZFTGPSATWRWQJDANCNFSM6AAAAAATXDNZOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@nitnelave commented on GitHub (Jan 10, 2023): Sure! Could you run lldap in verbose mode and post the logs? On Tue, 10 Jan 2023, 19:06 poVoq, ***@***.***> wrote: > Hard to say where exactly it fails but I can't get Convos.chat > <https://convos.chat> to work with LLDAP. > > The support is rather simple, see the LDAP auth plugin documentation here > <https://convos.chat/doc/Convos/Plugin/Auth/LDAP>. > > It seems like the request is made as I see this in the LLDAP logs: > > LDAP session [ 71.8µs | 45.06% / 100.00% ] > > 2023-01-10T18:00:51.845875506+00:00 INFO ┕━ LDAP request [ 39.4µs | 54.94% ] > > > But Convos.chat side it fails to recognize the user or password. > > I made an very unspecific bug report on the Convos.chat issue tracker but > I think neither me or anyone there might have an idea what is going wrong: > convos-chat/convos#815 <https://github.com/convos-chat/convos/issues/815> > > Is there a way to narrow it down further on the LLDAP side? Thanks! > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/415>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWLHSFHPADDZFTGPSATWRWQJDANCNFSM6AAAAAATXDNZOI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@poVoq commented on GitHub (Jan 10, 2023):

See my edit above. It looks like it is not passing the ou=people part, but LLDAP requires that?

@poVoq commented on GitHub (Jan 10, 2023): See my edit above. It looks like it is not passing the `ou=people` part, but LLDAP requires that?

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 10, 2023):

Yes, it's required. You should just be able to adjust the CONVOS_AUTH_LDAP_DN variable to add it

@nitnelave commented on GitHub (Jan 10, 2023): Yes, it's required. You should just be able to adjust the CONVOS_AUTH_LDAP_DN variable to add it

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@poVoq commented on GitHub (Jan 10, 2023):

I just tried that via CONVOS_AUTH_LDAP_URL="ldap://localhost:3890?ou=people but the error is the same. I think this might be a bug Convos side in how the login name is converted into a DN.

@poVoq commented on GitHub (Jan 10, 2023): I just tried that via `CONVOS_AUTH_LDAP_URL="ldap://localhost:3890?ou=people` but the error is the same. I think this might be a bug Convos side in how the login name is converted into a DN.

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 10, 2023):

No, not in the URL! :)
You define the pattern with the other variable:
CONVOS_AUTH_LDAP_DN="uid=%uid,dc=%domain,dc=%tld"

You can just replace that with
CONVOS_AUTH_LDAP_DN="uid=%uid,ou=people,dc=%domain,dc=%tld"

On Tue, 10 Jan 2023, 21:34 poVoq, @.***> wrote:

I just tried that via
CONVOS_AUTH_LDAP_URL="ldap://localhost:3890?ou=people but the error is
the same. I think this might be a bug Convos side in how the login name is
converted into a DN.

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/415#issuecomment-1377813864,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWL72CINBGUQQZUY7DTWRXBUJANCNFSM6AAAAAATXDNZOI
.
You are receiving this because you commented.Message ID:
@.***>

@nitnelave commented on GitHub (Jan 10, 2023): No, not in the URL! :) You define the pattern with the other variable: `CONVOS_AUTH_LDAP_DN="uid=%uid,dc=%domain,dc=%tld"` You can just replace that with `CONVOS_AUTH_LDAP_DN="uid=%uid,ou=people,dc=%domain,dc=%tld"` On Tue, 10 Jan 2023, 21:34 poVoq, ***@***.***> wrote: > I just tried that via > CONVOS_AUTH_LDAP_URL="ldap://localhost:3890?ou=people but the error is > the same. I think this might be a bug Convos side in how the login name is > converted into a DN. > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/415#issuecomment-1377813864>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWL72CINBGUQQZUY7DTWRXBUJANCNFSM6AAAAAATXDNZOI> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-02-27 08:15:37 +03:00

Author

Owner

@poVoq commented on GitHub (Jan 10, 2023):

Duh, now I feel stupid.

This seems to mostly work. The login still fails on first try, but since the lldap log said "success" I tried again. Maybe because the Convos account had to be created first.

Ok but looks like on LLDAP side there is nothing wrong. Thanks for the help!

I'll probably make a PR with the settings once I have ironed out the remaining paper-cuts.

@poVoq commented on GitHub (Jan 10, 2023): Duh, now I feel stupid. This seems to mostly work. The login still fails on first try, but since the lldap log said "success" I tried again. Maybe because the Convos account had to be created first. Ok but looks like on LLDAP side there is nothing wrong. Thanks for the help! I'll probably make a PR with the settings once I have ironed out the remaining paper-cuts.

kerem referenced this issue

2026-02-27 08:18:04 +03:00

[PR #160] [MERGED] build(deps): bump docker/setup-buildx-action from 1 to 2 #581