starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #666] LLDAP group names are case sensitive when searching, they shouldn't be #241

New issue
Closed
opened 2026-02-27 08:16:06 +03:00 by kerem · 16 comments
kerem commented 2026-02-27 08:16:06 +03:00
Owner
Copy link

Originally created by @ArVar on GitHub (Sep 7, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/666

I'm following the instructions as explained here: https://github.com/lldap/lldap/blob/main/example_configs/nextcloud.md

Unfortunately, I'm getting both:
A message, telling me, that the LDAP server does not support memberOf (which is obviously not true).
And yes, I've read this in the example: the only from these groups option is not functional, but would like to mention this in this context.

Trying to use the described filter:
(&(objectclass=person)(memberOf=cn=nextcloud_users,ou=groups,dc=example,dc=com))
I'm getting following warning in lldap logs:

┕━ 🚧 [warn]: Ignoring unknown group attribute ""memberof"" in filter.\n
To disable this warning, add it to "ignored_group_attributes" in the config.

and the users are not discovered.
Of course I have groups and Users assigned to them.

I'm using the most recent image for the container, as well as an up to date Nextcloud installation. I've found similar errors in the issues but no solution for this particular problem so far.
Apperently, there also was a discussion on discord a while ago, but without a proper solution.

Does anyone have similar experiences?
For me it looks somehow related to case-(in)sensitivity.

Originally created by @ArVar on GitHub (Sep 7, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/666 I'm following the instructions as explained here: https://github.com/lldap/lldap/blob/main/example_configs/nextcloud.md Unfortunately, I'm getting both: A message, telling me, that the LDAP server does not support memberOf (which is obviously not true). And yes, I've read this in the example: `the only from these groups option is not functional`, but would like to mention this in this context. Trying to use the described filter: `(&(objectclass=person)(memberOf=cn=nextcloud_users,ou=groups,dc=example,dc=com))` I'm getting following warning in lldap logs: > ┕━ 🚧 [warn]: Ignoring unknown group attribute ""memberof"" in filter.\n\ > To disable this warning, add it to "ignored_group_attributes" in the config. and the users are not discovered. Of course I have groups and Users assigned to them. I'm using the most recent image for the container, as well as an up to date Nextcloud installation. I've found similar errors in the issues but no solution for this particular problem so far. Apperently, there also was a discussion on discord a while ago, but without a proper solution. Does anyone have similar experiences? For me it looks somehow related to case-(in)sensitivity.
kerem 2026-02-27 08:16:06 +03:00
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 7, 2023):

Sorry for the silly question, but: could you have somehow gotten mixed up
between the groups and users filters?
The warning you get is from querying groups (which also explains why member
of doesn't work, since it only works with users)

<!-- gh-comment-id:1710838888 --> @nitnelave commented on GitHub (Sep 7, 2023): Sorry for the silly question, but: could you have somehow gotten mixed up between the groups and users filters? The warning you get is from querying groups (which also explains why member of doesn't work, since it only works with users)
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 7, 2023):

Just leaving a note: I do not think it's due to case sensitivity. We lowercase every keyword, and we have tests checking that we do.

<!-- gh-comment-id:1710867068 --> @nitnelave commented on GitHub (Sep 7, 2023): Just leaving a note: I do not think it's due to case sensitivity. We lowercase every keyword, and we have tests checking that we do.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Sep 11, 2023):

I need to recheck. But I'm explicitly doing as described in the example. I'll report.

<!-- gh-comment-id:1713228554 --> @ArVar commented on GitHub (Sep 11, 2023): I need to recheck. But I'm explicitly doing as described in the example. I'll report.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Sep 11, 2023):

So, I played around with different group names. I created different groups in lldap. The filter in nextcloud as described in the example only works for existing groups with all-lowercase names. E.g. for 'test' as an lldap-group it worked, where for 'Test' the result was always empty until I created the group 'test' in lldap (with all lowercase). Therefore I think, there really might be a case issue. The request might be transformed to lowercase in the nextcloud LDAP-plugin but lldap seems to be case-sensitive at least for groups. LDAP is mostly case-insensitve by default.

<!-- gh-comment-id:1714303500 --> @ArVar commented on GitHub (Sep 11, 2023): So, I played around with different group names. I created different groups in lldap. The filter in nextcloud as described in the example only works for existing groups with all-lowercase names. E.g. for 'test' as an lldap-group it worked, where for 'Test' the result was always empty until I created the group 'test' in lldap (with all lowercase). Therefore I think, there really might be a case issue. The request might be transformed to lowercase in the nextcloud LDAP-plugin but lldap seems to be case-sensitive at least for groups. LDAP is mostly case-insensitve by default.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 11, 2023):

