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

"Search full LDAP directory" doesn't actually work #11548

Open
Banh-Canh opened this issue Sep 27, 2024 · 12 comments
Open

"Search full LDAP directory" doesn't actually work #11548

Banh-Canh opened this issue Sep 27, 2024 · 12 comments
Labels
bug Something isn't working

Comments

@Banh-Canh
Copy link

Describe the bug
"Search full LDAP directory" doesn't actually work.

To Reproduce
Steps to reproduce the behavior:

Add "Search full LDAP directory" permission to a freshly created user/serviceaccount. Then run the query:

ldapsearch -x -H ldap://<outpost-ldap>:389 -D 'cn=ldapbind,ou=users,DC=ldap,DC=goauthentik,DC=io'  -w 'xxx'  -b 'OU=users,DC=ldap,DC=goauthentik,DC=io' '(objectClass=user)

It only returns the binduser.
If I ran the same command after I gave superuser permission to the bind user, it just work and i get the whole directory of users.

Expected behavior
I should get the whole directory of user with this permission without superuser rights.

Version and Deployment (please complete the following information):

  • authentik version: 2024.8.3
  • Deployment: helm
@Banh-Canh Banh-Canh added the bug Something isn't working label Sep 27, 2024
@shawnbonifas
Copy link

I'm having the same issue here. I only just today set up the LDAP application, outpost, provider, flows, etc. so I don't know if it was working previously. If I use the akadmin account I can search for users and see all of them. Using the service account I created it can only find itself and the groups it's a member of. I have tried giving it superuser permission, all LDAP permissions, and all permissions to users the user search still only returns the bind user. I'm also using 2024.8.3, deployed using the helm template.

@DrMax1
Copy link

DrMax1 commented Oct 16, 2024

Same issue here. Using the "Search full LDAP directory" permission to the bind user makes the query only return the bind user itself.
After adding the bind user to the superuser group it returns all users in the current authentik instance.

Running 2024.8.3 with docker-compose

@BeryJu
Copy link
Member

BeryJu commented Oct 16, 2024

@DrMax1 @shawnbonifas @Banh-Canh are you assigning the search full LDAP directory to the service user within a single provider or globally?

Also try restarting the LDAP outpost after the permissions are assigned, this might be a caching part (it shouldn't but just to rule it out)

@DrMax1
Copy link

DrMax1 commented Oct 16, 2024

@DrMax1 @shawnbonifas @Banh-Canh are you assigning the search full LDAP directory to the service user within a single provider or globally?

Also try restarting the LDAP outpost after the permissions are assigned, this might be a caching part (it shouldn't but just to rule it out)

@BeryJu I am assigning the permission to the service user globally:

grafik

I restarted the LDAP outpost and also set the provider to direct binding and querying to avoid caching issues.

I also tried downgrading to Version 2024.8.2 but the issue persists.

@francescor
Copy link

We confirm this bug: lost a lot of hours debugging today: the problem is with 2024.8.3 while it's OK with 2024.6.1

In https://version-2024-8.goauthentik.io/docs/providers/ldap/ I read

INFO
Up to authentik version 2024.8 this was managed using the "Search group" attribute in the LDAP Provider, where users could be added to a group to grant them this permission. With authentik 2024.8 this is automatically migrated to the "Search full LDAP directory" permission, which can be assigned more flexibly.

So, we are stuck

@francescor
Copy link

francescor commented Oct 22, 2024

These are the relative commits #10639

Updated: maybe we can solve this by working with roles?

@DrMax1
Copy link

DrMax1 commented Oct 22, 2024

These are the relative commits #10639

maybe we can solve this by working with roles?

Do you mean creating a role, assigning the "Search full LDAP directory" permission to said role, assigning this role to a group and then adding the relevant service users?

I tried it and it doesn't work either unfortunately. I think there must be an issue with the the permission in the authorization code.

@francescor
Copy link

I've figured out how to allow a user, in the context of this issue, to "Search full LDAP directory" without the need to make it a superuser (so without make it member of authentik Admins): as stated in the first comment in #10639 we need to use object permissions and not global permissions as we all did so far :(

So you need to have this

image

which can be accomplish by Application/Provider/Ldap Permissions TAB, then Assign new User

image

this way we have:

image

Et voilà

@francescor
Copy link

so I guess this issue can be easily solved just with few words in documentation

@DrMax1
Copy link

DrMax1 commented Oct 22, 2024

This actullay solved the problem! Thanks for tinkering around and finding the solution! :)

Would you mind starting a PR to add this to the documentation so it can help future users?

@perrze
Copy link
Contributor

perrze commented Oct 24, 2024

I've figured out how to allow a user, in the context of this issue, to "Search full LDAP directory" without the need to make it a superuser (so without make it member of authentik Admins): as stated in the first comment in #10639 we need to use object permissions and not global permissions as we all did so far :(

When you added the permission, did you need to restart the outpost container ? Because on my instance it was the only way that the permissions would be applied.

@francescor
Copy link

When you added the permission, did you need to restart the outpost container ? Because on my instance it was the only way that the permissions would be applied.

no, but you must be aware of the CACHE which I kept disable till I solve all setup

image

so, with a restart you probably flush caches

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

6 participants