[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: idassert-bind seems to ignore binddn

There was no change unfortunately, but thank you for the suggestion.

idassert-bind bindmethod=simple
idassert-authzFrom      "dn.regex:.*"


On Fri, May 1, 2015 at 11:52 AM, Abdelhamid Meddeb <abdelhamid@meddeb.net> wrote:
what happen if you add:

idassert-authzFrom      "dn.regex:.*"

to your configuration ?

Le 01/05/2015 19:48, Ryan Lovett a écrit :
Note that I can get access to the privileged attributes if the
ldapsearch client binds to the proxy using a rootdn/rootpw, e.g.

rootdn "cn=proxy,dc=company,dc=com"
rootpw "proxypass"
idassert-bind bindmethod=simple

$ ldapsearch ... -D cn=proxy,dc=company,dc=com -W


On Fri, May 1, 2015 at 9:58 AM, Ryan Lovett <rylo@berkeley.edu
<mailto:rylo@berkeley.edu>> wrote:

    According to
    http://www.openldap.org/faq/data/cache/532.html, idassert-authzFrom
    is not needed in this case. Here is the example:

        To allow (dumb) clients that do not perform bind to access
        servers that require bind (and some ssf) by asserting some
        static identity (the dn:<dn>, or even the anonymous mode, to
        implement the "sandbox" user described above) without any
        idassert-authzFrom rule in place:
        database        ldap
             suffix          "dc=example,dc=com"
             uri             "ldap://ldap.example.com
             idassert-bind   bindmethod=simple
        If no authzID is given, and mode is set to none (for instance
        because the remote server does not support the proxyAuthz
        control), the clients will be authorized as
        "cn=Proxy,dc=example,dc=com" even if they actually connected
        anonymously to the proxy. Beware that this may be a significant
        security breach, if that identity is granted anything but
        anonymous read privileges.


    On Fri, May 1, 2015 at 12:28 AM, Abdelhamid Meddeb
    <abdelhamid@meddeb.net <mailto:abdelhamid@meddeb.net>> wrote:

        In addition to ancient version, and according to reported
        configuration you are missed idassert-authzFrom setting. more
        details in slapd.conf(5).
        Without this parameter you may have this issue.


        Le 01/05/2015 03:25, Quanah Gibson-Mount a écrit :

            --On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett
            <rylo@berkeley.edu <mailto:rylo@berkeley.edu>> wrote:


                I've setup a simple proxy so that local LDAP clients can
                get access to
                protected attributes on a remote server. My proxy is
                slapd 2.4.31 with

                What am I doing wrong? Any advice is greatly appreciated!

            The first thing you're doing wrong is running a version of
            OpenLDAP that
            is so ancient.

            OpenLDAP 2.4.31 Release (2012/04/21)

            I.e., it's over 3 years old.

            There have been multiple fixes to slapd-ldap since that
            release.  This
            one in particular may be related:

            OpenLDAP 2.4.33 Release (2012/10/10)
                     Fixed slapd-ldap idassert bind handling (ITS#7403)



            Quanah Gibson-Mount
            Platform Architect
            Zimbra, Inc.
            Zimbra ::  the leader in open source messaging and collaboration

        *Abdelhamid Meddeb*

*Abdelhamid Meddeb*