openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6913) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

Full_Name: Marco Pizzoli Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) This is a feature request. I would like to further extend accesslog filtering capabilities. It would be useful to me exclude logging of operations made by a specific user (DN). My usage case is a DBMS (DB2) using native LDAP authentication, which does extensive search operations on my DIT (quite 2 millions searches per day per instance). I assigned a specific technical user (DN) to these DB2 instancies and so I am able to identify operations made by those users. This filter would allow me to reduce very much my accesslog db size and augment my data retention. Thanks Marco Pizzoli

1 0

(ITS#6912) authz-regexp DN
by daniel＠pluta.biz 21 Apr '11

21 Apr '11

Full_Name: authz-regex dnNormalize() filter expression with matching rule assertion Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:fe00:200:5efe:81bb:f4c) We tried to support/implement case-sensitive logins using SASL DIGEST-MD5. Imagine the following partial authz-regexp statement: ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=$1) During "dnNormalize" the uid is transformed into lowercase which cause the caseExactMatch to fail: SASL [conn=1010] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=user1HAHA,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=user1HAHA,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=user1HAHA,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=user1HAHA,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=user1HAHA,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=user1HAHA,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=user1haha)'}

1 0

Re: (ITS#6911) Feature Request: accesslog filter on DN
by hyc＠symas.com 21 Apr '11

21 Apr '11

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.174.164.11) > > > This is a feature request. > > I would like to further extend accesslog filtering capabilities. > It would be useful to me exclude logging of operations made by a specific user > (DN). > > My usage case is a DBMS (DB2) using native LDAP authentication, which does > extensive search operations on my DIT (quite 2 millions searches per day per > instance). > I assigned a specific technical user (DN) to these DB2 instancies and so I am > able to identify operations made by those users. > > This filter would allow me to reduce very much my accesslog db size and augment > my data retention. Patches welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6911) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

It works! :-) In next 2 days I will test other configurations and I will let you know! By now, thanks a lot! Marco On Wed, Apr 20, 2011 at 9:26 PM, Howard Chu <hyc(a)symas.com> wrote: > Marco Pizzoli wrote: >> >> Trying a more complex configuration I found my first problem. >> This is my configuration: >> >> logbase session dc=mycorp,dc=mydc.it >> logbase all ou=groups,dc=mycorp,dc=mydc.it >> logbase all ou=people,dc=mycorp,dc=mydc.it >> >> Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an >> authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", >> I obtain this accesslog >> >> >> # 20110420141404.000000Z, log03, mydc.it >> dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it >> objectClass: auditBind >> reqStart: 20110420141404.000000Z >> reqEnd: 20110420141404.000001Z >> reqType: bind >> reqSession: 1000 >> reqAuthzID: >> reqDN: cn=manager,dc=mycorp,dc=mydc.it >> reqResult: 0 >> reqVersion: 3 >> reqMethod: SIMPLE >> >> # 20110420141404.000002Z, log03, mydc.it >> dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it >> objectClass: auditSearch >> reqStart: 20110420141404.000002Z >> reqEnd: 20110420141404.000003Z >> reqType: search >> reqSession: 1000 >> reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it >> reqDN: ou=groups,dc=mycorp,dc=mydc.it >> reqResult: 0 >> reqScope: sub >> reqDerefAliases: never >> reqAttrsOnly: FALSE >> reqFilter: (cn=minnie) >> reqAttr: dn >> reqEntries: 0 >> reqTimeLimit: -1 >> reqSizeLimit: -1 >> >> As you can see, there isn't the unbind operation log... >> It's an error of mine? >> > Looks like Unbind has not been modified to handle logbase yet. Will fix this > shortly. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 20 Apr '11

20 Apr '11

Marco Pizzoli wrote: > Trying a more complex configuration I found my first problem. > This is my configuration: > > logbase session dc=mycorp,dc=mydc.it > logbase all ou=groups,dc=mycorp,dc=mydc.it > logbase all ou=people,dc=mycorp,dc=mydc.it > > Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an > authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", > I obtain this accesslog > > > # 20110420141404.000000Z, log03, mydc.it > dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it > objectClass: auditBind > reqStart: 20110420141404.000000Z > reqEnd: 20110420141404.000001Z > reqType: bind > reqSession: 1000 > reqAuthzID: > reqDN: cn=manager,dc=mycorp,dc=mydc.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > > # 20110420141404.000002Z, log03, mydc.it > dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it > objectClass: auditSearch > reqStart: 20110420141404.000002Z > reqEnd: 20110420141404.000003Z > reqType: search > reqSession: 1000 > reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it > reqDN: ou=groups,dc=mycorp,dc=mydc.it > reqResult: 0 > reqScope: sub > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (cn=minnie) > reqAttr: dn > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: -1 > > As you can see, there isn't the unbind operation log... > It's an error of mine? > Looks like Unbind has not been modified to handle logbase yet. Will fix this shortly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 20 Apr '11

