LDAP - session length?

[thielj]

"Binding" in (L)LDAP takes a significant time, probably due to the hashing algorithm / password verification. On a low powered device, this can be 2500ms, followed by one or two queries in the 1-2ms range. So I wonder, is there an idle timeout I have missed in Authelia or LLDAP. Are sessions actually pooled/re-used?

Am I missing something else here? LLDAP is just another container on the same host, exclusively used by Authelia.

[glime-ai[bot]]

Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it.

---

Based on the information provided in the sources, there is no specific mention of an idle timeout setting directly within Authelia or LLDAP that would address the issue you're experiencing with binding times. However, there are a few considerations and configurations that might help optimize the performance:

1. Session Reuse: Authelia does not cache LDAP bind operations as per the discussion in GitHub issue Authelia ldaps with active directory still allows login with old password and new password after reset #6030. This means each authentication attempt will involve a full bind process, which can be time-consuming, especially on low-powered devices.

2. Hashing Algorithm Performance: As you mentioned, the hashing algorithm (like Argon2id used by Authelia) can significantly impact performance. You might consider tuning the parameters of the Argon2id algorithm used in Authelia to reduce computational overhead, though this could potentially affect security.

3. LDAP Connection Pooling: While not directly mentioned in your sources, implementing connection pooling at the LDAP client level could potentially improve performance. This would allow LDAP connections to be reused rather than creating a new connection for each bind request. You would need to check if your LDAP client library supports connection pooling and configure it accordingly.

4. Hardware Limitations: Given that LLDAP is running on the same host and is exclusively used by Authelia, hardware limitations could be a bottleneck. Upgrading the hardware or distributing the load across multiple devices might help.

5. Optimize LDAP Queries: Ensure that your LDAP queries are optimized and that the LDAP server itself is configured for performance. This includes indexing relevant attributes and minimizing the scope and complexity of search queries.

If you continue to experience issues, it might be beneficial to look into more detailed logs from both Authelia and LLDAP to identify any specific bottlenecks or errors that could be contributing to the long bind times.

This comment was generated by Glime.

[james-d-elliott]

So we don't do any pooling currently as there wasn't a clear benefit due to the frequency of connections made. We can experiment with one if you're interested in giving feedback.

[james-d-elliott]

Hi James. The "bind user" session used to lookup groups and such should stay alive as long as possible, maybe with a "max requests" parameter of some sort. Without it, any Argon2 based LDAP implementation is practically unusable on a small system.

Not entirely sure if should is the correct way to phrase it, but it'd be useful to give the option for this regardless. Pretty sure I've got a working implementation just have to finish reworking the tests. There are likely to be implementation specific issues which cause disconnects periodically which will lead to additional issues anyway.

Judging from discussions, many people seem to be stumbling about this when setting it up. Shall I add this to the docs?

I don't think we can reasonably document every nuance with each of the different LDAP implementations and maintain it, it's not really our job. We can ensure the implementation defaults match a working configuration under normal circumstances though.

[james-d-elliott]

Try out feat-ldap-pool. Example config:

authentication_backend:
  ldap:
    pooling:
      enable: true  # Use pooling.
      count: 4  # Pool count/max connections.
      retries: 3  # Number of retries within the timeout period.
      timeout: 10s  # Length of time to wait for the pool to have a connection available.

[james-d-elliott]

Keep in mind if you set count to 4 the maximum concurrent requests that can utilize LDAP is 4, the requests additional to this will wait up until the timeout value for the prior requests to finish before proceeding (or erroring if the timeout is reached).

[thielj]

HI James,

to be honest, I can't confirm that any pooling is happening or not, at least not from the Authelia or LLDAP logs.

The only observation I can make is that there are no more sessions or requests logged after the initial ones. I.e. without pooling enabled, connections to LLDAP to verify the user's credentials were always followed about 2 more connections authenticated with the bind user (bind_authelia in the log below). These seem to have all but disappeared now.

I can also confirm that this is working with GLAUTH.

Mind you, no load testing or anything like that, but I will leave it enabled for now and pass it on to the LLDAP board.

Looking forward to see this in an official build. Thanks!

---

v4.38.8 observable behaviour (grep'ing on LLDAP's passwords_match)

2024-04-24T16:12:38.309497189+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 997ms | 64.13% ] username: bind_authelia
2024-04-24T16:12:39.577864247+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 609ms | 70.18% ] username: bind_authelia
2024-04-24T16:12:37.807920268+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 494ms | 46.37% ] username: bind_authelia
2024-04-24T16:12:36.392714911+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 1.41s | 69.65% ] username: bind_authelia
2024-04-24T16:39:48.886705099+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 1.40s | 99.34% ] username: bind_authelia
2024-04-24T16:40:18.376067481+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 2.23s | 88.76% ] username: bind_authelia
2024-04-24T16:40:21.008156121+00:00  DEBUG       │  │  ┕━ passwords_match [ 1.19s | 99.49% ] username: jens
2024-04-24T16:40:22.406034655+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 781ms | 99.16% ] username: bind_authelia
2024-04-24T16:40:24.399096785+00:00  DEBUG       │  │  ┕━ passwords_match [ 892ms | 99.77% ] username: svc_uptime
2024-04-24T16:40:23.674498481+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 623ms | 99.31% ] username: bind_authelia
2024-04-24T16:40:25.304846392+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 471ms | 98.47% ] username: bind_authelia
2024-04-24T16:40:40.573461797+00:00  DEBUG       │  │  ┕━ passwords_match [ 511ms | 99.65% ] username: svc_uptime
2024-04-24T16:40:38.935637795+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 1.55s | 99.62% ] username: bind_authelia
2024-04-24T16:40:41.272139532+00:00  DEBUG    │  │  │  ┕━ passwords_match [ 412ms | 98.62% ] username: bind_authelia

[thielj]

Also, from the user side, it feels significantly 'snappier'.