10:37 a.m.
Hi.
Is there a way to have a more fine-grained restriction for simple binds
rather than just On of Off? Maybe some ACL regexp?
For instance I want to restrict simple bind possibilities to direct
children of two or three OU groups, and furthermore I want to restrict
the simple binds for the normal users to those with a {SASL} entry in
their userPassword (or everyone if it cannot be specified separately).
I'm using the option "password-hash {CLEARTEXT}" and don't want users
without a userPassword like "{SASL}<uid>@REALM" to be allowed to do
simple binds to the LDAP database. I have a Kerberos realm setup to
handle passwords and saslauthd for the password check.
Some applications that I have running are not kerberized. So I can't
disable simple binds completely, since these applications still need to
do simple binds for authentication.
You might say that simple binds won't be possible if entries don't have
a userPassword attribute, but I'd like some better reassurance.
/Tobias
1:33 a.m.
Hi again.
Small update...
I started fiddling around with regexp ACLs after I wrote my mail (I
thought of it just as I was finishing the mail), and so far I have been
able to limit access to the userPassword (and as such, simple binds) to
users in ou=People who have a userPassword like regexp "{SASL}.+@REALM".
However, I have yet to find a way to expand a regexp from the dn
containing the uid, into the attrs regexp. My ACL looks something like this:
access to dn.regex="^uid=([^,]+),ou=People,dc=example,dc=com$"
attrs=userPassword val.regex="{SASL}.+(a)EXAMPLE.COM"
by self read
by anonymous auth
by * none
I have tried to use val.exact="{SASL}$1(a)EXAMPLE.COM" but it doesn't
appear to expand the $1 from teh first dn.regex as I would like. Any ideas?
/Tobias
Tobias Franzén wrote:
Hi.
Is there a way to have a more fine-grained restriction for simple binds
rather than just On of Off? Maybe some ACL regexp?
For instance I want to restrict simple bind possibilities to direct
children of two or three OU groups, and furthermore I want to restrict
the simple binds for the normal users to those with a {SASL} entry in
their userPassword (or everyone if it cannot be specified separately).
I'm using the option "password-hash {CLEARTEXT}" and don't want users
without a userPassword like "{SASL}<uid>@REALM" to be allowed to do
simple binds to the LDAP database. I have a Kerberos realm setup to
handle passwords and saslauthd for the password check.
Some applications that I have running are not kerberized. So I can't
disable simple binds completely, since these applications still need to
do simple binds for authentication.
You might say that simple binds won't be possible if entries don't have
a userPassword attribute, but I'd like some better reassurance.
/Tobias
10:35 a.m.
Tobias Franzén wrote:
I started fiddling around with regexp ACLs after I wrote my mail (I
thought of it just as I was finishing the mail), and so far I have been
able to limit access to the userPassword (and as such, simple binds) to
users in ou=People who have a userPassword like regexp "{SASL}.+@REALM".
However, I have yet to find a way to expand a regexp from the dn
containing the uid, into the attrs regexp. My ACL looks something like
this:
access to dn.regex="^uid=([^,]+),ou=People,dc=example,dc=com$"
attrs=userPassword val.regex="{SASL}.+(a)EXAMPLE.COM"
by self read
by anonymous auth
by * none
I have tried to use val.exact="{SASL}$1(a)EXAMPLE.COM" but it doesn't
appear to expand the $1 from teh first dn.regex as I would like. Any ideas?
Your wish does not find any correspondence in the documentation. In
fact, there's no possibility to have such expansion, nor it makes much
sense, as there's no consequentiality implied in setting
access to dn=pattern attr=desc val=value
since
access to val=value attr=desc dn=pattern
would be exactly the same rule.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
3:05 p.m.
Pierangelo Masarati wrote:
Tobias Franzén wrote:
> I started fiddling around with regexp ACLs after I wrote my mail (I
> thought of it just as I was finishing the mail), and so far I have been
> able to limit access to the userPassword (and as such, simple binds) to
> users in ou=People who have a userPassword like regexp "{SASL}.+@REALM".
> However, I have yet to find a way to expand a regexp from the dn
> containing the uid, into the attrs regexp. My ACL looks something like
> this:
>
> access to dn.regex="^uid=([^,]+),ou=People,dc=example,dc=com$"
> attrs=userPassword val.regex="{SASL}.+(a)EXAMPLE.COM"
> by self read
> by anonymous auth
> by * none
>
> I have tried to use val.exact="{SASL}$1(a)EXAMPLE.COM" but it doesn't
> appear to expand the $1 from teh first dn.regex as I would like. Any ideas?
>
Your wish does not find any correspondence in the documentation. In
fact, there's no possibility to have such expansion, nor it makes much
sense, as there's no consequentiality implied in setting
access to dn=pattern attr=desc val=value
since
access to val=value attr=desc dn=pattern
would be exactly the same rule.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
I agree that order in which the dn= or attrs= parts of an access entry
appear in slapd.conf is not important or relevant to OpenLDAP. However,
one might argue that regex groupings could (and should) be expandable
for any and all regexs that follows. Is it not (or should it not be)
possible to expand regex groups when matching for "who" to give access?
There is no mention of it in the online documentation, but man for
slapd.access mentions the expandability for "what" groupings in "who"
matchings.
When running slapd with -d 128 (ACLs), it shows how it first has to
check if the requested DN is matched (and rightfully so), before it can
move on to defined attrs. So when this first dn regex is done, it
shouldn't be impossible to extract substrings from it into the second
regex for attrs as well.
Anyway, my point was to get an answer about other possible ways to make
sure that if a DN like "uid=user_one,ou=People,dc=example,dc=com" has an
attribute userPassword, it should be exactly
"{SASL}user_one(a)EXAMPLE.COM", and only then should anonymous be
permitted to authenticate as this user.
I'm not entirely sure how it is now, and I hope this following
explanation is understandable. If you can only allocate substrings in a
dn.regex for "what" to access, and later extract them in a
dn.exact[,expand] fashion for the "who" can access, and not having
substring allocation possible for the attrs=attr val.regex, then you
should also be able to extract substrings from the initial dn.regex in
the attrs=attr val.regex or exact[,expand].
The documentation for slapd configuration, and the man pages for
slapd.conf and slapd.access, say nothing about the possibility to expand
or not expand regex substrings to or from an attrs regex as far as I
have been able to see.
/Tobias
11:06 p.m.
Tobias Franzén wrote:
Pierangelo Masarati wrote:
> Tobias Franzén wrote:
>
>
>> I started fiddling around with regexp ACLs after I wrote my mail (I
>> thought of it just as I was finishing the mail), and so far I have been
>> able to limit access to the userPassword (and as such, simple binds) to
>> users in ou=People who have a userPassword like regexp
"{SASL}.+@REALM".
>> However, I have yet to find a way to expand a regexp from the dn
>> containing the uid, into the attrs regexp. My ACL looks something like
>> this:
>>
>> access to dn.regex="^uid=([^,]+),ou=People,dc=example,dc=com$"
>> attrs=userPassword val.regex="{SASL}.+(a)EXAMPLE.COM"
>> by self read
>> by anonymous auth
>> by * none
>>
>> I have tried to use val.exact="{SASL}$1(a)EXAMPLE.COM" but it
doesn't
>> appear to expand the $1 from teh first dn.regex as I would like. Any
>> ideas?
>>
>
> Your wish does not find any correspondence in the documentation. In
> fact, there's no possibility to have such expansion, nor it makes much
> sense, as there's no consequentiality implied in setting
>
> access to dn=pattern attr=desc val=value
>
> since
>
> access to val=value attr=desc dn=pattern
>
> would be exactly the same rule.
>
> p.
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
I agree that order in which the dn= or attrs= parts of an access entry
appear in slapd.conf is not important or relevant to OpenLDAP.
This is a fact.
However,
one might argue that regex groupings could (and should) be expandable
for any and all regexs that follows. Is it not (or should it not be)
possible to expand regex groups when matching for "who" to give access?
The "who" is a separate clause from "what"; "who" expansion
based on
"what" contents is implemented and documented, in fact.
There is no mention of it in the online documentation, but man for
slapd.access mentions the expandability for "what" groupings in
"who"
matchings.
Exactly.
When running slapd with -d 128 (ACLs), it shows how it first has to
check if the requested DN is matched (and rightfully so), before it can
move on to defined attrs. So when this first dn regex is done, it
shouldn't be impossible to extract substrings from it into the second
regex for attrs as well.
This is a "feature request". In general, you should safely assume that
undocumented features are not documented because they do not exist.
Anyway, my point was to get an answer about other possible ways to
make
sure that if a DN like "uid=user_one,ou=People,dc=example,dc=com" has an
attribute userPassword, it should be exactly
"{SASL}user_one(a)EXAMPLE.COM", and only then should anonymous be
permitted to authenticate as this user.
I'm not entirely sure how it is now, and I hope this following
explanation is understandable. If you can only allocate substrings in a
dn.regex for "what" to access, and later extract them in a
dn.exact[,expand] fashion for the "who" can access, and not having
substring allocation possible for the attrs=attr val.regex, then you
should also be able to extract substrings from the initial dn.regex in
the attrs=attr val.regex or exact[,expand].
Technically, I think there is no limitation: whatever you figure out can
probably be implemented somehow. Semantically, I'd object that much
like DN pattern matching can be substituted in VAL, the same should be
true for VAL pattern matching in DN, but since DN and VAL have the same
priority (to be AND-ed), this would probably require changing the
semantics of the "what" clause.
The documentation for slapd configuration, and the man pages for
slapd.conf and slapd.access, say nothing about the possibility to expand
or not expand regex substrings to or from an attrs regex as far as I
have been able to see.
As I said, when the docs say nothing about something, you can safely
assume it's because that something is not possible/implemented. Feel
free to file a feature request through the ITS
<http://www.openldap.org/its/>;.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
1:53 a.m.
Tobias Franzén wrote:
Hi.
Is there a way to have a more fine-grained restriction for simple binds
rather than just On of Off? Maybe some ACL regexp?
For instance I want to restrict simple bind possibilities to direct
children of two or three OU groups, and furthermore I want to restrict
the simple binds for the normal users to those with a {SASL} entry in
their userPassword (or everyone if it cannot be specified separately).
I'm using the option "password-hash {CLEARTEXT}" and don't want users
without a userPassword like "{SASL}<uid>@REALM" to be allowed to do
simple binds to the LDAP database. I have a Kerberos realm setup to
handle passwords and saslauthd for the password check.
Some applications that I have running are not kerberized. So I can't
disable simple binds completely, since these applications still need to
do simple binds for authentication.
You might say that simple binds won't be possible if entries don't have
a userPassword attribute, but I'd like some better reassurance.
You can use access control on the userPassword attribute. Something like
access to attrs=userPassword
by group="ou=Simple Bind" auth
by * break
access to attrs=userPassword val.regex="^{SASL}.*"
by * auth
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
2:27 a.m.
Pierangelo Masarati wrote:
Tobias Franzén wrote:
> Hi.
>
> Is there a way to have a more fine-grained restriction for simple binds
> rather than just On of Off? Maybe some ACL regexp?
>
> For instance I want to restrict simple bind possibilities to direct
> children of two or three OU groups, and furthermore I want to restrict
> the simple binds for the normal users to those with a {SASL} entry in
> their userPassword (or everyone if it cannot be specified separately).
>
> I'm using the option "password-hash {CLEARTEXT}" and don't want
users
> without a userPassword like "{SASL}<uid>@REALM" to be allowed to do
> simple binds to the LDAP database. I have a Kerberos realm setup to
> handle passwords and saslauthd for the password check.
>
> Some applications that I have running are not kerberized. So I can't
> disable simple binds completely, since these applications still need to
> do simple binds for authentication.
>
> You might say that simple binds won't be possible if entries don't have
> a userPassword attribute, but I'd like some better reassurance.
You can use access control on the userPassword attribute. Something like
access to attrs=userPassword
by group="ou=Simple Bind" auth
by * break
Not quite. "auth" operations are always anonymous.
It would need to be something like
access to dn.one="ou=Simple Bind" attrs=userPassword
by anonymous auth
access to attrs=userPassword val.regex="^{SASL}.*"
by * auth
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:50 a.m.
Howard Chu wrote:
> access to attrs=userPassword
> by group="ou=Simple Bind" auth
> by * break
Not quite. "auth" operations are always anonymous.
It would need to be something like
access to dn.one="ou=Simple Bind" attrs=userPassword
by anonymous auth
> access to attrs=userPassword val.regex="^{SASL}.*"
> by * auth
Right. A set would allow to define a group of users allowed to simple
bind without physically placing them under that entry; something like
access to attrs=userPassword
by set="[ou=Simple Bind]/member & this" auth
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
5701
days inactive
5703
days old
openldap-software@openldap.org
7 comments
3 participants
participants (3)
-
Howard Chu -
Pierangelo Masarati -
Tobias Franzén