Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP search permissions no longer work #11404

Open
pizzaandcheese opened this issue Sep 17, 2024 · 7 comments
Open

LDAP search permissions no longer work #11404

pizzaandcheese opened this issue Sep 17, 2024 · 7 comments
Labels
bug Something isn't working

Comments

@pizzaandcheese
Copy link

pizzaandcheese commented Sep 17, 2024

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
Screenshot_20240916_211159
Screenshot_20240916_211343
Screenshot_20240916_211419

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 pizzaandcheese added the bug Something isn't working label Sep 17, 2024
@pizzaandcheese
Copy link
Author

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:
Screenshot_20240916_213426-1

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
Copy link
Member

BeryJu commented Sep 17, 2024

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
Copy link
Author

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
Copy link
Member

BeryJu commented Sep 17, 2024

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
Copy link
Author

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
Copy link

McGeaverBeaver commented Sep 18, 2024

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

{"bindDN":"cn=[email protected],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=[email protected],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
Copy link
Author

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.

Screenshot_20240922_170549

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants