Hi,
Like a lot of people I guess, I'm having trouble configuring slapd to work as a proxy server in front of Microsoft's Active Directory. AD in this case is configured to refuse to allow anonymous searches but I want to allow anonymous searches on the proxy. Therefore the configuration I'm hoping for is:
* Anonymous binds to slapd get translated into an authenticated bind to AD. * Authenticated binds to slapd have their credentials (DN and password) passed through to AD.
Here's what I have so far, based on the documentation. I'm using slapd.conf rather than the new conf.d directory based config, and I'm currently running openldap 2.4.19:
-- database ldap chase-referrals no suffix "MY-AD-SUFFIX-HERE" uri "ldaps://MY-AD-SERVER-HERE/" cancel abandon
acl-bind bindmethod=simple binddn="VALID-BIND-DN" credentials="VALID-PASSWORD"
idassert-bind bindmethod=simple binddn="VALID-BIND-DN credentials="VALID-PASSWORD" mode=legacy flags=non-prescriptive
idassert-authzFrom "dn.regex:.*"
access to * by * read --
You can assume I've used valid bind DNs, suffixes, server names and passwords in the places where I've resorted to capitals above. I've tested these binds from the command line directly against the AD server and they all work.
I have tested the above on OpenLDAP 2.3, it works for anonymous binds if and only if a successful authenticated bind is done first. The same was reported in this post:
http://www.openldap.org/lists/openldap-technical/200907/msg00043.html
In OpenLDAP 2.4 it fails to recognise the idassert-bind completely, all attempts at anonymous bind seem to fail. A similar problem was reported while upgrading to 2.3.11 to 2.3.27, here:
http://www.openldap.org/lists/openldap-software/200701/msg00055.html
Am I using the correct configuration directives to achieve what I want, and if not what should I be using?
Thanx,
Just to elaborate on some of my own points below:
Like a lot of people I guess, I'm having trouble configuring slapd to work as a proxy server in front of Microsoft's Active Directory. AD in this case is configured to refuse to allow anonymous searches but I want to allow anonymous searches on the proxy. Therefore the configuration I'm hoping for is:
- Anonymous binds to slapd get translated into an authenticated bind to AD.
- Authenticated binds to slapd have their credentials (DN and password)
passed through to AD.
According to man slapd-ldap, which says:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_ciphersuite=<ciphers>] [tls_protocol_min=<version>] [tls_crlcheck=none|peer|all]
Allows to define the parameters of the authentication method that is internally used by the proxy to authorize connections that are authenticated by other databases. The identity defined by this directive, according to the properties associated to the authentication method, is supposed to have auth access on the target server to attributes used on the proxy for authentication and authorization, and to be allowed to authorize the users. This requires to have proxyAuthz privileges on a wide set of DNs, e.g. authzTo=dn.subtree:"", and the remote server to have authz-policy set to to or both. See slapd.conf(5) for details on these statements and for remarks and drawbacks about their usage. The supported bindmethods are
So it seems that this is the parameter I want.
none|simple|sasl
where none is the default, i.e. no identity assertion is performed.
I think I need "simple" here because I want OpenLDAP to do a simple bind (non-SASL) to AD.
... The supported modes are:
<mode> := {legacy|anonymous|none|self}
If <mode> is not present, and authzId is given, the proxy always authorizes that identity. <authorization ID> can be
u:<user>
[dn:]<DN>
The former is supposed to be expanded by the remote server according to the authz rules; see slapd.conf(5) for details. In the latter case, whether or not the dn: prefix is present, the string must pass DN validation and normalization.
The default mode is legacy, which implies that the proxy will either perform a simple bind as the authcDN or a SASL bind as the authcID and assert the client’s identity when it is not anonymous. Direct binds are always proxied. The other modes imply that the proxy will always either perform a simple bind as the authcDN or a SASL bind as the authcID, unless restricted by idassert-authzFrom rules (see below), in which case the operation will fail; eventually, it will assert some other identity according to <mode>.
It seems to me that I want mode=legacy according to this. I want it to perform a simple bind as some ID (VALID-BIND-DN below) when the client is anonymous, but assert the client's identity when it is not anonymous.
I have to say that the language of the manual here is far from clear. It doesn't actually define what is meant by "authcDN" for example, I'm only assuming that that means the "<simple DN>" given as the argument to the binddn option of this parameter. Also it could skip the double negatives.
However it doesn't appear to work. Any ideas?
Here's what I have so far, based on the documentation. I'm using slapd.conf rather than the new conf.d directory based config, and I'm currently running openldap 2.4.19:
-- database ldap chase-referrals no suffix "MY-AD-SUFFIX-HERE" uri "ldaps://MY-AD-SERVER-HERE/" cancel abandon
acl-bind bindmethod=simple binddn="VALID-BIND-DN" credentials="VALID-PASSWORD"
idassert-bind bindmethod=simple binddn="VALID-BIND-DN credentials="VALID-PASSWORD" mode=legacy flags=non-prescriptive
idassert-authzFrom "dn.regex:.*"
access to * by * read
You can assume I've used valid bind DNs, suffixes, server names and passwords in the places where I've resorted to capitals above. I've tested these binds from the command line directly against the AD server and they all work.
I have tested the above on OpenLDAP 2.3, it works for anonymous binds if and only if a successful authenticated bind is done first. The same was reported in this post:
http://www.openldap.org/lists/openldap-technical/200907/msg00043.html
In OpenLDAP 2.4 it fails to recognise the idassert-bind completely, all attempts at anonymous bind seem to fail. A similar problem was reported while upgrading to 2.3.11 to 2.3.27, here:
http://www.openldap.org/lists/openldap-software/200701/msg00055.html
Am I using the correct configuration directives to achieve what I want, and if not what should I be using?
Thanx,
Hi,
Like a lot of people I guess, I'm having trouble configuring slapd to work as a proxy server in front of Microsoft's Active Directory. AD in this case is configured to refuse to allow anonymous searches but I want to allow anonymous searches on the proxy. Therefore the configuration I'm hoping for is:
- Anonymous binds to slapd get translated into an authenticated bind to
AD.
- Authenticated binds to slapd have their credentials (DN and password)
passed through to AD.
Here's what I have so far, based on the documentation. I'm using slapd.conf rather than the new conf.d directory based config, and I'm currently running openldap 2.4.19:
-- database ldap chase-referrals no suffix "MY-AD-SUFFIX-HERE" uri "ldaps://MY-AD-SERVER-HERE/" cancel abandon
acl-bind bindmethod=simple binddn="VALID-BIND-DN" credentials="VALID-PASSWORD"
idassert-bind bindmethod=simple binddn="VALID-BIND-DN credentials="VALID-PASSWORD" mode=legacy flags=non-prescriptive
idassert-authzFrom "dn.regex:.*"
access to * by * read
You can assume I've used valid bind DNs, suffixes, server names and passwords in the places where I've resorted to capitals above. I've tested these binds from the command line directly against the AD server and they all work.
I have tested the above on OpenLDAP 2.3, it works for anonymous binds if and only if a successful authenticated bind is done first. The same was reported in this post:
http://www.openldap.org/lists/openldap-technical/200907/msg00043.html
In OpenLDAP 2.4 it fails to recognise the idassert-bind completely, all attempts at anonymous bind seem to fail. A similar problem was reported while upgrading to 2.3.11 to 2.3.27, here:
http://www.openldap.org/lists/openldap-software/200701/msg00055.html
Am I using the correct configuration directives to achieve what I want, and if not what should I be using?
As far as I recall, what you need is not possible. You can:
- have authenticated users proxied with their identity asserted, or
- all users, including unauthenticated ones auth'd as a fixed identity
but not both. Please note that you're asking OpenLDAP's slapd to bridge the gap between two broken pieces of code: clients that cannot be configured to bind, and AD that cannot be configured to accept anonymous requests (AFAIK). Feel free to suggest an enhancement that allows to handle this scenario, though.
p.
On Wednesday, 9 February 2011 01:13:38 masarati@aero.polimi.it wrote:
As far as I recall, what you need is not possible. You can:
have authenticated users proxied with their identity asserted, or
all users, including unauthenticated ones auth'd as a fixed identity
but not both. Please note that you're asking OpenLDAP's slapd to bridge the gap between two broken pieces of code: clients that cannot be configured to bind,
Because the OP wants to have anonymous access for some clients of the proxy does not necessarily mean the software is broken, there could be organisational reasons (e.g. AD administrator not prepared to create multiple proxy accounts for different applications).
and AD that cannot be configured to accept anonymous requests (AFAIK).
Again, AD can be configured to allow anonymous binds, but AFAIK as of Windows 2003, it is disabled by default, and many AD security standards (used by e.g. financial auditing companies in their IT auditing) mandate that it not be enabled.
Feel free to suggest an enhancement that allows to handle this scenario, though.
IMHO, it would make sense to support this mode of operation.
Regards, Buchan
Buchan Milne wrote:
On Wednesday, 9 February 2011 01:13:38 masarati@aero.polimi.it wrote:
As far as I recall, what you need is not possible. You can:
have authenticated users proxied with their identity asserted, or
all users, including unauthenticated ones auth'd as a fixed identity
but not both. Please note that you're asking OpenLDAP's slapd to bridge the gap between two broken pieces of code: clients that cannot be configured to bind,
Because the OP wants to have anonymous access for some clients of the proxy does not necessarily mean the software is broken, there could be organisational reasons (e.g. AD administrator not prepared to create multiple proxy accounts for different applications).
and AD that cannot be configured to accept anonymous requests (AFAIK).
Again, AD can be configured to allow anonymous binds, but AFAIK as of Windows 2003, it is disabled by default, and many AD security standards (used by e.g. financial auditing companies in their IT auditing) mandate that it not be enabled.
Feel free to suggest an enhancement that allows to handle this scenario, though.
IMHO, it would make sense to support this mode of operation.
This feature is already supported: the OP could configure a proxy for auth'd users, and another proxy for clients binding anonymously, and point each client to the most appropriate proxy. If an organization's configuration can tolerate the complexity of one proxy to workaround what I still believe be broken software, it can tolerate the complexity of two proxies. Tthe fact that one needs to add a piece of software to break rules makes the whole system broken, since rules are violated anyway, so I'd find it easier to eliminate to-be-broken rules in the first place.
p.
Buchan Milne wrote:
On Wednesday, 9 February 2011 01:13:38 masarati@aero.polimi.it wrote:
As far as I recall, what you need is not possible. You can:
have authenticated users proxied with their identity asserted, or
all users, including unauthenticated ones auth'd as a fixed identity
but not both. Please note that you're asking OpenLDAP's slapd to bridge the gap between two broken pieces of code: clients that cannot be configured to bind,
Because the OP wants to have anonymous access for some clients of the proxy does not necessarily mean the software is broken, there could be organisational reasons (e.g. AD administrator not prepared to create multiple proxy accounts for different applications).
and AD that cannot be configured to accept anonymous requests (AFAIK).
Again, AD can be configured to allow anonymous binds, but AFAIK as of Windows 2003, it is disabled by default, and many AD security standards (used by e.g. financial auditing companies in their IT auditing) mandate that it not be enabled.
Feel free to suggest an enhancement that allows to handle this scenario, though.
IMHO, it would make sense to support this mode of operation.
Sorry but that just doesn't compute. If you have organizational security standards that are being audited and they forbid anonymous access, then allowing anonymous access to an OpenLDAP proxy that connects to AD is going to be equally forbidden.
Come back with an argument that actually makes sense from a security perspective first. Otherwise this is just creating back doors to do end-runs around your sysadmins and company policies.
On Wed, Feb 09, 2011 at 01:20:22AM -0800, Howard Chu wrote:
Buchan Milne wrote:
On Wednesday, 9 February 2011 01:13:38 masarati@aero.polimi.it wrote:
Please note that you're asking OpenLDAP's slapd to bridge the gap between two broken pieces of code
Very likely, and we are fortunate to have a tool that will fill such gaps as they occur with depressing regularity in large organisations.
Sorry but that just doesn't compute. If you have organizational security standards that are being audited and they forbid anonymous access, then allowing anonymous access to an OpenLDAP proxy that connects to AD is going to be equally forbidden.
In some environments the IP address of the client system is considered to be sufficient authentication. OpenLDAP ACLs can cope with that. AD ACLs are much less flexible.
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Buchan Milne -
Del -
Howard Chu -
masarati＠aero.polimi.it -
Pierangelo Masarati