Closed Ekleog closed 5 years ago
GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/10270 (LDAP wizard issue), https://github.com/nextcloud/server/issues/11113 (LDAP authentication assumes passwords are reusable), https://github.com/nextcloud/server/issues/5237 (inconsistent ldap connection), https://github.com/nextcloud/server/issues/3068 (LDAP: Quota issues), and https://github.com/nextcloud/server/issues/4177 (LDAP Integration - Bind failed: 49: Invalid credentials).
Currently trying to setup my nextcloud server to work with my LDAP server, it appears that it requires a system user with the ability to do searches across the whole LDAP directory.
Yes, https://docs.nextcloud.com/server/14/admin_manual/configuration_user/user_auth_ldap.html
OTOH, an a priori more secure variant would be to have nextcloud attempt to bind as the user requesting authentication, and if this succeeds then accept the login
Happens on login. The service user is then used anyway to ensure it has the necessary privileges. For sharing it is necessary to search the directory.
OTOH, an a priori more secure variant would be to have nextcloud attempt to bind as the user requesting authentication, and if this succeeds then accept the login
Happens on login. The service user is then used anyway to ensure it has the necessary privileges. For sharing it is necessary to search the directory.
Well, searching could search only in the list of users that have already been included in nextcloud's internal database. At least that how matrix.org's synapse is handling LDAP auth: an user can be contacted only when they have connected for the first time.
This avoids having to give nextcloud full-on read access to the whole database, including people who might not want to use it.
Well, searching could search only in the list of users that have already been included in nextcloud's internal database. At least that how matrix.org's synapse is handling LDAP auth: an user can be contacted only when they have connected for the first time.
We have the use case that people can be shared to, even when they did not log in yet. Also, you (as admin) define filters and thus control who is included, and who is not.
This avoids having to give nextcloud full-on read access to the whole database, including people who might not want to use it.
On the other hand we loose the ability for house keeping and background updates.
I'm closing this as it is not on our roadmap and it would fundamentally change the way we work with LDAP.
Currently trying to setup my nextcloud server to work with my LDAP server, it appears that it requires a system user with the ability to do searches across the whole LDAP directory.
OTOH, an a priori more secure variant would be to have nextcloud attempt to bind as the user requesting authentication, and if this succeeds then accept the login. This way, nextcloud never needs special setup in the LDAP server, and doesn't get privileges it's not supposed to have.
Currently, the only work-around I can think of would be to install an IMAP or FTP server that knows how to auth by LDAP bind and use the IMAP or FTP backends of nextcloud… not really a clean solution :)