Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
I searched the documentation but without success. All I found was disallow simplebind and sasl_ssf, but both seem to make no sense in this case: While the first disallows simple_binds globally, the combination of sasl_ssf and access auth is or at least seems contradicting to me.
Question: Is it possible to achieve this goal using current openldap release?
Thank you very much
Dora
Am Mon, 9 May 2016 09:00:22 +0200 schrieb Dora Paula deepee@gmx.net:
Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
I searched the documentation but without success. All I found was disallow simplebind and sasl_ssf, but both seem to make no sense in this case: While the first disallows simple_binds globally, the combination of sasl_ssf and access auth is or at least seems contradicting to me.
Question: Is it possible to achieve this goal using current openldap release?
Yes, this is possible, man slapd.acess(5), read on security, security strength factors and transport layer security.
-Dieter
I searched for security in slapd.access(5) [1] and just found:
"The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and sasl_ssf=<n> set the minimum required Security Strength Factor (ssf) needed to grant access."
In regard to "security" slapd.conf(5) [2] states:
"security <factors> ... The directive may be specified globally and/or per-database."
Thus I don't see how this applies to my goal.
The following statement/example is taken from the current admin guide [3]:
access to dn="cn=example,cn=edu" by * ssf=256 read
Thus I tested, just for fun: access to dn="ou=usersa,dc=example,dc=com" by * sasl_ssf=1 auth
Without success - which seems clear to me, because there is no sasl-layer known during an initial bind. So, if I'm wrong, could you please be so kind and go into more detail here?
Thank you very much.
[1] http://www.openldap.org/software/man.cgi?query=slapd.access&sektion=5&am... [2] http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&... [3] http://www.openldap.org/doc/admin24/guide.html
On 09.05.2016 10:26, Dieter Klünter wrote:
Am Mon, 9 May 2016 09:00:22 +0200 schrieb Dora Paula deepee@gmx.net:
Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
I searched the documentation but without success. All I found was disallow simplebind and sasl_ssf, but both seem to make no sense in this case: While the first disallows simple_binds globally, the combination of sasl_ssf and access auth is or at least seems contradicting to me.
Question: Is it possible to achieve this goal using current openldap release?
Yes, this is possible, man slapd.acess(5), read on security, security strength factors and transport layer security.
-Dieter
Am Mon, 9 May 2016 11:00:38 +0200 schrieb Dora Paula deepee@gmx.net:
I searched for security in slapd.access(5) [1] and just found:
"The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and sasl_ssf=<n> set the minimum required Security Strength Factor (ssf) needed to grant access."
In regard to "security" slapd.conf(5) [2] states:
"security <factors> ... The directive may be specified globally and/or per-database."
Thus I don't see how this applies to my goal.
The following statement/example is taken from the current admin guide [3]:
access to dn="cn=example,cn=edu" by * ssf=256 read
Thus I tested, just for fun: access to dn="ou=usersa,dc=example,dc=com" by * sasl_ssf=1 auth
Without success - which seems clear to me, because there is no sasl-layer known during an initial bind. So, if I'm wrong, could you please be so kind and go into more detail here?
Thank you very much.
[...]
Any password transport should be protected by some means of transport security, that is, either sasl DIGEST-MD5 or TLS.
security=1
access to dn.sub=ou=userA,dc=example,dc=com by * sasl_ssf=128 read
access to dn.sub=ou=userB,dc=example,dc=com by * ssf=56 read
or alternatively
by transport_ssf=56 read
-Dieter
On 09.05.2016 12:31, Dieter Klünter wrote:
Am Mon, 9 May 2016 11:00:38 +0200 schrieb Dora Paula deepee@gmx.net:
I searched for security in slapd.access(5) [1] and just found:
"The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and sasl_ssf=<n> set the minimum required Security Strength Factor (ssf) needed to grant access."
In regard to "security" slapd.conf(5) [2] states:
"security <factors> ... The directive may be specified globally and/or per-database."
Thus I don't see how this applies to my goal.
The following statement/example is taken from the current admin guide [3]:
access to dn="cn=example,cn=edu" by * ssf=256 read
Thus I tested, just for fun: access to dn="ou=usersa,dc=example,dc=com" by * sasl_ssf=1 auth
Without success - which seems clear to me, because there is no sasl-layer known during an initial bind. So, if I'm wrong, could you please be so kind and go into more detail here?
Thank you very much.
[...]
Any password transport should be protected by some means of transport security, that is, either sasl DIGEST-MD5 or TLS.
security=1
access to dn.sub=ou=userA,dc=example,dc=com by * sasl_ssf=128 read
access to dn.sub=ou=userB,dc=example,dc=com by * ssf=56 read
or alternatively
by transport_ssf=56 read
-Dieter
Dieter,
please note: Access auth is the question. Thus I think your example using access read misses the point here.
Nevertheless I've set security ssf=1 for the database, used the following acl ...
access to dn.one="ou=usersA,dc=example,dc=com" attrs=cn by anonymous sasl_ssf=128 auth by users read by * none
... and tried an "ldapwhoami -Y DIGEST-MD5 -U ...", which does not work as expected. Please see the "ACL 1 > OP 0" in the following log excerpt:
57307aa4 => acl_mask: access to entry "cn=test,ou=usersA,dc=example,dc=com", attr "cn" requested 57307aa4 => acl_mask: to value by "", (=0) 57307aa4 <= check a_dn_pat: anonymous 57307aa4 <= check a_authz.sai_sasl_ssf: ACL 1 > OP 0 57307aa4 <= check a_dn_pat: self 57307aa4 <= check a_dn_pat: * 57307aa4 <= acl_mask: [5] applying none(=0) (stop) 57307aa4 <= acl_mask: [5] mask: none(=0) 57307aa4 => slap_access_allowed: auth access denied by none(=0)
General note regaring my setup: Without the security and ssf stuff the test user can successfully bind using simple and sasl bind - so far so good. All I would like to achieve, is to restrict binds locally (see dn.one=...) to sasl-only, without disallowing simple bind globally.
Is this possible? If yes, how?
Thanks again.
On 09. mai 2016 09:00, Dora Paula wrote:
Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
Simple Bind uses anonymous auth (=x) access to userPassword. Does your SASL setup use userPassword? If not, or if userPassword for SASL look like {foo}something but other passwords do not, use can use something like
olcAccess: to attrs=userPassword dn.children="ou=usersB,..." by anonymous =x by self =w # just reject passwords outside usersB. If you need something else, # may add val.regex=^[{]SASL[}] or whatever, see man slapd.access(5) olcAccess: to attrs=userPassword by * none
On 09.05.2016 13:31, Hallvard Breien Furuseth wrote:
On 09. mai 2016 09:00, Dora Paula wrote:
Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
Simple Bind uses anonymous auth (=x) access to userPassword. Does your SASL setup use userPassword? If not, or if userPassword for SASL look like {foo}something but other passwords do not, use can use something like
olcAccess: to attrs=userPassword dn.children="ou=usersB,..." by anonymous =x by self =w # just reject passwords outside usersB. If you need something else, # may add val.regex=^[{]SASL[}] or whatever, see man slapd.access(5) olcAccess: to attrs=userPassword by * none
Oh ha, this sound very promissing! I'll give it a try.
Just one quick question: How can I tell slapd to use a customUserPassword-attribute instead of the hard coded userPassword - to avoid the somewhat performance hungry "val.regexp=" check?
Thank you very much!
On 09. mai 2016 14:32, Dora Paula wrote:
Just one quick question: How can I tell slapd to use a customUserPassword-attribute instead of the hard coded userPassword - to avoid the somewhat performance hungry "val.regexp=" check?
For Simple Bind, you can't. But if your SASL is looking up userPassword, it can presumably be configured to look up customUserPassword instead. Look at your SASL config rather than your slapd config for that.
On 09. mai 2016 14:44, Hallvard Breien Furuseth wrote:
On 09. mai 2016 14:32, Dora Paula wrote:
Just one quick question: How can I tell slapd to use a customUserPassword-attribute instead of the hard coded userPassword - to avoid the somewhat performance hungry "val.regexp=" check?
For Simple Bind, you can't. But if your SASL is looking up userPassword, it can presumably be configured to look up customUserPassword instead. Look at your SASL config rather than your slapd config for that.
I should have added: I wouldn't bother to restructure the DB that way initially, unless there actually is a performance issue.
On 09.05.2016 13:31, Hallvard Breien Furuseth wrote:
On 09. mai 2016 09:00, Dora Paula wrote:
Dear List,
I've two subtrees that contain user-accounts: ou=usersA,dc=example,dc=com and ou=usersB,dc=example,dc=com.
Goal: Users below ou=userA,... should only be allowed to bind using sasl_bind, but not with simple_bind. Whereas users below ou=usersB,... should be allowed to bind using both (or any kind of bind).
Simple Bind uses anonymous auth (=x) access to userPassword. Does your SASL setup use userPassword? If not, or if userPassword for SASL look like {foo}something but other passwords do not, use can use something like
olcAccess: to attrs=userPassword dn.children="ou=usersB,..." by anonymous =x by self =w # just reject passwords outside usersB. If you need something else, # may add val.regex=^[{]SASL[}] or whatever, see man slapd.access(5) olcAccess: to attrs=userPassword by * none
Hallvard,
unfortunately, I think I had been glad already too early:
I use locally (in slapd) stored passwords (using the userPassword attribute, mainly to be able to ldapmodify them, and of course plain text to allow DIGEST-MD5 to work).
If I understand the admin guide correct, adding {SASL} always activates passthru authentication (e.g. saslauthd). If not, could you please go into more detail regarding your idea? Is it possible to pass-thru-back-to-slapd?
Thanks again.
openldap-technical@openldap.org
-
Dieter Klünter -
Dora Paula -
Hallvard Breien Furuseth