Open Ma27 opened 4 months ago
The definitely sounds like a bug, after successfully binding the outpost uses the /core/applications/{slug}/check_access/
API with the session that was just authenticated by the flow and thus it should correctly check access to the correct application. Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.
Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.
Sorry, should've mentioned that, they do indeed (all the stuff used the same OpenLDAP server before, so I decided to keep the base DN to make it a little easier).
Having multiple LDAP providers with the same Base DN is supported, however they can't be in the same outpost
So I hope I didn't just miss it in the docs somewhere, but I think it might help to display a warning if that is about to be configured, no?
There is a note towards the top of https://docs.goauthentik.io/docs/providers/ldap/, but it should definitely also be shown in the admin UI
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I think displaying a warning should be done here since it's very painful to debug if you made the mistake.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Describe the bug When having two applications (called A, B) bound to an LDAP outpost and A has a User/Group binding, the LDAP bind against B breaks with "Insufficient access" if the service account for B isn't allowed in A's user/group binding.
To Reproduce
You'll get an "Insufficient access" error now whereas binding as "hydra" works fine. The workaround is to grant "nextcloud-user-sync" access to the Hydra application.
Expected behavior
I'm not sure. At first, I thought that this is clearly a bug, but then I realized that this is potentially expected behavior since you don't want to allow binding against an application with user/group restrictions (even if it's just the service account for another application).
OTOH this behavior was pretty unexpected to me, so I'd expect to have a warning at least in the UI. Or maybe even in the logs (i.e.
user denied because of user/group bindings from application hydra
).Another option would be to always let the binds of service accounts through.
In other words: this may be an issue, but I'm not sure yet what's the best solution out of it.
Screenshots n/a
Logs n/a
Version and Deployment (please complete the following information):
Additional context n/a