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

Re: idassert-bind seems to ignore binddn

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
binddn="uid=my_id,ou=my_dept,dc=company,dc=com"
credentials="mypass"

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


Ryan

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
        <http://ldap.example.com>"
             idassert-bind   bindmethod=simple
                             binddn="cn=Proxy,dc=example,dc=com"
                             credentials=proxy
                             authzID="dn:cn=Sandbox,dc=example,dc=com"
        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.



    Ryan

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

        Hi,
        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.

        Cheers.


        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:


                Hello,


                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


            --

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



        --
        *Abdelhamid Meddeb*
        http://www.meddeb.net





--
*Abdelhamid Meddeb*
http://www.meddeb.net

Attachment: smime.p7s
Description: Signature cryptographique S/MIME