389 Directory Server inventory starts with LDAP authority, not a web title

389 Directory Server is an LDAP directory. Many deployments expose no distinctive HTML title, and the server's real security boundary is the bind, TLS, access control, and replication path rather than a product landing page. A ZoomEye count-only probe on November 15, 2026 showed that distinction clearly.

The queries used sub_type=all, page 1, and page size 1. app="389 Directory Server" returned 0, title="389 Directory Server" returned 1, and http.body="389 Directory Server" returned 88. These are index observations, not confirmed deployments. The body count can include documentation, package pages, and portals that mention the product without running the directory on that host.

Start from the directory service

Identify the LDAP listener, the LDAPS listener, and any StartTLS path. For each service, record the certificate subject and issuer, the minimum TLS version, the cipher policy, and whether anonymous bind is allowed. 389 Directory Server supports access controls based on bind identity and can require protected connections for simple binds.

Map administrative accounts separately from application bind accounts. The directory manager is not a normal service account. A replication bind account should have the narrowest access the replication agreement needs. Review ACI rules with the actual groups and attributes they protect, then test an allowed and a denied operation from a client.

The access log is central to ownership and incident review. It records operations and results, and a security audit log can distinguish authentication and other events. Collect the logs centrally before a suspected incident. A local log on a compromised directory server is not an independent record.

Use the body matches as leads

Open a body match only to verify the product context and owner. A product documentation page is not a running server. A portal that includes the product name may be a management front end, an integration, or an old migration note.

When a live LDAP endpoint is confirmed, ask which application consumes it. Directory data often carries employee identities, group membership, service credentials, and authorization attributes. That makes a read-only bind more sensitive than a generic inventory label suggests.

The near-zero title signal is useful evidence about the fingerprint, not evidence that the directory estate is small. Prefer service, certificate, and organization context for discovery, then verify ownership and configuration on the host.

A defensible inventory

Record the host, endpoint, server version, TLS mode, bind mechanism, replication peers, naming context, owner, and supported applications. Confirm that the anonymous bind setting and ACI rules match the documented policy. Test that a retired account cannot bind and that a simple bind is rejected when the policy requires a protected channel.

The count tells you where to begin. The directory authority tells you what the asset controls.

References

• 389 Directory Server access control guide
• 389 Directory Server TLS and StartTLS guide
• 389 Directory Server anonymous access switch
• 389 Directory Server documentation