Bug 1381687

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.

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

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

(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.

(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

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

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