szaimen
commented
1 year ago Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
Hi,
We're in the process of adding SAML authentication to our existing nextcloud which currently has LDAP authentication.
Since we never explicitly configured the attribute to use for the internal username it's currently based on the entryUUID of the user in LDAP.
We want SAML authentication to only allow if the user is known in another database (LDAP). To get this to work with the entryUUID as the internal username, we return a SAML attribute that contains the entryUUID from LDAP and configure this attribute in the nextcloud SAML settings. This way, existing users can log in using SAML as they are already in the database with that internal username.
If a user is not (yet) in the database, nextcloud performs an LDAP search for the specified user. Since the username is the entryUUID, we've added the entryUUID field to the list of fields to search for users. As mentioned issue 16173, this results in an LDAP search for the configured fields with a * appended to make it a substring search.
However the entryUUID field in LDAP does not allow substring searches, so it returns no results, and the user is not found. If the LDAP search would search for the username without the * appended to it, the LDAP search would work and the user would be found.
For example:
ldapsearch -x entryUUID=f9af84f1-b87a-4266-864f-904e5fbe4a40 entryUUID => This returns the entry with this ID
ldapsearch -x entryUUID=f9af84f1-b87a-4266-864f-904e5fbe4a40* entryUUID => This does not return any entries.
Unless I'm missing something it does not seem to be possible to get this to work if the defaults were initially used for the LDAP settings (use the entryUUID as the internal username)?
What is the rationale for adding the * to make it a wildcard search in LDAP? Is this configurable somehow? Since the entryUUID is an internal attribute, it's not possible to extend the schema to make substring searches possible?
Regards, Rik