[GH-ISSUE #1165] [BUG] Users and groups objects are seen as containers, instead of leafs #414

New issue

Open

opened 2026-02-27 08:17:10 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 08:17:10 +03:00

Owner

Originally created by @Wrong-Code on GitHub (May 1, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1165

Describe the bug
While I was playing with a couple of LDAP browsers software, I have noticed that both users and groups in LLDAP are seen by those apps not as leafs, but as containers. I am not very strong in LDAP terminology / standard, but to my knowledge it shouldn't be so.

To Reproduce
I have used Softerra LDAP Browser and LDAPSoft LDAP Browser Windows apps to browser the LLDAP's LDAP tree. In both cases, when pointing to an user or a group, they are shown as containers in the LDAP tree, and you can drill down (expand) endlessly the object. See the attached snapshots:

In Softerra LDAP Browser, it can be seen that the uid attribute is seen both as a string value, and as a container.

Expected behavior
Users / groups should not be interpreted by LDAP browsers as containers.

Logs
None

Additional context
This could be indeed another side effect of LDAP simplification which the project aims to. However, standard LDAP software can be mislead by the data returned from the LLDAP service.

Originally created by @Wrong-Code on GitHub (May 1, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1165 **Describe the bug** While I was playing with a couple of LDAP browsers software, I have noticed that both users and groups in LLDAP are seen by those apps not as leafs, but as containers. I am not very strong in LDAP terminology / standard, but to my knowledge it shouldn't be so. **To Reproduce** I have used Softerra LDAP Browser and LDAPSoft LDAP Browser Windows apps to browser the LLDAP's LDAP tree. In both cases, when pointing to an user or a group, they are shown as containers in the LDAP tree, and you can drill down (expand) endlessly the object. See the attached snapshots: ![Image](https://github.com/user-attachments/assets/4edc839c-9099-4f66-9886-eb7a568aefe7) ![Image](https://github.com/user-attachments/assets/b9ea25f0-ce15-4733-8ed4-b5ba7c7223ea) In Softerra LDAP Browser, it can be seen that the uid attribute is seen both as a string value, and as a container. **Expected behavior** Users / groups should not be interpreted by LDAP browsers as containers. **Logs** None **Additional context** This could be indeed another side effect of LDAP simplification which the project aims to. However, standard LDAP software can be mislead by the data returned from the LLDAP service.

kerem added the

bug

label

2026-02-27 08:17:10 +03:00

kerem commented

2026-02-27 08:17:10 +03:00

Author

Owner

@nitnelave commented on GitHub (May 1, 2025):

This is somewhat well-known: LDAP browsers don't work well with LLDAP, because they send very generic queries asking for lots of properties to cover very generic cases, and we don't handle a lot of these queries (properly).

I don't know exactly what went wrong here, but it's not my priority to investigate. Just to mention the scope of the project: a better support of the LDAP protocol would be a nice-to-have (and I'll accept PRs for it), but not a priority, so I probably won't personally work on it.

@nitnelave commented on GitHub (May 1, 2025): This is somewhat well-known: LDAP browsers don't work well with LLDAP, because they send very generic queries asking for lots of properties to cover very generic cases, and we don't handle a lot of these queries (properly). I don't know exactly what went wrong here, but it's not my priority to investigate. Just to mention the scope of the project: a better support of the LDAP protocol would be a nice-to-have (and I'll accept PRs for it), but not a priority, so I probably won't personally work on it.

kerem referenced this issue

2026-02-27 09:09:31 +03:00

[PR #414] [MERGED] Gitea: add additional attributes and group sync #726