pfSense

<authserver>
            <refid>625fe60aa1df2</refid>
            <type>ldap</type>
            <name>JumpCloud</name>
            <ldap_caref>global</ldap_caref>
            <ldap_certref></ldap_certref>
            <host>ldap.jumpcloud.com</host>
            <ldap_port>389</ldap_port>
            <ldap_urltype>STARTTLS Encrypted</ldap_urltype>
            <ldap_protver>3</ldap_protver>
            <ldap_scope>one</ldap_scope>
            <ldap_basedn><![CDATA[ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com]]></ldap_basedn>
            <ldap_authcn><![CDATA[ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com]]></ldap_authcn>
            <ldap_extended_enabled>yes</ldap_extended_enabled>
            <ldap_extended_query><![CDATA[&amp;(objectClass=inetOrgPerson)(memberOf=cn=VPN,ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com)]]></ldap_extended_query>
            <ldap_attr_user><![CDATA[uid]]></ldap_attr_user>
            <ldap_attr_group><![CDATA[cn]]></ldap_attr_group>
            <ldap_attr_member><![CDATA[member]]></ldap_attr_member>
            <ldap_attr_groupobj><![CDATA[groupOfNames]]></ldap_attr_groupobj>
            <ldap_pam_groupdn></ldap_pam_groupdn>
            <ldap_binddn><![CDATA[uid=binddn,ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com]]></ldap_binddn>
            <ldap_bindpw><![CDATA[secret_squirrel_bind_password]]></ldap_bindpw>
            <ldap_timeout>25</ldap_timeout>
            <ldap_rfc2307_userdn></ldap_rfc2307_userdn>
        </authserver>

.

I think this is probably still not right.

Extended query works.

RFC2307 groups work.

Authentication fails when both are enabled.

The site I'm testing against is SSL so I have no visibility. I need to spin up another LDAP server that supports memberOf to test it in-the-clear which is a non-trivial project.

OK. It looks like it is combining the RFC2307 query and the extended query into something that cannot match when both extended query and RFC2307 groups are enabled. This is after the initial DN search and bind as the authenticating user. In other words, during the extended query. Since this must return success for the extended query to work, it always fails.

Filter: (&(member=uid=cjl,cn=users,cn=accounts,dc=example,dc=com)(memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com))

The extended query is set to memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com and member is the RFC2307 group attribute that is in the posixGroup entries. Both of those filters will never match a posixUser entry.

I believe it should initially filter on (&(DN_RETURNED_BY_INITIAL_SEARCH)(memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com))

Then it should move on to processing the RFC2307 group memberships.

(&(DN_RETURNED_BY_INITIAL_SEARCH)(memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com))

That doesn't work. The DN doesn't match.

This works: (&(uid=cjl)(memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com))

I don't know if that's too broad - possibly including other entries.

Uncle Internet says to do this to limit the search to one DN:

ldapsearch -x -D 'uid=binduser,cn=sysaccounts,cn=etc,dc=example,dc=com' -b 'uid=cjl,cn=users,cn=accounts,dc=example,dc=com' -s base -W '(memberOf=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com)'

I improved the LDAP debug logging a bit over on #13718 which may help here as well.