Closed mxhash closed 2 months ago
Having the same issue. However when i switched the Provider settings to direct binding and direct querying, the ldap starts and accepts searches, but is extremly slow and the memory usage of the ldap container skyrocket every minute about 100MB.
Hi,
I can confirm that the startup was successful with the direct query and bind options configured. I’ve attached a screenshot showing the memory consumption for a single login. The login took more than 5 minutes.
Cheers, Marius
Describe the bug
After the upgrade to 2024.8.0 the ldap outpost does not start up and authentication is not possible.
Edit: Looks like the container tries to fetch users and groups. I left the container running for an hour, and it builds up memory until the kernel kills the process with an OOM (Out of Memory) error:
To Reproduce Steps to reproduce the behavior:
Expected behavior LDAP outpost starts the binder and the ports are open. Also the FE outpost status and the container should be healthy and authentication, or at least, bind with a service user should lead to success.
Logs
LDAP Outpost Container Logs:
Outpost Requests on Server Container
Successful startup of a 2024.6.4 LDAP outpost, but it does not accept the response from the server any more and no authentication is possible:
Version and Deployment (please complete the following information):
Additional context
It seems that the LDAP outpost hangs after fetching the certificate, and it does not start the binder. As a result, the ports do not open, making a connection impossible. I double-checked the object permissions, and a test with superuser privileges for the outpost user did not change anything. All requests respond with a status of 200. Simplifying the configuration and using vanilla documentation deployment examples were also unsuccessful.
The frontend shows the first health check request as OK (with no version), but then switches to ‘not available’.
Docker compose service: