Bug 1381687 - RFE: rgw ldap does not support custom ldap search filters
Summary: RFE: rgw ldap does not support custom ldap search filters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: RGW
Version: 2.1
Hardware: All
OS: All
medium
low
Target Milestone: rc
: 2.1
Assignee: Matt Benjamin (redhat)
QA Contact: Ramakrishnan Periyasamy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-04 18:20 UTC by Matt Benjamin (redhat)
Modified: 2017-07-30 15:49 UTC (History)
10 users (show)

Fixed In Version: RHEL: ceph-10.2.3-4.el7cp Ubuntu: ceph_10.2.3-5redhat1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-22 19:31:35 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Ceph Project Bug Tracker 17185 None None None 2016-10-05 19:13:54 UTC
Red Hat Product Errata RHSA-2016:2815 normal SHIPPED_LIVE Moderate: Red Hat Ceph Storage security, bug fix, and enhancement update 2017-03-22 02:06:33 UTC

Description Matt Benjamin (redhat) 2016-10-04 18:20:22 UTC
A need for custom search filters to identify users is common in LDAP deployments, and would be useful to customers and SAs.

Matches upstream tracker issue: http://tracker.ceph.com/issues/17185

Fixed in:
commit 4943fbf18442b623e23bc387d35c78b019ef1dcd
Author: Harald Klein <hari@vt100.at>
Date:   Wed Aug 31 17:41:26 2016 +0200

    add ldap auth custom search filter feature patch - http://tracker.ceph.com/issues/17185

Comment 4 Matt Benjamin (redhat) 2016-10-06 15:37:39 UTC
The primary verification of this change should be non-regression of ordinary LDAP authentication.

Secondarily, guidance can be found in the tracker issue on constructing common search filters, e.g., restriction on membership of an LDAP account entry in an LDAP group.

Comment 6 Ramakrishnan Periyasamy 2016-10-25 05:55:35 UTC
Hi Matt,

Please provide the rgw command or proper steps to verify this bug, step or command not clear in the bug or tracker.

Tracker says this 3 types of filters "Parameter set to empty , Parameter set to Partial, Parameter set to complete" but Where and how to use this filters in rgw ?

Regards,
Ramakrishnan

Comment 7 Matt Benjamin (redhat) 2016-10-26 15:36:47 UTC
(In reply to Ramakrishnan Periyasamy from comment #6)
> Hi Matt,
> 
> Please provide the rgw command or proper steps to verify this bug, step or
> command not clear in the bug or tracker.
> 
> Tracker says this 3 types of filters "Parameter set to empty , Parameter set
> to Partial, Parameter set to complete" but Where and how to use this filters
> in rgw ?
> 
> Regards,
> Ramakrishnan

Here's what I put in pastebin--basically, we need to refine this;  however, the exact filter shown below should succeed, and small permutations (e.g., alternate objectClass not mixed into user accounts by default) should work with MS AD:
 
# matt
 
        # LDAP service (ldaps:// is AD-compliant)
 
        rgw ldap uri = "ldaps://msad-frog.eng.arb.redhat.com"
        rgw ldap binddn = "CN=ceph,CN=Users,DC=msad-frog,DC=eng,DC=arb,DC=redhat,DC=com"
        rgw ldap secret = "/etc/bindpass"
        rgw ldap searchdn = "CN=Users,DC=msad-frog,DC=eng,DC=arb,DC=redhat,DC=com"
        rgw ldap searchfilter = "(&(cn=@USERNAME@)(objectClass=organizationalPerson))"
 
        rgw ldap dnattr = "cn"
        rgw s3 auth use ldap = true
 
#so, needs edit, but the above requires accounts to have a given objectClass--this one always succeeds for user accounts in default AD, iirc
# another kind of filter we should test is memberof a group--this is AD-specific syntax, iirc
#       (memberOf=cn=Test,ou=East,dc=Domain,dc=com)

Comment 8 Ramakrishnan Periyasamy 2016-10-27 06:32:06 UTC
(In reply to Matt Benjamin (redhat) from comment #7)
> (In reply to Ramakrishnan Periyasamy from comment #6)
> > Hi Matt,
> > 
> > Please provide the rgw command or proper steps to verify this bug, step or
> > command not clear in the bug or tracker.
> > 
> > Tracker says this 3 types of filters "Parameter set to empty , Parameter set
> > to Partial, Parameter set to complete" but Where and how to use this filters
> > in rgw ?
> > 
> > Regards,
> > Ramakrishnan
> 
> Here's what I put in pastebin--basically, we need to refine this;  however,
> the exact filter shown below should succeed, and small permutations (e.g.,
> alternate objectClass not mixed into user accounts by default) should work
> with MS AD:
>  
> # matt
>  
>         # LDAP service (ldaps:// is AD-compliant)
>  
>         rgw ldap uri = "ldaps://msad-frog.eng.arb.redhat.com"
>         rgw ldap binddn =
> "CN=ceph,CN=Users,DC=msad-frog,DC=eng,DC=arb,DC=redhat,DC=com"
>         rgw ldap secret = "/etc/bindpass"
>         rgw ldap searchdn =
> "CN=Users,DC=msad-frog,DC=eng,DC=arb,DC=redhat,DC=com"
>         rgw ldap searchfilter =
> "(&(cn=@USERNAME@)(objectClass=organizationalPerson))"
>  
>         rgw ldap dnattr = "cn"
>         rgw s3 auth use ldap = true

Added above mentioned information in the ceph.conf file under rgw section.
after adding this am able to get particular user bucket details.

[ubuntu@magna104 ~]$ sudo radosgw-admin bucket list --uid=tempuser2
[
    "abc",
    "ram",
    "sdf",
    "xys"
]

Changed the rgw ldap dnattr="" as per ldap behaviour it will construct its own search filter. in this case also above command was successful.

>  
> #so, needs edit, but the above requires accounts to have a given
> objectClass--this one always succeeds for user accounts in default AD, iirc
> # another kind of filter we should test is memberof a group--this is
> AD-specific syntax, iirc
> #       (memberOf=cn=Test,ou=East,dc=Domain,dc=com)

Please correct me if i am missing anything here, after confirmation i will move to verified state.

Comment 9 Matt Benjamin (redhat) 2016-10-27 13:25:39 UTC
(In reply to Ramakrishnan Periyasamy from comment #8)
> (In reply to Matt Benjamin (redhat) from comment #7)
> > (In reply to Ramakrishnan Periyasamy from comment #6)

> Please correct me if i am missing anything here, after confirmation i will
> move to verified state.

Hi Rmakrishnan,

I think this is the the expected/correct behavior.  I'm not aware of a specific need to widen the scope of filter testing, so I would support marking as verified.

Matt

Comment 10 Ramakrishnan Periyasamy 2016-10-27 16:22:54 UTC
Moving the bug to verified state as per comment8 and comment9.

Thanks Matt, thank you so much for helping me in verifying this bug. 

Regards,
Ramakrishnan

Comment 12 errata-xmlrpc 2016-11-22 19:31:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2815.html


Note You need to log in before you can comment on or make changes to this bug.