[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
idassert-authzFrom: Proper way to include only non-anonymous binds
- To: openldap-technical@openldap.org
- Subject: idassert-authzFrom: Proper way to include only non-anonymous binds
- From: Patrik Lundin <patrik@sigterm.se>
- Date: Mon, 1 Apr 2019 23:39:26 +0200
- Content-disposition: inline
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigterm.se; h= date:from:to:subject:message-id:mime-version:content-type; s= fm2; bh=HeJL+Dn6VoKTkS0ZjoWcRmb0PDYZaVMOrjBibxSf8JQ=; b=MlXVCdUv veKBH6hpsyBaswGQ2B8aCfIqJ7qE97EUPtq2rJWTXnwTEk46P6SxlPavusJAOUcA wRZPpeXSJHioC+g3JFA2ORQ34a2h8BtspOFI71hNGuWtJgPD3Wn+yJ3vwpY66Fq5 JbBGRq0y0gqaKToKNPzN2Lxu0wgpsYh0Na52YVxzfXixoyYOlT5SDrwB0cngtvge DXGx9U/MbKRZUivwcQvAIGwJ/GUGfkFdrfMAw7FMlkDLAUcZRT1D79Q0Zx+X5yxK 93FGvtL/t7cCJSioI+Gxx6O5YDSXQQ6QgAX6m7e7pw1I01hFd4yztdXCbnxuPaUo /CIIQsOZ7xkG5g==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=HeJL+Dn6VoKTkS0ZjoWcRmb0PDYZa VMOrjBibxSf8JQ=; b=CcIULLUj2I1XFNT1TQn9YcuAXWOmgYENOEXjK1upmH6SS Ktah723ItdAJixx1fb+nYBYNzrUongdeDPyrVaqQ9B+ewdlPTAWg3R1ASNvyYq3j cCBaWtyKUUhgDbY0SOzlHXi0e+VeHPbF3vg6e+R5Miq4KL0mBka9+96c/QxmKVUY kpvbhoeddZTUPpiZF2j84XqZ8kFuAYwPaJcl1Rww/1D9Kbzpt/mvW3F0L4y75nqS lln98q4vKJc9bpmp05kJcwJHD3dbPTTEBK9bpSkcdASnYeoeYb3rsR2Eh2oh6Puo CcjSt7OuaFw7zcH5ioDmjCWgUiNcAVNTkvjEsPp7Q==
- User-agent: Mutt/1.6.2 (2016-07-01)
Hello,
What is the proper way to make sure only non-anonymous binds are allowed
to utilize idassert-bind credentials?
Reading http://www.openldap.org/faq/data/cache/532.html the following is
stated:
===
Authorize only non-anonymous:
idassert-authzFrom "dn:*"
===
It also states:
===
The idassert-authzFrom mechanism controls whether a client's identity
can be asserted or not. The idassert-authzFrom mechanism basically
selects what identities can access the identity assertion feature, and
indeed should be considered as the set of values of the authzFrom
attribute associated to the administrative identity, with the essential
difference that, if not present, by default every identity is
authorized, including anonymous.
===
These excerpts makes me believe that the expected default behaviour is that a
missing idassert-authzFrom will allow anyone, even anonymous binds. That
a pattern of "*" is supposed to match non-anon binds is also stated in
the slapd.conf man page (https://linux.die.net/man/5/slapd.conf):
===
A pattern of * means any non-anonymous DN.
===
Then there is this contradictory message I found while looking through
the lists:
https://www.openldap.org/lists/openldap-technical/200809/msg00096.html
It states:
===
If you want idassert to work also for anonymous operations (not
recommended, as this defeats the security model of the remote server, by
letting it believe that the proxy authenticated users while it didn't),
you need to explicitly enable it using an idassert-authzFrom rule that
includes anonymous, like
idassert-authzFrom "dn.regex:.*"
===
This is more in line with my tests, where removing the
"idassert-authzFrom" all together stops an anonymous ldapsearch from
returning a result, while adding 'idassert-authzFrom "dn:*"' makes it
return results for the anon bind.
I realize there is a difference between the the line from the FAQ
("dn:*") and the line from the mailing list ("dn.regex:.*") but looking
at slap_idassert_authzfrom_parse():
https://github.com/openldap/openldap/blob/b06f5b0493937fc28f2cc86df1d7f464aa4504d8/servers/slapd/back-ldap/config.c#L681
... it appears to me that "*", "dn:*" and "dn.regex:.*" are supposed to
be equivalent. I am using the meta backend, but I'm guessing they are
sharing code in this case.
The man page for slapd-meta does not state what the result of not
configuring a "idassert-authzFrom" is though it seems to yield the
results I want (that only properly authenticated connections can make
use of the idassert-bind credentials).
I'm guessing one way to make sure only authenticated clients can do
anything is to add "require authc" to the config, but it is hard to tell
how these things interact, and it would be nice to know what the
expected way to configure idassert-authzFrom is (even if it means
leaving it unset).
Regards,
Patrik Lundin