Hmm, yeah, it does look like a case sensitivity now (I still think there was something wrong with the filters at the beginning, that was not a case sensitivity problem).

Indeed, I think the group names are case sensitive in LLDAP, where they should not be. I'll rename the issue to refocus on that. Can you work around this for now?

<!-- gh-comment-id:1714332034 --> @nitnelave commented on GitHub (Sep 11, 2023): Hmm, yeah, it does look like a case sensitivity now (I still think there was something wrong with the filters at the beginning, _that_ was not a case sensitivity problem). Indeed, I think the group names are case sensitive in LLDAP, where they should not be. I'll rename the issue to refocus on that. Can you work around this for now?
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Sep 11, 2023):

After further thinking about the warning:
Ignoring unknown group attribute ""memberof"" in filter.\n\
This warning should not appear in the logs, since my filter is for users and not for groups:
ldapUserFilter "(&(objectclass=person)(memberOf=cn=nextcloud_users,ou=groups,dc=example,dc=com))"
This might or might not be related to how the LDAP-plugin of nextcloud works but mislead me to wrong conclusions earlier. But it definetely is not the source of this problem, since I checked lldaps source, which handles this memberOf attribute well, I think.

Is it possible that convert_group_filter is applied on each LDAP-search even if there is only a user filter? (Would be another, completely different issue).

