LDAP search permissions no longer work

[pizzaandcheese]

Describe the bug
Ever since the 2024.8 update my LDAP user access has not been functional. I get "ldap_bind: Insufficient access (50)" when testing. Reading through the changelogs led me to finding out that the search group was removed and all LDAP permissions were moved to RBAC. I tried creating a role for LDAP search access and adding my LDAP bind user to a group with that role attached to no avail. Am I doing something wrong with my configurations?

To Reproduce
Steps to reproduce the behavior:

1. have Authentik installed pre 2024.8
2. create LDAP user via Documentation
3. update to 2024.8
4. ???

Expected behavior
LDAP bind searches users

Screenshots

Logs
ldapsearch -x -H <REDACTED> -D 'cn=ldapservice,ou=users,ou=ldap,DC=ldap,DC=example,DC=com' -w <REDACTED> '(objectClass=username)'
ldap_bind: Insufficient access (50)

Logs from auhtentik-ldap container:
ldap-1 | {"bindDN":"cn=ldapservice,ou=users,ou=ldap,dc=ldap,dc=example,dc=com","client":"<REDACTED>","event":"No provider found for request","level":"warning","request":"bind","requestId":"89c29721-3d8a-475a-86a4-180bc3f28c80","timestamp":"2024-09-17T02:30:18Z"}
ldap-1 | {"bindDN":"cn=ldapservice,ou=users,ou=ldap,dc=ldap,dc=example,dc=com","client":"<REDACTED>","event":"Bind request","level":"info","requestId":"89c29721-3d8a-475a-86a4-180bc3f28c80","timestamp":"2024-09-17T02:30:18Z","took-ms":1}

Version and Deployment (please complete the following information):

• authentik version: 2024.8
• Deployment: docker-compose

[pizzaandcheese]

I tried changing the LDAP bind user path to cn=ldapservice,ou=users,ou=mail,dc=ldap,dc=example,dc=com to match the Provider Base DN as seen here:

I got a slightly different error this time:
ldap_bind: Invalid credentials (49)

container logs:
ldap-1 | {"bindDN":"cn=ldapservice,ou=users,ou=mail,dc=ldap,dc=example,dc=com","client":"<REDACTED>","error":"unsupported challenge type ak-stage-flow-error","event":"failed to execute flow","level":"warning","requestId":"9203746c-a5a3-481d-a287-4da6bc71c844","timestamp":"2024-09-17T02:32:54Z"}' 'ldap-1 | {"bindDN":"cn=ldapservice,ou=users,ou=mail,dc=ldap,dc=example,dc=com","client":"<REDACTED>","event":"Bind request","level":"info","requestId":"9203746c-a5a3-481d-a287-4da6bc71c844","timestamp":"2024-09-17T02:32:54Z","took-ms":1902}

[BeryJu]

there were some bugs for this that are fixed on 2024.8
also from the ldap container logs it looks like the outpost version doesn't match the authentik version

[pizzaandcheese]

I am using the manual outpost method for my LDAP outpost found here does this not get updated at the same frequency as everything else?

As I use docker-compose I update everything at the same time.

I also have already updated to 2024.8.2 with no fix yet :(

[BeryJu]

the latest image gets updated at the same time, but I recommend explicitly using a version tag. On startup the outpost prints which version it is, could you post the logs from the container start?

[pizzaandcheese]

ldap-1 | {"event":"Loaded config","level":"debug","path":"inbuilt-default","timestamp":"2024-09-18T02:01:04Z"}
ldap-1 | {"event":"Loaded config from environment","level":"debug","timestamp":"2024-09-18T02:01:04Z"}
ldap-1 | {"event":"not enabling debug server, set 'AUTHENTIK_DEBUG' to 'true' to enable it.","level":"info","logger":"authentik.go_debugger","timestamp":"2024-09-18T02:01:04Z"}
ldap-1 | {"event":"Successfully connected websocket","level":"info","logger":"authentik.outpost.ak-ws","outpost":"06eede47-1a5b-4d52-9637-163f8da28cbf","timestamp":"2024-09-18T02:01:05Z"}
ldap-1 | {"event":"Fetching certificate and private key","level":"info","logger":"authentik.outpost.cryptostore","timestamp":"2024-09-18T02:01:05Z","uuid":"70e10b96-8b04-4a5b-8a6c-5c0f6379ed9a"}
ldap-1 | {"event":"initialised direct binder","level":"info","logger":"authentik.outpost.ldap.binder.direct","timestamp":"2024-09-18T02:01:06Z"}
ldap-1 | {"event":"Update providers","level":"info","logger":"authentik.outpost.ldap","timestamp":"2024-09-18T02:01:06Z"}
ldap-1 | {"event":"Starting LDAP SSL server","level":"info","listen":"0.0.0.0:6636","logger":"authentik.outpost.ldap","timestamp":"2024-09-18T02:01:06Z"}
ldap-1 | {"event":"Starting Metrics server","level":"info","listen":"0.0.0.0:9300","logger":"authentik.outpost.metrics","timestamp":"2024-09-18T02:01:06Z"}
ldap-1 | {"event":"Starting LDAP server","level":"info","listen":"0.0.0.0:3389","logger":"authentik.outpost.ldap","timestamp":"2024-09-18T02:01:06Z"}
ldap-1 | {"event":"Starting authentik outpost","hash":"tagged","level":"info","logger":"authentik.outpost","timestamp":"2024-09-18T02:01:06Z","version":"2024.8.2"}
ldap-1 | {"event":"initialised direct binder","level":"info","logger":"authentik.outpost.ldap.binder.direct","timestamp":"2024-09-18T02:01:07Z"}
ldap-1 | {"event":"Update providers","level":"info","logger":"authentik.outpost.ldap","timestamp":"2024-09-18T02:01:07Z"}

[McGeaverBeaver]

Same issue here, LDAP is broken. Outpost has been updated to the latest version [2024.8.2]

{"bindDN":"cn=user@name.com,ou=users,dc=ldap,dc=domain,dc=com","client":"192.168.10.1","error":"unsupported challenge type ak-stage-flow-error","event":"failed to execute flow","level":"warning","requestId":"d95cc463-d433-4f2a-8f1a-cdf7156697cc","timestamp":"2024-09-18T13:21:32Z"}
{"bindDN":"cn=user@name.com,ou=users,dc=ldap,dc=domain,dc=com","client":"192.168.10.1","event":"Bind request","level":"info","requestId":"d95cc463-d433-4f2a-8f1a-cdf7156697cc","timestamp":"2024-09-18T13:21:32Z","took-ms":356}

[pizzaandcheese]

I managed to figure this out.

After reading through the LDAP Provider setup found here I noticed that my stage bindings were different than what was in the guide. Below is an image of what I had in my stage bindings.

I deleted the Password Stage binding and everything worked!

I'm not entirely sure why this stage binding was here, but oh well.

Check yours @McGeaverBeaver maybe its the same issue?

[McGeaverBeaver]

Yes, nice @pizzaandcheese .. Fixed as well now. I had to edit the " ldap-auth-stage " to have a password stage..

and I deleted teh password stage in binding..

resolved.