Hi,
I am trying to grant users access to a ldap object when user/allowedDomain match the Mail object ou. To accomplish that I have to use set.regex and substring substitution, but I was not able to figure out what I am doing wrong.
This is the current ACL:
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set="user/allowedDomain & this/ou" write
result: ======= "ou=example.com,ou=Mail,o=example,c=BR" = write(=wrscxd) "mail=test@example.com,ou=example.com,ou=Mail,o=example,c=BR" = 0
This is the ACL that I am trying to build. It was expecting both results as = write(=wrscxd), but I am getting only = 0.
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & $2" write
result: ======= "ou=example.com,ou=Mail,o=example,c=BR" = 0 "mail=test@example.com,ou=example.com,ou=Mail,o=example,c=BR" = 0
Any ideas about what I should do for this to work?
Thanks! Ronie
Hey folks,
I'm trying to debug the cause of faulty module behavior (autogroup) which has eluded both strace and 'slapd -d 16383' (and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on Ubuntu 8.04). So, I'd like to use gdb to figure out what's going on, but I'm not quite sure how to attack the problem. I've tried several different approaches to debug what's going wrong during the ldapsearch with gdb, but I can't seem to capture what I'm looking for. Rather than paste what I've tried, since it's ineffective, I'd instead like to ask how you all would approach it. So again, the scenario is:
- slapd is running without any errors in the logs (about slapd or the failed autogroup expansions) - dynlist works, so I know that modules as a whole and dynamic searches work - autogroup doesn't generate any errors, but fails to perform any expansions during ldapsearches
How can I attack this problem with gdb such that I'll be able to step through what's going on from the moment slapd begins parsing the entry requested by the ldapsearch in which there's supposed to be an expansion occurring? Many thanks in advance for your insight.
Regards, Ryan
The ISCA answer is: You might try run everything under Valgrind instead of gdb as it might be easier.
Quoting "Ryan Steele" ryans@aweber.com:
Hey folks,
I'm trying to debug the cause of faulty module behavior (autogroup) which has eluded both strace and 'slapd -d 16383' (and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on Ubuntu 8.04). So, I'd like to use gdb to figure out what's going on, but I'm not quite sure how to attack the problem. I've tried several different approaches to debug what's going wrong during the ldapsearch with gdb, but I can't seem to capture what I'm looking for. Rather than paste what I've tried, since it's ineffective, I'd instead like to ask how you all would approach it. So again, the scenario is:
- slapd is running without any errors in the logs (about slapd or the failed autogroup expansions) - dynlist works, so I know that modules as a whole and dynamic searches work - autogroup doesn't generate any errors, but fails to perform any expansions during ldapsearches
How can I attack this problem with gdb such that I'll be able to step through what's going on from the moment slapd begins parsing the entry requested by the ldapsearch in which there's supposed to be an expansion occurring? Many thanks in advance for your insight.
Regards, Ryan
On Wed, 16 Sep 2009, omalleys@msu.edu wrote:
The ISCA answer is:� You might try run everything under Valgrind instead of gdb as it might be easier.
You can try that, but unless the fault is a memory error of some sort, I don't know that valgrind has the right tools for it (or maybe I just don't use it the right way). It really sounds like the bigger issue is a logic issue.
And honestly, in that case, a locally hacked version of the module with Debug() statements probably wouldn't hurt. Of course you can do same in gdb, and that has advantages that we like like not needing a recompile, but I think the concept of "put a print statement in" is a bit easier when getting started.
Ryan Steele wrote:
Hey folks,
I'm trying to debug the cause of faulty module behavior (autogroup) which
has eluded both strace and 'slapd -d 16383'
(and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on
Ubuntu 8.04). So, I'd like to use gdb to
figure out what's going on, but I'm not quite sure how to attack the
problem. I've tried several different approaches
to debug what's going wrong during the ldapsearch with gdb, but I can't seem
to capture what I'm looking for. Rather
than paste what I've tried, since it's ineffective, I'd instead like to ask
how you all would approach it. So again,
the scenario is:
- slapd is running without any errors in the logs (about slapd or the failed autogroup expansions)
- dynlist works, so I know that modules as a whole and dynamic searches work
- autogroup doesn't generate any errors, but fails to perform any expansions during ldapsearches
autogroup isn't supposed to perform any expansion during searches. That's not what it does.
Howard Chu wrote:
autogroup isn't supposed to perform any expansion during searches. That's not what it does.
So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? The autogroup man page makes no mention of needing the dynlist module (only the dynlist schema), which to me seems to imply that it's intended to supersede, not complement, dynlist. However, I could certainly have subjectively misinterpreted the documentation, or it might just not be documented at all (in which case I'm happy to submit a patch after having inquired with the two major developers of the module as to the patch's accuracy.
Several previous on-list postings about this aren't clear as to whether or not they use autogroup instead of or in addition to dynlist. And, when I tested the use of both together, the results aren't what I expect; e.g., the following query returns nothing:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(uid=user1)'
... whereas the same query without the trailing '(uid=user1)' returns a group full of member uid's:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup ou=Groups,dc=example,dc=com" -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?(&(employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com
If I use autogroup alone, it does not work either. So, I assumed this to be a problem in the module with whatever is supposed to trigger the expansion and was hoping to try and ferret it out with gdb instead of bothering the list with several posts full of output without having tried to debug it myself first. But, if I've interpreted it incorrectly and the premise for my investigation is invalid, I'm happy to be told exactly how to achieve the ability to filter dynamically created groups using one or both of those overlays before assuming and investigating a bug!
For reference, the following posts are examples of what I'm referring to:
http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00030.html
As always, I appreciate any and all advice!
Regards, Ryan
Ryan Steele wrote:
Howard Chu wrote:
autogroup isn't supposed to perform any expansion during searches. That's not what it does.
So, you're saying that dynlist should perform the expansion, and autogroup
just allows you to filter it?
I'm quite certain I never said any such thing.
The autogroup man page makes no mention of needing the dynlist module (only the dynlist
schema), which to me seems to imply that it's
intended to supersede, not complement, dynlist.
The autogroup Readme clearly states:
DESCRIPTION The autogroup overlay allows automated updates of group memberships which meet the requirements of any filter contained in the group definition. The filters are built from LDAP URI-valued attributes. Any time an object is added/deleted/updated, it is tested for compliance with the filters, and its membership is accordingly updated. For searches and compares it behaves like a static group.
Howard Chu wrote:
Ryan Steele wrote:
Howard Chu wrote:
autogroup isn't supposed to perform any expansion during searches. That's not what it does.
So, you're saying that dynlist should perform the expansion, and autogroup
just allows you to filter it?
I'm quite certain I never said any such thing.
That wasn't a statement, it was a question, denoted by the question mark punctuation. And, if the answer is no, can you elaborate on what you did mean? Or, perhaps answer the question I asked at the end of the post, which was regarding how to achieve the desired affect, as you alluded to in http://www.openldap.org/lists/openldap-software/200802/msg00211.html, which reads:
Pierangelo Masarati wrote:
Guy Deleeuw wrote:
All work fine, I can retrieve the two group entries. Now, I try to retrieve the group which have a particular member (ExoMemberShipMember): ldapsearch -x -LLL -b "ou=groups,ou=portal,ou=www,ou=Exo,o=Eurofer,c=be" -s sub "(&(&(objectClass=ExoMemberShip)(ExoMemberShipURL=*))(ExoMemberShipMember=cn=De Leeuw Guy,br=Internal,o=Eurofer,c=be))" And I receive an empty respond. Could you give me your advice about the feasibility of this kind of query ?
This occurs because you can't filter for dynamically created members, as they get added to the entry while it's being returned. So the dynamic members are not present in the entry during search, when the filter is evaluated. You can only filter for static data.
You might want to look at the autogroup overlay
http://www.openldap.org/its/index.cgi/Contrib?id=5145
which will be included in OpenLDAP 2.4.8.
-- 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/
The autogroup Readme clearly states:
I have read the README. I'm interested in the behavior mentioned in that post, if you could be so kind to elaborate on the statement you made in it?
Thanks, Ryan
On Wed, Sep 16, 2009 at 17:42, Ryan Steele ryans@aweber.com wrote:
query returns nothing:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(uid=user1)'
This filter doesn't look right. Try "(member=uid=user1,ou=Users,dc=example,dc=com)"
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup ou=Groups,dc=example,dc=com" -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?(&(employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com
Hey Andreas,
Andreas Hasenack wrote:
On Wed, Sep 16, 2009 at 17:42, Ryan Steele ryans@aweber.com wrote:
query returns nothing:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(uid=user1)'
This filter doesn't look right. Try "(member=uid=user1,ou=Users,dc=example,dc=com)"
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup ou=Groups,dc=example,dc=com" -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?(&(employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com
Thanks for the advice - I think you're right about filtering on the 'member' attribute. However, doing so still returns the entire list, not the individual member I'm filtering for. E.g., the same results as:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(member=*)'
At an even more basic level, something like this should work too, but it returns nothing:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL member
I'm not quite sure how to explain this behavior, given the implications made in the following two posts which indicate that I should be able to use dynamically generated attributes as filter expressions:
http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00038.html
Also, in the earlier ITS filed for the autogroup contrib overlay, it states that for searches and compares, it should behave like a static group, bolstering that supposition:
http://www.openldap.org/lists/openldap-bugs/200709/msg00128.html
So, should I be searching for a bug (which was the premise for the OP), or has the behavior of autogroup changed since its inception?
As always, many thanks for any and all advice!
Respectfully, Ryan
--On Friday, September 18, 2009 2:13 PM -0400 Ryan Steele ryans@aweber.com wrote:
This filter doesn't look right. Try "(member=uid=user1,ou=Users,dc=example,dc=com)"
Thanks for the advice - I think you're right about filtering on the 'member' attribute. However, doing so still returns the entire list, not the individual member I'm filtering for. E.g., the same results as:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(member=*)'
Ryan,
This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for "objectClass=joe" objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass.
If I search for "(member=uid=user1,ou=users,dc=example,dc=com)", it will return to me every group that has a member attribute matching that value.
I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for "objectClass=joe" objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass.
If I search for "(member=uid=user1,ou=users,dc=example,dc=com)", it will return to me every group that has a member attribute matching that value.
I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions.
To expand on this a little bit more:
LDAP filters are used to limit the number of entries returned. They do not limit attr=value pairs.
Generally, with groups, the most common operation is the ldapcompare operation. It lets you "ask" whether or not a given value is assigned to an attribute in a specific entry.
I.e., I can ask "Is uid=user1,ou=users,dc=example,dc=com a value for the member attribute in the group cn=testgroup ou=Groups,dc=example,dc=com" using the ldapcompare operation. It will answer one of three ways: TRUE, FALSE, or UNDEFINED.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi Quanah,
Quanah Gibson-Mount wrote:
This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for "objectClass=joe" objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass.
If I search for "(member=uid=user1,ou=users,dc=example,dc=com)", it will return to me every group that has a member attribute matching that value.
I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions.
To expand on this a little bit more:
LDAP filters are used to limit the number of entries returned. They do not limit attr=value pairs.
Generally, with groups, the most common operation is the ldapcompare operation. It lets you "ask" whether or not a given value is assigned to an attribute in a specific entry.
I.e., I can ask "Is uid=user1,ou=users,dc=example,dc=com a value for the member attribute in the group cn=testgroup ou=Groups,dc=example,dc=com" using the ldapcompare operation. It will answer one of three ways: TRUE, FALSE, or UNDEFINED.
Ah, your responses have been most helpful, thank you! The ldapcompare operation might actually satisfy the end-goals I was hoping to achieve by returning the dn or uid explicitly. Cheers!
Respectfully, Ryan
Ryan Steele wrote:
Hey Andreas,
Andreas Hasenack wrote:
On Wed, Sep 16, 2009 at 17:42, Ryan Steeleryans@aweber.com wrote:
query returns nothing:
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(uid=user1)'
This filter doesn't look right. Try "(member=uid=user1,ou=Users,dc=example,dc=com)"
ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup ou=Groups,dc=example,dc=com" -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?(&(employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com
Thanks for the advice - I think you're right about filtering on the 'member'
attribute. However, doing so still returns
the entire list, not the individual member I'm filtering for.
That is the way LDAP search filters work, as Quanah explained in his followup. And yes, this comment deserves an RTFM response.
Note that there is a ValuesReturnFilter control (RFC3876) which can be used to only return specific values in a result.
I'm not quite sure how to explain this behavior, given the implications made in the following two posts which indicate that I should be able to use dynamically generated attributes as filter
expressions:
The posts you reference make no such implication.
http://www.openldap.org/lists/openldap-software/200802/msg00211.html
States quite clearly "the dynamic members are not present in the entry during search, when the filter is evaluated. You can only filter for static data."
Or again, for clarity: You cannot use dynamically generated attributes as filter expressions.
The suggestion to use the autogroup overlay is precisely because autogroup does not use dynamically generated attributes, and therefore doesn't run into this constraint.
http://www.openldap.org/lists/openldap-software/200812/msg00038.html
Also, in the earlier ITS filed for the autogroup contrib overlay, it states that for searches and compares, it should behave like a static group, bolstering that supposition:
http://www.openldap.org/lists/openldap-bugs/200709/msg00128.html
How does "behaves like a static group" in any way support the notion that *dynamic* content is supported?
So, should I be searching for a bug (which was the premise for the OP), or has the behavior of autogroup changed since its inception? As always, many thanks for any and all advice!
You should be re-checking the enormous logical leaps you have made based on the material you have read. Another reason questions go un-answered is because the person asking them has already demonstrated such poor reading comprehension that the time spent writing an answer would be wasted; the answer will obviously be misunderstood.
"static" and "dynamic" are clearly antonyms in this context but you have conflated the two together and are asking why you aren't seeing the behavior you expect. Since we can only communicate in English on this list, if you don't even understand this basic semantic in English then you're beyond our ability to help.
I think you mean "slapacl -D"
I am already using it to debug the acl's.
-------- Original Message -------- Subject: Re: set.regex and substring substitution From: Aaron Richton richton@nbcs.rutgers.edu To: Ronie Gilberto Henrich ronie@ronie.com.br Cc: openldap-software@openldap.org Date: Tue Sep 15 2009 12:15:17 GMT-0300
On Tue, 15 Sep 2009, Ronie Gilberto Henrich wrote:
Any ideas about what I should do for this to work?
Start with "slapd -d acl" and go from there...
On Tue, 15 Sep 2009, Ronie Gilberto Henrich wrote:
I think you mean "slapacl -D"
No, I mean "slapd -d acl", not to say that slapacl isn't useful too. The key to slapacl is knowing what the proper input should be, and history has shown that "slapd -d acl" often proves enlightening to discovering the actual input to the ACL rules.
Also, if you post relevant parts of "slapd -d acl" output to the list, it'll be a LOT easier than us having to try to divine (possibly quite relevant) DIT details.
Hi Aaron,
Isn't it the same as setting loglevel 128 (access control list processing) in /etc/openldap/slapd.conf ?
This is the slapd.access acl: access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & $2" write
These are the logs: slapd[19439]: => access_allowed: add access to "mail=teste2@example.com.br,ou=example.com.br,ou=Mail,o=example,c=BR" "entry" requested slapd[19439]: => dnpat: [1] .*,ou=User,o=example,c=BR nsub: 0 slapd[19439]: => dnpat: [2] .*,ou=User,o=example,c=BR nsub: 0 slapd[19439]: => dnpat: [3] ^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$ nsub: 2 slapd[19439]: => acl_get: [3] matched slapd[19439]: => acl_get: [3] attr entry slapd[19439]: => acl_mask: access to entry "mail=teste2@example.com.br,ou=example.com.br,ou=Mail,o=example,c=BR", attr "entry" requested slapd[19439]: => acl_mask: to all values by "uid=ronie,ou=user,o=example,c=br", (=0) slapd[19439]: <= check a_set_pat: user/allowedDomain & $2 slapd[19439]: => bdb_entry_get: found entry: "uid=ronie,ou=user,o=example,c=br" slapd[19439]: <= acl_mask: [4] applying read(=rscxd) (stop) slapd[19439]: <= acl_mask: [4] mask: read(=rscxd) slapd[19439]: => slap_access_allowed: add access denied by read(=rscxd) slapd[19439]: => access_allowed: no more rules
Thanks, Ronie
-------- Original Message -------- Subject: Re: set.regex and substring substitution From: Aaron Richton richton@nbcs.rutgers.edu To: Ronie Gilberto Henrich ronie@ronie.com.br Cc: openldap-software@openldap.org Date: Wed Sep 16 2009 13:45:00 GMT-0300
On Tue, 15 Sep 2009, Ronie Gilberto Henrich wrote:
I think you mean "slapacl -D"
No, I mean "slapd -d acl", not to say that slapacl isn't useful too. The key to slapacl is knowing what the proper input should be, and history has shown that "slapd -d acl" often proves enlightening to discovering the actual input to the ACL rules.
Also, if you post relevant parts of "slapd -d acl" output to the list, it'll be a LOT easier than us having to try to divine (possibly quite relevant) DIT details.
Ronie Gilberto Henrich wrote:
Hi Aaron,
Isn't it the same as setting loglevel 128 (access control list processing) in /etc/openldap/slapd.conf ?
This is the slapd.access acl: access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & $2" write
Try
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & [$2]" write
since the domain, after regex expansion, should be treated as a literal. Moreover,
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.expand="user/allowedDomain & [$2]" write
should be more appropriate.
p.
Buon giorno Pierangelo,
The [] around the $2 solved this problem.
Grazie, Ronie
-------- Original Message -------- Subject: Re: set.regex and substring substitution From: Pierangelo Masarati masarati@aero.polimi.it To: ronie@ronie.com.br Cc: openldap-software@openldap.org Date: Thu Sep 17 2009 07:02:23 GMT-0300
Try
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & [$2]" write
since the domain, after regex expansion, should be treated as a literal. Moreover,
access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.expand="user/allowedDomain & [$2]" write
should be more appropriate.
p.
On Wed, 16 Sep 2009, Ronie Gilberto Henrich wrote:
Isn't it the same as setting loglevel 128 (access control list processing) in /etc/openldap/slapd.conf ?
Yes, that should have the same effect...
slapd[19439]: <= check a_set_pat: user/allowedDomain & $2
As Pierangelo pointed out, that's the next thing to tweak.
openldap-software@openldap.org
-
Aaron Richton -
Andreas Hasenack -
Howard Chu -
omalleys＠msu.edu -
Pierangelo Masarati -
Quanah Gibson-Mount -
Ronie Gilberto Henrich -
Ryan Steele