<!-- gh-comment-id:1714376946 --> @ArVar commented on GitHub (Sep 11, 2023): After further thinking about the warning: `Ignoring unknown group attribute ""memberof"" in filter.\n\` This warning should not appear in the logs, since my filter is for users and not for groups: `ldapUserFilter "(&(objectclass=person)(memberOf=cn=nextcloud_users,ou=groups,dc=example,dc=com))"` This might or might not be related to how the LDAP-plugin of nextcloud works but mislead me to wrong conclusions earlier. But it definetely is not the source of this problem, since I checked lldaps source, which handles this memberOf attribute well, I think. Is it possible that convert_group_filter is applied on each LDAP-search even if there is only a user filter? (Would be another, completely different issue).
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 11, 2023):

Could you run LLDAP in verbose mode and paste the logs here? It's hard to debug without knowing what query was sent.

<!-- gh-comment-id:1714388096 --> @nitnelave commented on GitHub (Sep 11, 2023): Could you run LLDAP in verbose mode and paste the logs here? It's hard to debug without knowing what query was sent.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Sep 21, 2023):

Here are the logs for following request:
(&(objectclass=person)(memberOf=cn=Mitarbeiter,ou=groups,dc=***,dc=de))

Logs:

2023-09-21T19:59:16.235693811+00:00  INFO     LDAP session [ 97.1ms | 0.11% / 100.00% ]
2023-09-21T19:59:16.235723421+00:00  INFO     ┝━ LDAP request [ 96.5ms | 0.14% / 99.40% ]
2023-09-21T19:59:16.235735351+00:00  DEBUG    │  ┝━ 🐛 [debug]:  | msg: LdapMsg { msgid: 1, op: BindRequest(LdapBindRequest { dn: "uid=***,ou=people,dc=***,dc=de", cred: Simple("********") }), ctrl: [] }
2023-09-21T19:59:16.235737481+00:00  DEBUG    │  ┝━ do_bind [ 96.4ms | 0.03% / 99.26% ]
2023-09-21T19:59:16.235740641+00:00  DEBUG    │  │  ┝━ 🐛 [debug]: DN: uid=***,ou=people,dc=***,dc=de
2023-09-21T19:59:16.235747811+00:00  DEBUG    │  │  ┝━ bind [ 96.2ms | 0.01% / 99.05% ]
2023-09-21T19:59:16.235749911+00:00  DEBUG    │  │  │  ┝━ get_password_file_for_user [ 98.3µs | 0.10% ]
2023-09-21T19:59:16.235958470+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 96.1ms | 98.94% ]
2023-09-21T19:59:16.332031983+00:00  DEBUG    │  │  ┝━ get_user_groups [ 183µs | 0.19% ]
2023-09-21T19:59:16.332038763+00:00  DEBUG    │  │  │  ┝━ 🐛 [debug]:  | user_id: UserId("***")
2023-09-21T19:59:16.332426610+00:00  DEBUG    │  │  │  ┕━ 🐛 [debug]:  | return: {GroupDetails { group_id: GroupId(3), display_name: "lldap_strict_readonly", creation_date: 2023-08-16T19:55:45.477622915, uuid: Uuid("9f2962ab-8c86-3f62-8105-c01a77c15253") }}
2023-09-21T19:59:16.332430939+00:00  DEBUG    │  │  ┕━ 🐛 [debug]: Success!
2023-09-21T19:59:16.332438819+00:00  DEBUG    │  ┕━ 🐛 [debug]:  | response: BindResponse(LdapBindResponse { res: LdapResult { code: Success, matcheddn: "", message: "", referral: [] }, saslcreds: None })
2023-09-21T19:59:16.332833476+00:00  INFO     ┝━ LDAP request [ 469µs | 0.06% / 0.48% ]
2023-09-21T19:59:16.332844335+00:00  DEBUG    │  ┝━ 🐛 [debug]:  | msg: LdapMsg { msgid: 2, op: SearchRequest(LdapSearchRequest { base: "dc=***,dc=de", scope: Subtree, aliases: Never, sizelimit: 0, timelimit: 0, typesonly: false, filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")]), attrs: ["dn"] }), ctrl: [SimplePagedResults { size: 500, cookie: "" }] }
2023-09-21T19:59:16.332845865+00:00  DEBUG    │  ┝━ do_search [ 412µs | 0.10% / 0.42% ]
2023-09-21T19:59:16.332852605+00:00  DEBUG    │  │  ┝━ 🐛 [debug]:  | request.base: "dc=***,dc=de" | scope: Global
2023-09-21T19:59:16.332853695+00:00  DEBUG    │  │  ┝━ get_user_list [ 194µs | 0.02% / 0.20% ]
2023-09-21T19:59:16.332857475+00:00  DEBUG    │  │  │  ┝━ 🐛 [debug]:  | ldap_filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")])
2023-09-21T19:59:16.332871475+00:00  DEBUG    │  │  │  ┝━ 🐛 [debug]:  | filters: And([And([And([]), MemberOf("mitarbeiter")]), And([])])
2023-09-21T19:59:16.332873725+00:00  DEBUG    │  │  │  ┕━ list_users [ 170µs | 0.18% ]
2023-09-21T19:59:16.332875975+00:00  DEBUG    │  │  │     ┝━ 🐛 [debug]:  | filters: Some(And([And([And([]), MemberOf("mitarbeiter")]), And([])]))
2023-09-21T19:59:16.333164473+00:00  DEBUG    │  │  │     ┕━ 🐛 [debug]:  | return: []
2023-09-21T19:59:16.333167863+00:00  DEBUG    │  │  ┕━ get_groups_list [ 119µs | 0.02% / 0.12% ]
2023-09-21T19:59:16.333172243+00:00  DEBUG    │  │     ┝━ 🐛 [debug]:  | ldap_filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")])
2023-09-21T19:59:16.333176873+00:00  WARN     │  │     ┝━ 🚧 [warn]: Ignoring unknown group attribute ""memberof"" in filter.\n\
                                To disable this warning, add it to "ignored_group_attributes" in the config.
2023-09-21T19:59:16.333180023+00:00  DEBUG    │  │     ┝━ 🐛 [debug]:  | filters: And([And([Not(And([])), Not(And([]))]), And([])])
2023-09-21T19:59:16.333181753+00:00  DEBUG    │  │     ┕━ list_groups [ 103µs | 0.11% ]
2023-09-21T19:59:16.333183983+00:00  DEBUG    │  │        ┝━ 🐛 [debug]:  | filters: Some(And([And([Not(And([])), Not(And([]))]), And([])]))
2023-09-21T19:59:16.333337982+00:00  DEBUG    │  │        ┕━ 🐛 [debug]:  | return: []
2023-09-21T19:59:16.333506840+00:00  DEBUG    │  ┕━ 🐛 [debug]:  | response: SearchResultDone(LdapResult { code: Success, matcheddn: "", message: "", referral: [] })
2023-09-21T19:59:16.335292254+00:00  INFO     ┕━ LDAP request [ 4.52µs | 0.00% ]
2023-09-21T19:59:16.335296014+00:00  DEBUG       ┕━ 🐛 [debug]:  | msg: LdapMsg { msgid: 3, op: UnbindRequest, ctrl: [] }

The group "Mitarbeiter" is transformed to "mitarbeiter" and the Result is return: []
"Mitarbeiter" has members where "mitarbeiter" does not exist.

I hope this helps to dig a bit deeper.

<!-- gh-comment-id:1730225012 --> @ArVar commented on GitHub (Sep 21, 2023): Here are the logs for following request: `(&(objectclass=person)(memberOf=cn=Mitarbeiter,ou=groups,dc=***,dc=de))` Logs: ``` 2023-09-21T19:59:16.235693811+00:00 INFO LDAP session [ 97.1ms | 0.11% / 100.00% ] 2023-09-21T19:59:16.235723421+00:00 INFO ┝━ LDAP request [ 96.5ms | 0.14% / 99.40% ] 2023-09-21T19:59:16.235735351+00:00 DEBUG │ ┝━ 🐛 [debug]: | msg: LdapMsg { msgid: 1, op: BindRequest(LdapBindRequest { dn: "uid=***,ou=people,dc=***,dc=de", cred: Simple("********") }), ctrl: [] } 2023-09-21T19:59:16.235737481+00:00 DEBUG │ ┝━ do_bind [ 96.4ms | 0.03% / 99.26% ] 2023-09-21T19:59:16.235740641+00:00 DEBUG │ │ ┝━ 🐛 [debug]: DN: uid=***,ou=people,dc=***,dc=de 2023-09-21T19:59:16.235747811+00:00 DEBUG │ │ ┝━ bind [ 96.2ms | 0.01% / 99.05% ] 2023-09-21T19:59:16.235749911+00:00 DEBUG │ │ │ ┝━ get_password_file_for_user [ 98.3µs | 0.10% ] 2023-09-21T19:59:16.235958470+00:00 DEBUG │ │ │ ┕━ passwords_match [ 96.1ms | 98.94% ] 2023-09-21T19:59:16.332031983+00:00 DEBUG │ │ ┝━ get_user_groups [ 183µs | 0.19% ] 2023-09-21T19:59:16.332038763+00:00 DEBUG │ │ │ ┝━ 🐛 [debug]: | user_id: UserId("***") 2023-09-21T19:59:16.332426610+00:00 DEBUG │ │ │ ┕━ 🐛 [debug]: | return: {GroupDetails { group_id: GroupId(3), display_name: "lldap_strict_readonly", creation_date: 2023-08-16T19:55:45.477622915, uuid: Uuid("9f2962ab-8c86-3f62-8105-c01a77c15253") }} 2023-09-21T19:59:16.332430939+00:00 DEBUG │ │ ┕━ 🐛 [debug]: Success! 2023-09-21T19:59:16.332438819+00:00 DEBUG │ ┕━ 🐛 [debug]: | response: BindResponse(LdapBindResponse { res: LdapResult { code: Success, matcheddn: "", message: "", referral: [] }, saslcreds: None }) 2023-09-21T19:59:16.332833476+00:00 INFO ┝━ LDAP request [ 469µs | 0.06% / 0.48% ] 2023-09-21T19:59:16.332844335+00:00 DEBUG │ ┝━ 🐛 [debug]: | msg: LdapMsg { msgid: 2, op: SearchRequest(LdapSearchRequest { base: "dc=***,dc=de", scope: Subtree, aliases: Never, sizelimit: 0, timelimit: 0, typesonly: false, filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")]), attrs: ["dn"] }), ctrl: [SimplePagedResults { size: 500, cookie: "" }] } 2023-09-21T19:59:16.332845865+00:00 DEBUG │ ┝━ do_search [ 412µs | 0.10% / 0.42% ] 2023-09-21T19:59:16.332852605+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | request.base: "dc=***,dc=de" | scope: Global 2023-09-21T19:59:16.332853695+00:00 DEBUG │ │ ┝━ get_user_list [ 194µs | 0.02% / 0.20% ] 2023-09-21T19:59:16.332857475+00:00 DEBUG │ │ │ ┝━ 🐛 [debug]: | ldap_filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")]) 2023-09-21T19:59:16.332871475+00:00 DEBUG │ │ │ ┝━ 🐛 [debug]: | filters: And([And([And([]), MemberOf("mitarbeiter")]), And([])]) 2023-09-21T19:59:16.332873725+00:00 DEBUG │ │ │ ┕━ list_users [ 170µs | 0.18% ] 2023-09-21T19:59:16.332875975+00:00 DEBUG │ │ │ ┝━ 🐛 [debug]: | filters: Some(And([And([And([]), MemberOf("mitarbeiter")]), And([])])) 2023-09-21T19:59:16.333164473+00:00 DEBUG │ │ │ ┕━ 🐛 [debug]: | return: [] 2023-09-21T19:59:16.333167863+00:00 DEBUG │ │ ┕━ get_groups_list [ 119µs | 0.02% / 0.12% ] 2023-09-21T19:59:16.333172243+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | ldap_filter: And([And([Equality("objectclass", "person"), Equality("memberOf", "cn=Mitarbeiter,ou=groups,dc=***,dc=de")]), Present("displayname")]) 2023-09-21T19:59:16.333176873+00:00 WARN │ │ ┝━ 🚧 [warn]: Ignoring unknown group attribute ""memberof"" in filter.\n\ To disable this warning, add it to "ignored_group_attributes" in the config. 2023-09-21T19:59:16.333180023+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | filters: And([And([Not(And([])), Not(And([]))]), And([])]) 2023-09-21T19:59:16.333181753+00:00 DEBUG │ │ ┕━ list_groups [ 103µs | 0.11% ] 2023-09-21T19:59:16.333183983+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | filters: Some(And([And([Not(And([])), Not(And([]))]), And([])])) 2023-09-21T19:59:16.333337982+00:00 DEBUG │ │ ┕━ 🐛 [debug]: | return: [] 2023-09-21T19:59:16.333506840+00:00 DEBUG │ ┕━ 🐛 [debug]: | response: SearchResultDone(LdapResult { code: Success, matcheddn: "", message: "", referral: [] }) 2023-09-21T19:59:16.335292254+00:00 INFO ┕━ LDAP request [ 4.52µs | 0.00% ] 2023-09-21T19:59:16.335296014+00:00 DEBUG ┕━ 🐛 [debug]: | msg: LdapMsg { msgid: 3, op: UnbindRequest, ctrl: [] } ``` The group "Mitarbeiter" is transformed to "mitarbeiter" and the Result is `return: []` "Mitarbeiter" has members where "mitarbeiter" does not exist. I hope this helps to dig a bit deeper.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 21, 2023):

Ah, yes, I think I see what's happening. This is a half-baked attempt at making comparison case insensitive: the searched group is lowercased, which would help if the stored groups were lowercased as well, but it's not the case (haha).

Yep, that's a very legitimate bug

<!-- gh-comment-id:1730233222 --> @nitnelave commented on GitHub (Sep 21, 2023): Ah, yes, I think I see what's happening. This is a half-baked attempt at making comparison case insensitive: the searched group is lowercased, which would help if the stored groups were lowercased as well, but it's not the case (haha). Yep, that's a very legitimate bug
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 21, 2023):

In the meantime, I recommend only using lowercase groups

<!-- gh-comment-id:1730233579 --> @nitnelave commented on GitHub (Sep 21, 2023): In the meantime, I recommend only using lowercase groups
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Sep 21, 2023):

Wow, what a response time, @nitnelave. 🥇 :-D

<!-- gh-comment-id:1730237537 --> @ArVar commented on GitHub (Sep 21, 2023): Wow, what a response time, @nitnelave. 🥇 :-D
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@ArVar commented on GitHub (Oct 18, 2023):

Hi @nitnelave, if you point me to the relevant code snippets you have in mind, maybe I can help and create a pull request.

<!-- gh-comment-id:1769237123 --> @ArVar commented on GitHub (Oct 18, 2023): Hi @nitnelave, if you point me to the relevant code snippets you have in mind, maybe I can help and create a pull request.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Oct 20, 2023):

Sorry for the delay, I was thinking how to best approach it. I'd still like to be able to have capital letters in group names (so we have to store them in capital), but there's no portable (and indexable) way to have a case insensitive search in SQL.
One way would be to write an SQL migration, and do something different for each engine to add a case insensitive collate.
Sea-QL doesn't support collate cross-engine yet (there's https://docs.rs/sea-query/latest/sea_query/table/struct.TableCreateStatement.html#method.collate and https://github.com/SeaQL/sea-orm/issues/1901 but they're not there yet), so we'd have to check the type of the connection and write raw SQL for each engine.

<!-- gh-comment-id:1772666196 --> @nitnelave commented on GitHub (Oct 20, 2023): Sorry for the delay, I was thinking how to best approach it. I'd still like to be able to have capital letters in group names (so we have to store them in capital), but there's no portable (and indexable) way to have a case insensitive search in SQL. One way would be to write an SQL migration, and do something different for each engine to add a case insensitive `collate`. Sea-QL doesn't support `collate` cross-engine yet (there's https://docs.rs/sea-query/latest/sea_query/table/struct.TableCreateStatement.html#method.collate and https://github.com/SeaQL/sea-orm/issues/1901 but they're not there yet), so we'd have to check the type of the connection and write raw SQL for each engine.
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Oct 20, 2023):

As for the specifics, it'd be something like adding a migrate_to_v6 method here: https://github.com/lldap/lldap/blob/main/server/src/domain/sql_migrations.rs#L495

<!-- gh-comment-id:1772668746 --> @nitnelave commented on GitHub (Oct 20, 2023): As for the specifics, it'd be something like adding a `migrate_to_v6` method here: https://github.com/lldap/lldap/blob/main/server/src/domain/sql_migrations.rs#L495
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Dec 15, 2023):

Alright, I fixed the casing of group names, attribute names and user emails while I was at it :)

<!-- gh-comment-id:1858578647 --> @nitnelave commented on GitHub (Dec 15, 2023): Alright, I fixed the casing of group names, attribute names and user emails while I was at it :)
kerem commented 2026-02-27 08:16:07 +03:00
Author
Owner
Copy link

@a1730 commented on GitHub (Jan 11, 2024):

Fantastic!
This will be a big win for us. May I plead for a point release with these features, please?
Thank you for this excellent project.

<!-- gh-comment-id:1887526362 --> @a1730 commented on GitHub (Jan 11, 2024): Fantastic! This will be a big win for us. May I plead for a point release with these features, please? Thank you for this excellent project.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear labels   
backend

   
blocked

   
bug

   
cleanup

   
dependencies

   
docker

   
documentation

   
duplicate

   
enhancement

   
enhancement

   
frontend

   
github_actions

   
good first issue

   
help wanted

   
help wanted

   
integration

   
invalid

   
ldap

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#241
No description provided.