"0 users found" when configuring LDAP auth with Posix groups

Sorry to hear you’re facing problems :slight_frown:

If you’re urgently looking for support to keep your business running, consider checking out our paid support options.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the following as you can (you can cut and paste this into your topic):


Nextcloud version (eg, 10.0.2): 11.02
Operating system and version (eg, Ubuntu 16.04): 14.04
Apache or nginx version (eg, Apache 2.4.25): 2.4.7-1ubuntu4.13
PHP version (eg, 5.6):PHP 7.0.16-3+deb.sury.org~trusty+1
Is this the first time you’ve seen this error?: no

Can you reliably replicate it? (If so, please outline steps): Configure LDAP auth

The issue you are facing: posix groups are found and selected under teh “Users” tab, however nextcloud reports “0 users found” when clicking Verify. The query building wrongly assumes this is a groupOfNames object when posixGroups have actually been selected.

(&(|(objectclass=inetOrgPerson))(|(memberof=cn=nextcloud,ou=groups,dc=myorg,dc=com)))

The output of your Nextcloud log in Admin > Logging:
{“reqId”:“qjJA8tYcYG9x3njrBr61”,“remoteAddr”:“10.14.13.1”,“app”:“user_ldap”,“message”:“Configuration Error (prefix ): login filter does not contain %uid place holder.”,“level”:2,“time”:“2017-03-01T22:16:37+00:00”,“method”:“GET”,“url”:"/ocs/v2.php/apps/notifications/api/v2/notifications",“user”:“admin”,“version”:“11.0.2.7”}

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php $CONFIG = array ( 'instanceid' => 'xxxxxxxxxxxxxxxx', 'passwordsalt' => 'xxxxxxxxxxxxxxxx', 'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'trusted_domains' => array ( 0 => 'wal.myorg.com', 1 => 'do.myorg.com', 2 => 'ig.myorg.com', ), 'datadirectory' => '/var/www/nextcloud_data', 'overwrite.cli.url' => 'http://localhost:8777', 'dbtype' => 'mysql', 'version' => '11.0.2.7', 'dbname' => 'mydb', 'dbhost' => 'localhost', 'dbport' => '', 'dbtableprefix' => 'oc_', 'dbuser' => 'xxxxxxxxxxxx', 'dbpassword' => 'xxxxxxxxxxxxx', 'logtimezone' => 'UTC', 'installed' => true, 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'memcache.local' => '\\OC\\Memcache\\APCu', 'redis' => array ( 'host' => '127.0.0.1', 'port' => 6379, ), 'ldapIgnoreNamingRules' => false, 'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory', ); The output of your Apache/nginx/system log in `/var/log/____`: 10.14.13.1 - - [01/Mar/2017:16:20:41 -0600] "POST /index.php/apps/user_ldap/ajax/wizard.php HTTP/1.1" 200 995 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0" 10.14.13.1 - - [01/Mar/2017:16:20:41 -0600] "POST /index.php/apps/user_ldap/ajax/wizard.php HTTP/1.1" 200 1166 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0" --- Remember, this information may be requested if it isn't supplied; for fastest response please provide as much as you can :heart: Feel free to use a pastebin service, otherwise log files can be indented with 4 spaces on each line to present them in a friendlier way on the forum.

are you using nested groups? or are all users directly inside of ‘cn=nextcloud,ou=groups,dc=myorg,dc=com’?
did you check the “Login Attributes” option in the LDAP configuration?

No, no nested groups. I have a hunch that Nextcloud will only work with groupOfNames objects in LDAP since it seems to specify memberOf for the Login attributes filter as well as the “user” filter. I would guess this is because the memberOf DN includes the full user’s DN instead of simply a CN, or other posix attribute for the username. I ended up creating a groupOfNames object in LDAP to get Nextcloud logins working. It’s just kind of redundant to have to maintain one group for Unix user support (posixGroups) and a “duplicate” user group for Nextcloud access.

you could try to build the correct filter-query in any other LDAP tool and then just copy the query-string. at least that’s what I did in the end, because the GUI just didn’t work for me…

as I understand your solution it’s a big workaround to something that should be solvable with the correct LDAP-filter(s).
i have absolutely no experience with LDAP besides AD, so please forgive me if I’m totally wrong about this and/or if you are happy with your solution, just ignore my comment :wink:

Hello, I am revisiting this again as I am creating another Nextcloud instance and have run into the same issue again.

I don’t think it is possible to use posixGroup for this. I say this because even under “LDAP Users” tab, Nextcloud does not allow to check for posixGroup as shown in the picture. I suspect there should be an item to check called posixGroup but it is not there. Strangely enough, the second pulldown, Only from these groups, lists my posix groups! (but you cannot see this in the picture).

If I create a query using ldapsearch on the cli, as you suggest, I can return membership from a posix group (as shown in the code below). Nextcloud just does not allow for filtering on posixGroup for some reason. Maybe I am missing something obvious but It sure seems to me that Nextcloud is just not supporting posix groups this way.

ldapsearch -x -ZZ ‘(&(objectClass=posixGroup)(&(gidNumber=2001)))’

dn: cn=nextcloud,ou=groups,dc=mycorp,dc=dot,dc=com
cn: nextcloud
gidNumber: 2001
objectClass: posixGroup
objectClass: top
memberUid: user111
memberUid: user232
memberUid: user333
memberUid: user444

very late answer, but i’m gonna try anyway.

i understand the setup options as follows:

1 - only find users with this objectclass (posixAccount)
2 - only find users within there groups
or
2 - only find users based on this query/filter

the first option defines which type of LDAP you are using. the second option defines which users in your LDAP to choose.
so there is no need to choose “posixGroup” from the list in the first option. you need to filter for “posixAccount” i guess.

Thanks for the late reply but I gave up on it and ended up making a groupOfNames object with user dn in member attributes. This actually works better as the dn includes the user’s ou which doesn’t work for posixGroup attribute. If a user exists in multiple ous, you can pick which one to allow.

i like that idea…!