5:32 p.m.
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 this
slapd.conf:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
moduleload back_ldap
sizelimit 500
tool-threads 1
backend ldap
database ldap
suffix "dc=company,dc=com"
uri ldap://ldap.company.com:389
idassert-bind bindmethod=simple
binddn="uid=my_id,ou=my_dept,dc=company,dc=com"
credentials="mypass"
authcId="dn:uid=my_id,ou=my_dept,dc=company,dc=com"
mode=legacy
ldap.company.com permits the my_id DN to access privileged attributes that
anonymous users cannot. I can run ldapsearch against ldap.company.com with
simple auth, binding as my_id, and view the privileged attributes.
ldapsearch -H ldap://ldap.company.com:389 -LLL -x \
-b ou=users,dc=company,dc=com \
-W -D uid=my_id,ou=my_dept,dc=company,dc=com \
"(uid=12345)"
When I run ldapsearch against my proxy slapd with the above slapd.conf
however...
ldapsearch -H ldap://myproxy.company.com:389 -LLL -x \
-b ou=users,dc=company,dc=com \
"(uid=12345)"
... a packet trace shows that slapd is connecting to ldap.company.com
without binding as my_id:
LDAPMessage bindRequest(1) "<ROOT>" simple
messageID: 1
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: simple (0)
simple: <MISSING>
As a result I do not see the privileged attributes.
Based on the docs
<http://manpages.ubuntu.com/manpages/trusty/man5/slapd-ldap.5.html>;, I've
chosen mode=legacy because I'd like for the proxy to "perform a simple bind
as the authcDN ... and assert the client's identity when it is not
anonymous."
I've also tried following the advice at
http://www.openldap.org/faq/data/cache/532.html which states:
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.
yielding:
idassert-bind bindmethod=simple
binddn="uid=my_id,ou=my_dept,dc=company,dc=com"
credentials="mypass"
mode=none
But an ldapsearch of my proxy then reports "Inappropriate authentication
(48)" which I don't understand because client-to-proxy and proxy-to-remote
all use simple auth.
What am I doing wrong? Any advice is greatly appreciated!
Ryan
6:25 p.m.
--On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett <rylo(a)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
12:28 a.m.
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(a)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
9:58 a.m.
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
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(a)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(a)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
10:48 a.m.
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(a)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
> 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(a)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(a)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
>
>
11:52 a.m.
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(a)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(a)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(a)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
1:56 p.m.
There was no change unfortunately, but thank you for the suggestion.
idassert-bind bindmethod=simple
binddn="uid=my_id,ou=my_dept,dc=company,dc=com"
credentials="mypass"
authzId="dn:uid=my_id,ou=my_dept,dc=company,dc=com"
idassert-authzFrom "dn.regex:.*"
Ryan
On Fri, May 1, 2015 at 11:52 AM, Abdelhamid Meddeb <abdelhamid(a)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
> 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(a)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(a)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(a)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
12:53 a.m.
Am Fri, 1 May 2015 09:58:35 -0700
schrieb Ryan Lovett <rylo(a)berkeley.edu>:
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
> 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.
[...]
did you create a authz-policy rule in slapd.conf?
did you add an autzTo attribute to the entry cn=Proxy,dc=example,dc=com=
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
2959
days inactive
2959
days old
openldap-technical@openldap.org
7 comments
4 participants
participants (4)
-
Abdelhamid Meddeb -
Dieter Klünter -
Quanah Gibson-Mount -
Ryan Lovett