20 Apr '11

Trying a more complex configuration I found my first problem. This is my configuration: logbase session dc=mycorp,dc=mydc.it logbase all ou=groups,dc=mycorp,dc=mydc.it logbase all ou=people,dc=mycorp,dc=mydc.it Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", I obtain this accesslog # 20110420141404.000000Z, log03, mydc.it dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it objectClass: auditBind reqStart: 20110420141404.000000Z reqEnd: 20110420141404.000001Z reqType: bind reqSession: 1000 reqAuthzID: reqDN: cn=manager,dc=mycorp,dc=mydc.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE # 20110420141404.000002Z, log03, mydc.it dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it objectClass: auditSearch reqStart: 20110420141404.000002Z reqEnd: 20110420141404.000003Z reqType: search reqSession: 1000 reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it reqDN: ou=groups,dc=mycorp,dc=mydc.it reqResult: 0 reqScope: sub reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (cn=minnie) reqAttr: dn reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: -1 As you can see, there isn't the unbind operation log... It's an error of mine?

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 20 Apr '11

20 Apr '11

I compiled HEAD/Master branch and I tried setting logbase directive. It seems to work as requested! Thanks Marco

1 0

(ITS#6909)
by diego.jesus.granados.lopez＠ericsson.com 18 Apr '11

18 Apr '11

--_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It was difficult to achieve, but I was able to include several errors (rega= rding line numbers) in my two-line patch XD The correct one: --- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c 200= 9-08-14 22:54:14.000000000 +0200 +++ ./servers/slapd/back-meta/search.c 2011-04-15 13:11:51.395261000 +0200 @@ -309,6 +309,8 @@ if ( rc =3D=3D LDAP_SUCCESS ) { candidates[ candidate ].sr_msgid =3D META_M= SGID_IGNORE; + binddn =3D msc->msc_bound_ndn; + cred =3D msc->msc_cred; goto retry; } } Regards, Diego --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Arial, sans-serif" size=3D"2"> <div>It was difficult to achieve, but I was able to include several errors = (regarding line numbers) in my two-line patch XD </div> <div> </div> <div>The correct one: </div> <div> </div> <div>--- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c&nbs= p;     2009-08-14 22:54:14.000000000 +0200</div> <div>+++ ./servers/slapd/back-meta/search.c  2011-04-15 13= :11:51.395261000 +0200</div> <div>@@ -309,6 +309,8 @@</div> <div> </div> <div>           &nbs= p;             = if ( rc =3D=3D LDAP_SUCCESS ) {</div> <div>           &nbs= p;            &= nbsp;        candidates[ candidate ].sr_= msgid =3D META_MSGID_IGNORE;</div> <div>+          &nbsp= ;            &n= bsp;       binddn =3D msc->msc_bound_ndn;<= /div> <div>+          &nbsp= ;            &n= bsp;       cred =3D msc->msc_cred;</div> <div>           &nbs= p;            &= nbsp;        goto retry;</div> <div>           &nbs= p;             = }</div> <div>           &nbs= p;     }</div> <div> </div> <div> </div> <div>Regards, </div> <div>Diego</div> <div> </div> </font> </body> </html> --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_--

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 15 Apr '11

15 Apr '11

Hi, it's me again, with another small but also very important bugfix for the previous two versions of my patch. This patch does not change the correct (as documented by the project) behaviour of "dnattr=... selfwrite". It can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110415.patch FYI and the log: Next to some simple always reproducible test-shellscripts (ldapmodify add/delete distinct values) I have been also using Apache Directory Studio to test and workout the intended behavior of my ACLs, which is the root cause for these two updates: I've not been aware of the difference between "to value" and "to all values", yet and all my testcases (ldif changetype modify) only have been using "to value" operations. I've used following ACL to test this second patch of my original patch: access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users read by * none access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description by users read by * none break access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member by dnattr=member selfwrite by * none Based on these ACL each user that is a member of a group entry seems to be just the only member of these group (from the user's point of view, in case the user accesses the group's member attribute by read). When using Apache Directoy Studio to delete this only/single/last group member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation. => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr "member" requested => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0) It seems to me that this appears to be a bug in ADS, where the client (ADS) tries to be more inteligent/comfortable/strict than needed. OTOH based on this strange behaviour I've learned something "new" (and quite important to me in regard to acl design and testcases during testing). Sorry for these kind of SPAM and the circumstances. Hopefully that's the last bugfix for that patch.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs