On Tuesday 28 February 2012 14:27:36 Aleksander Machniak wrote: > While configuring ownCloud to use LDAP as user database we've found a > lot of issues with sharing and LDAP. Here are some thoughts. We've made > tests two months ago using git version, so maybe something's changed > since then? Thank you for your tests! I like to address your points and give some updates:
> - Authenticating against LDAP does not create the owncloud equivalent of > a user account, and therefore sharing with permissions is not working, These are two different things. Sharing with permissions is not dependent on local accounts. Is there another reason for them? However, you can have it working :) master has kind of some troubles because of a construction site in another aspect, but you can use stable branch and enhance it. This is clearly a candidate for the next maintenance release: Stable branch + current user_ldap from master + the database structure change from https://gitorious.org/owncloud/owncloud/commit/9df193f051c683fe69f9451ba07c4d34d480b76f/diffs/ca874a3ad776c9fd22c7bcbad81f493cfc551661 + current files_sharing from master (+ The fileeditor has a bug which opens writable files in readonly mode, this can be used by current files_texteditor from master without the spelling correction from https://gitorious.org/owncloud/owncloud/commit/30673e478672af316c057f562a8a02babdbd3160 or maybe with the whole commit) > - It's referring to group members by uid instead of oc_users.id, so name > changes become difficult, Well, we do not have an ID in the oc_users table, but LDAP users are not in this table anyway. Even if we would create local users, we would need to detect the change of a user name. It looks like it is not possible to see the username history in the user object. Thus LDAP would need to tell ownCloud which name changed. It should not be a problem to offer an interface therefore, the question is if the underlying LDAP is able to notifiy about changes or if it can be established easily. ownClouds native user managment does not allow user name changes, but of course we cannot ignore different behaviour on other backends :) Possibly we can add/set an identifying user attribute on LDAP, which we can use internally instead of the uid. Besides, currently it is possible to define a different attribute as user name. We are considering to switch to IDs in one of the next releases. > - It's referring to groups by gid instead of oc_groups.id > (it doesn't have an id field for oc_groups nor oc_users tables, in fact) > the oc_principals table is also referring to the uid text instead of the > local account id, There is no group backend for LDAP (yet). Besides, the story of groups and gids is the same as for users and user-ids. > - It should use the user's bind credentials, and not the service bind > credentials, To perform LDAP searches? For Univention we create an extra LDAP-user who is able to search the LDAP, but has no other function. And not always every user is allowed to perform searches. The thing is: we need to store the password in a way that it either can be computed back or directly in plain text. Thing is: if someone gets access to the machine, he will find out either way. In this case is more to secure not to use user credentials, but to have distinct credentials therefore. Even the password can be changed every now and then without much trouble. It is possible to offer the option to use user bind credentials, but i really dislike the idea becaues of this. > - It attempts to create a full list of usernames for auto-completion, > which it shouldn't do for lists of usernames can get rather large. Meanwhile, you can specifiy the filter for the user list. Still it can become pretty large if there are a lot of users that should have access to ownCloud. But you can get rid of unneeded accounts. I would appreciate if the current LDAP backend could be tested. Yet it is not much different from before, besides the aspects of the extended_ldap are integrated and the user list filter can be configured. Cheers Arthur _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
