LLDAP describes itself as a lightweight authentication server with a simplified LDAP interface and a purpose-built web UI. The project architecture notes that the LDAP interface sends a password to the server and recommends restricting that interface to an internal or container network when the web app is internet-facing. The administrator group is lldap_admin, and membership grants admin rights in the web UI. Those two facts make LLDAP a useful study in joined authorities.
On 13 November 2026 at 03:46 China Standard Time, a ZoomEye count-only query with sub_type=all, page 1, and page size 1 returned 145 matches for title="LLDAP". The application query app="LLDAP" returned zero. The title count is a candidate set, not a count of exposed directories or administrators.
The LDAP and web planes are different interfaces
An LDAP client may bind with a user or service account to search directory entries. The web UI allows an administrator to manage users and groups. The same directory data sits behind both, but the protocols and authentication paths differ. A reverse proxy that protects the web UI does not automatically protect the LDAP listener. A network rule that restricts the LDAP port does not automatically prevent a web administrator from creating a broad account.
The LLDAP architecture documentation makes the transport distinction concrete. It describes the LDAP interface password as cleartext to the server and suggests LDAPS for an internet-facing interface or extra protection between containers. The project README says LDAPS is optional and recommends not exposing plain LDAP to the internet. That is a deployment warning, not a claim that every LLDAP listener is exposed.
The administrator group is another boundary. A user in lldap_admin can administer the web UI. The review should identify who is in that group, how the membership is changed, and whether the identity provider that authenticates the administrator is separate from the directory being managed. A directory service should not be its own sole recovery path for every administrator account without a documented break-glass process.
What a title match can support
A title match can help find self-hosted LLDAP deployments, but it cannot show whether the LDAP listener is private, whether LDAPS is enabled, or whether the web UI is behind SSO. Validate an owned deployment with a non-invasive page request and compare the URL with the internal service record. Do not attempt credential guessing against an unknown directory.
On an owned deployment, inventory the web listener and the LDAP listener separately. Record the TLS mode, bind method, account used by each application, and network path. Test that a normal application can search the directory with its intended account and that an unauthenticated network client cannot reach the LDAP listener from outside the management boundary.
Review the lldap_admin membership and the web UI's authentication. If SSO is used, verify the group mapping and the account used for emergency administration. If local passwords are used, review storage and reset procedures. Test that an ordinary user cannot perform an administrative group change even if the user can read the directory.
Monitor the joins, not only the ports
A new application integration can create a new LDAP bind account with broad read access. A new administrator can be added to lldap_admin through an automation path that bypasses the normal review. A reverse-proxy change can make the web UI reachable from a broader network while the LDAP listener remains private. Each change affects a different authority, so the monitoring should keep them separate.
Alert on changes to lldap_admin membership, new bind accounts, listener exposure, and LDAPS configuration. Correlate the event with the identity provider, the application owner, and the deployment record. A port scan alone will not show which account can modify the directory.
The 145 title matches are a useful discovery signal with clear ambiguity. The application fingerprint returned zero in this measurement. The security question is whether the validated deployment exposes the LDAP listener outside its management network and whether the web administrator path is protected by a separate, recoverable identity process. The small product surface does not make those two authorities the same.
Query evidence
Search:
title="LLDAP"Application:
app="LLDAP"Scope:
sub_type=all, page 1, page size 1Counts: 145 and 0
Observed: 2026-11-13 03:46 China Standard Time