* reading the config directly will return the value with line breaks
* using the proper accessor gives us all bases in an array
* returns the first matching one
* having user id provided for the group base is strange and does not let
us operate like this. here we return the first one. might change in
future, a backportable fix won't have an API change however.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
there is not such strange return mode. Having invalid user ids caused this
check to fail, and as side effect share limitation to groups to not work.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
* uniqueMember was the default so we did not know whether this setting is
desired or the initial value
* autodetection of the user-group association attribute runs only when it
was not set (as far as we knew)
* the default is now empty
* thus LDAPProvider might return this value as well (in exceptional cases)
* if a group base is given (edge case), use this instead of general base
* resolves#12682
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
LDAP plugins must change the createUser method to return the DN, as we
need this to update the cache.
Signed-off-by: Vinicius Cubas Brand <viniciuscb@gmail.com>
This commit fix an error happening when the subadmin tries to create an
user, adding him/her to the group s/he is subadmin of, using a LDAP
User/Group plugin.
This just forces the cache to be reset after an user is added to a
group.
Signed-off-by: Vinicius Cubas Brand <viniciuscb@gmail.com>
Nested groups are now cached in a CappedMemoryCache object to reduce
queries to the LDAP backend.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
The previous patch fixed the problem only for one level of indirection
because groupsMatchFilter() had been applied on each recursive call (and
thus there would be no second level if the first level fails the check).
This new implementation replaces the recursive call with a stack that
iterates all nested groups before filtering with groupsMatchFilter().
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
Currently groupsMatchFilter is called before nested groups are resolved.
This basicly breaks this feature since it is not possible to inherit
membership in a group from another group.
Minimal example:
Group filter: (&(objectClass=group),(cn=nextcloud))
Nested groups: enabled
cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local
objectClass: group
cn=IT,ou=groups,dn=company,dn=local
objectClass: group
memberOf: cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local
cn=John Doe,ou=users,dn=company,dn=local
objectClass: person
memberOf: cn=IT,ou=groups,dn=company,dn=local
Since 'cn=IT,ou=groups,dn=company,dn=local' doesn't match the group
filter, John wouldn't be a member of group 'nextcloud'.
This patch fixes this by filtering the groups after all nested groups
have been collected. If nested groups is disabled the result will be the
same as without this patch.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
* handler registered upon OCA\\Files_External::loadAdditionalBackends
event as user_ldap is loaded before files_external
* new configuration field "ldapExtStorageHomeAttribute" (not in GUI yet)
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
otherwise they will be skipped when the results is being formatted and the
lower-cased result keys do not match.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
parallel search is not compatible with paged search, but the letter is
usually always applied.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
during login they might be cached as non-existing and cause an Exception
in the long run
reduces some duplication, too
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
LDAP servers respond with that even if a limit was passed with the
request. Having this statement logged causes a lot of confusion.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Just some house keeping. IUserTools with used in even older days for
easier creation of Access instances…
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>