[GH-ISSUE #1394] [BUG] phpLDAPadmin compatibility improvements #483

New issue

Open

opened 2026-02-27 08:17:30 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @mlavi on GitHub (Jan 31, 2026).
Original GitHub issue: https://github.com/lldap/lldap/issues/1394

My recent discovery and success with LLDAP as a containerized LDAP solution was more productive in a few sessions than any of my previous efforts with others. Kudos and thank you for providing a cloud-native friendly solution for self-hosting!

phpLDAPadmin (PLA) is a LDAP management web GUI that started in 2002 and I've used it for many years (a long time ago I worked with the LDAP team at Netscape). This week I pointed PLA to my LLDAP instance and found a problem. Because of the LLDAP incompatibility section with encouragement to file a bug, I opened https://github.com/leenooks/phpLDAPadmin/issues/441#issuecomment-3829076024 and engaged a PLA maintainer to support LLDAP. A quick fix raised a few questions to improve the situation past the initial beachhead established with the PLA 2.3-dev container release.

May I ask/suggest: any LLDAP maintainer review and respond to the discussion there and, assuming there is interest in addressing next steps, discuss any LLDAP design or work here? I'm unsure if that is the best, but I wanted to broker initial contact.

To Reproduce

Configure and deploy, then populate a readonly user in LLDAP v2.3.8 (I deployed it behind a reverse proxy that exposes LLDAP's web and ldap ports).
Deploy and configure PLA 2.3-dev to use admin credentials with ldap://$LLDAPhostname.domain:$LLDAPport
Open PLA and see a successful connection and right side tree navigation as administrator, browse to a user entry. More detail on the referenced issue (although I had used the readonly user in that example) and there are questions for LLDAP maintainers.

Expected behavior
It would be nice to get a full read-only browsing session to work with the entire tree of user, groups, and other attributes first. I wouldn't expect editing yet.

Logs
PLA container has no helpful logs at this time.
Relevant LLDAP logs:

2026-01-31T20:14:40.003523399+00:00  INFO     LDAP request [ 163ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9
2026-01-31T20:14:40.005319234+00:00  INFO     ┕━ ｉ [info]: Login attempt for "admin"
2026-01-31T20:14:40.168461813+00:00  INFO     LDAP request [ 99.9µs | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9
2026-01-31T20:14:40.213828101+00:00  INFO     LDAP request [ 4.37ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9
2026-01-31T20:14:40.272084181+00:00  INFO     LDAP request [ 2.22ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9
2026-01-31T20:14:40.274787925+00:00  WARN     ┝━ 🚧 [warn]: Ignoring unrecognized user attribute: c. To disable this warning, add it to "ignored_user_attributes" in the config.
2026-01-31T20:14:40.274793202+00:00  WARN     ┝━ 🚧 [warn]: Ignoring unrecognized user attribute: hassubordinates. To disable this warning, add it to "ignored_user_attributes" in the config.
2026-01-31T20:14:40.274794147+00:00  WARN     ┕━ 🚧 [warn]: Ignoring unrecognized user attribute: numsubordinates. To disable this warning, add it to "ignored_user_attributes" in the config.

Originally created by @mlavi on GitHub (Jan 31, 2026). Original GitHub issue: https://github.com/lldap/lldap/issues/1394 My recent discovery and success with LLDAP as a containerized LDAP solution was more productive in a few sessions than any of my previous efforts with others. Kudos and thank you for providing a cloud-native friendly solution for self-hosting! phpLDAPadmin (PLA) is a LDAP management web GUI [that started in 2002](https://github.com/leenooks/phpLDAPadmin/wiki/History) and I've used it for many years (a long time ago I worked with the LDAP team at Netscape). This week I pointed PLA to my LLDAP instance and found a problem. Because of the LLDAP incompatibility section with encouragement to file a bug, I opened https://github.com/leenooks/phpLDAPadmin/issues/441#issuecomment-3829076024 and engaged a PLA maintainer to support LLDAP. A quick fix raised a few questions to improve the situation past the initial beachhead established with the PLA 2.3-dev container release. May I ask/suggest: any LLDAP maintainer review and respond to the discussion there and, assuming there is interest in addressing next steps, discuss any LLDAP design or work here? I'm unsure if that is the best, but I wanted to broker initial contact. **To Reproduce** 1. Configure and deploy, then populate a readonly user in LLDAP v2.3.8 (I deployed it behind a reverse proxy that exposes LLDAP's web and ldap ports). 2. Deploy and configure PLA 2.3-dev to use `admin` credentials with ldap://$LLDAPhostname.domain:$LLDAPport 3. Open PLA and see a successful connection and right side tree navigation as administrator, browse to a user entry. More detail on the referenced issue (although I had used the readonly user in that example) and there are questions for LLDAP maintainers. **Expected behavior** It would be nice to get a full read-only browsing session to work with the entire tree of user, groups, and other attributes first. I wouldn't expect editing yet. **Logs** PLA container has no helpful logs at this time. Relevant LLDAP logs: ``` 2026-01-31T20:14:40.003523399+00:00 INFO LDAP request [ 163ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9 2026-01-31T20:14:40.005319234+00:00 INFO ┕━ ｉ [info]: Login attempt for "admin" 2026-01-31T20:14:40.168461813+00:00 INFO LDAP request [ 99.9µs | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9 2026-01-31T20:14:40.213828101+00:00 INFO LDAP request [ 4.37ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9 2026-01-31T20:14:40.272084181+00:00 INFO LDAP request [ 2.22ms | 100.00% ] session_id: 543b16ca-818d-433b-8cdb-3baeeb035cf9 2026-01-31T20:14:40.274787925+00:00 WARN ┝━ 🚧 [warn]: Ignoring unrecognized user attribute: c. To disable this warning, add it to "ignored_user_attributes" in the config. 2026-01-31T20:14:40.274793202+00:00 WARN ┝━ 🚧 [warn]: Ignoring unrecognized user attribute: hassubordinates. To disable this warning, add it to "ignored_user_attributes" in the config. 2026-01-31T20:14:40.274794147+00:00 WARN ┕━ 🚧 [warn]: Ignoring unrecognized user attribute: numsubordinates. To disable this warning, add it to "ignored_user_attributes" in the config. ```

kerem added the

bug

label

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

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Jan 31, 2026):

A couple of links as context: https://github.com/lldap/lldap/discussions/1262 for an initial discussion, and https://github.com/lldap/lldap/issues/330 as the bug report adding basic support.

I want to mention that compatibility with LDAP browsers is not a design goal of LLDAP: the preferred interface to explore LLDAP is through graphql, where you will be exposed to the abstractions that the software is written with. The LDAP layer is of course essential, that's where most of the integrations happen, but we don't aim to support the entirety of the protocol, only what's necessary to support as many clients as reasonable.

That said, if we can improve LDAP support without overly increasing the complexity of the software, contributions are welcome (but it's not a priority, so if you wait for me to implement it you might have to wait a long time).

I'll have a look at the discussion and see what I can bring to the table.

@nitnelave commented on GitHub (Jan 31, 2026): A couple of links as context: https://github.com/lldap/lldap/discussions/1262 for an initial discussion, and https://github.com/lldap/lldap/issues/330 as the bug report adding basic support. I want to mention that compatibility with LDAP browsers is not a design goal of LLDAP: the preferred interface to explore LLDAP is through graphql, where you will be exposed to the abstractions that the software is written with. The LDAP layer is of course essential, that's where most of the integrations happen, but we don't aim to support the entirety of the protocol, only what's necessary to support as many clients as reasonable. That said, if we can improve LDAP support without overly increasing the complexity of the software, contributions are welcome (but it's not a priority, so if you wait for me to implement it you might have to wait a long time). I'll have a look at the discussion and see what I can bring to the table.

kerem commented

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

Author

Owner

@mlavi commented on GitHub (Jan 31, 2026):

Understood, my expectations were already set: other LDAP browsers are not a goal. I'd be happy if anything comes from the discussion for the future of both projects, thanks!

@mlavi commented on GitHub (Jan 31, 2026): Understood, my expectations were already set: other LDAP browsers are not a goal. I'd be happy if anything comes from the discussion for the future of both projects, thanks!

kerem referenced this issue

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

[PR #483] [CLOSED] Dark theme #771

kerem referenced this issue

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

[PR #487] [MERGED] Dark Theme #775