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
--On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett 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
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 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
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@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 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
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 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@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 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
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
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@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@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 andcollaboration
-- *Abdelhamid Meddeb* http://www.meddeb.net-- *Abdelhamid Meddeb* http://www.meddeb.net
Am Fri, 1 May 2015 09:58:35 -0700 schrieb Ryan Lovett rylo@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
openldap-technical@openldap.org
-
Abdelhamid Meddeb -
Dieter Klünter -
Quanah Gibson-Mount -
Ryan Lovett