Project

General

Profile

Actions

Bug #13093

open

LDAP authentication fails with extended query and RFC2307 group lookups enabled

Added by Chris Linstruth over 2 years ago. Updated almost 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Authentication
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:

Description

LDAP authentication fails with extended query and RFC2307 group lookups enabled

With Extended Query On and RFC2307 Groups off (Works):

First (Why is it searching that base?):

Base
uid=testuser,ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(uid=testuser)
Number of Results
0

Then:

Base
ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(&(uid=testuser)(&(objectClass=inetOrgPerson)(memberOf=cn=vpn,ou=users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com)))
Number of Results
1

Then:

Bind to:
User testuser authenticated successfully. This user is a member of groups:

With Extended Query off and RFC2307 Groups on, Use DN for username search on (Works):

First:

bind to 
Distinguished Name
uid=testuser,ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Successful

Then:

Base
ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(uid=testuser)
Number of Results
1

Then (Yes, it was logged twice):

Base
ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(uid=testuser)
Number of Results
1

Then:

Base
ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(&(objectClass=groupOfNames)(member=uid=testuser,ou=users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com))
Number of Results
3
User testuser authenticated successfully. This user is a member of groups:
Nextcloud
VPN

With Extended Query on and RFC2307 Groups on, Use DN for username search on (Fails):

Base
ou=Users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com
Search Filter
(&(member=uid=testuser,ou=users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com)(&(objectClass=inetOrgPerson)(memberOf=cn=vpn,ou=users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com)))
Number of Results
0
The following input errors were detected:
Authentication failed.

This looks like it is putting the extended query where it does not belong. It also looks like it is searching for the user as if it was a group with the member=uid=testuser,ou=users,o=9c65b5a4c5d919372fee0eee,dc=jumpcloud,dc=com query but it's also setting an objectClass=inetOrgPerson which is never going to succeed.

To me it should perform the user search with the extended query to get the DN then use that DN to search groupOfNames for the member=

Seems like it should test the bind to authenticate the user before the group search just to save unnecessary lookups if the authentication is just going to fail.

One should be able to use an extended query to limit the users to a specific group and do a query to get the list of groups the user is a member of. That does not look to be possible currently.


Related issues

Related to Feature #9527: Add ability for LDAP extended query on groups in RFC2307 containers.ResolvedSteve Powers05/16/2019

Actions
Actions #1

Updated by Viktor Gurov over 2 years ago

  • Related to Feature #9527: Add ability for LDAP extended query on groups in RFC2307 containers. added
Actions #2

Updated by Viktor Gurov over 2 years ago

  • Affected Version set to 2.6.0
Actions #3

Updated by Viktor Gurov over 2 years ago

  • Assignee set to Viktor Gurov
  • Target version set to 2.7.0
  • Plus Target Version set to 22.05

I found an issue where the Extended query is always used, regardless of the "Enable extended query" checkbox:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/746

But unable to reproduce other issues.
Could you provide a sanitized <authserver> config entry to check?

Actions #4

Updated by Chris Linstruth over 2 years ago

<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>
Actions #5

Updated by Chris Linstruth over 2 years ago

.

Actions #6

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Feedback

The PR above was merged a while ago, needs re-tested.

If there is still a problem this should be moved to 22.09 so we have more time to work out the details.

Actions #7

Updated by Chris Linstruth over 2 years ago

I think this is probably still not right.

Actions #8

Updated by Chris Linstruth over 2 years ago

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.

Actions #9

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to In Progress
  • Assignee changed from Viktor Gurov to Chris Linstruth
  • Plus Target Version changed from 22.05 to 22.09

OK, we'll nudge this forward for now and proceed once we have more detail.

Actions #10

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 22.09 to 22.11
Actions #11

Updated by Chris Linstruth over 2 years ago

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.

Actions #12

Updated by Chris Linstruth over 2 years ago

(&(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)'

Actions #13

Updated by Chris Linstruth over 2 years ago

  • Assignee deleted (Chris Linstruth)
Actions #14

Updated by Jim Pingle almost 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #15

Updated by Jim Pingle almost 2 years ago

  • Assignee set to Jim Pingle

I'll poke at this and see what I can turn up. Apparently both of my lab LDAP servers are broken in different ways at the moment so I need to fix those up first.

Actions #16

Updated by Jim Pingle almost 2 years ago

  • Status changed from In Progress to Feedback
  • Target version deleted (2.7.0)
  • Plus Target Version deleted (23.01)

OK this may be another case where it's the LDAP schema at play.

If your groups are not in the same container as the users, you need to adjust the authentication containers so it searches the whole tree.

I have my LDAP directory setup with a base DN of dc=example,dc=com and under there I have an ou of people for users and groups for groups and then under those I have users and groups in their respective containers.

So following that I had set the base DN to dc=example,dc=com and the authentication container to ou=people,dc=example,dc=com. Like you, I saw the same kind of failures.

Then I set my authentication container to dc=example,dc=com and it worked.

I have RFC2307 checked and I set an extended filter to search in:

&(objectClass=posixGroup)(cn=VPNUsers)(memberUid=*)

Note: Also beware that the extended filter will automatically be put in () so you should leave those off the extended query value entered in the GUI as I did here.

Which results in a group search of:

(&(memberUid=jimp)(&(objectClass=posixGroup)(cn=VPNUsers)(memberUid=*)))

Which returns the expected result, and I confirmed that also in Apache Directory Studio with the same search.

If I try to login with a user who is a member of VPNUsers, it works. If I try to login as a user who is not a member of VPNUsers, it fails as expected. So that seems to be the expected behavior for RFC2307+Extended filter, is it not?

Though looking above, yours uses memberOf which isn't RFC2307 style so the box would be unchecked if it's really done that way on that server. The box is only checked for LDAP servers where the group object has entries listing the member user IDs and not the other way around (user objects list member groups).

Taking the version off here since it's not clear there really is a bug beyond what was already committed on a previous version here.

Actions #17

Updated by Jim Pingle almost 2 years ago

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

Actions

Also available in: Atom PDF