Full_Name: Marco Pizzoli Version: ALL OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) Hi, this is a feature request. I would like to have accesslog writing to his db only ldap operations that match some sort of filter, or, in particular, to not to log searches that matches a specific pattern. This request is spotted by some ldap clients that I have that every 30seconds do a dummy ldap search only to keep alive their connection to the ldap server. These searches are frequent and I have many of these clients in my deploy, so my accesslog become full of not significant entries. Thanks in advance Marco Pizzoli
> This request is spotted by some ldap clients that I have that every > 30seconds do a dummy ldap search only to keep alive their connection > to the ldap server. These searches are frequent and I have many of > these clients in my deploy, so my accesslog become full of not > significant entries. For this specific purpose, your clients could perform an operation that is not logged; for example, search the rootDSE. p.
Hi, yes but not all my clients are so flexible. A helpful usage, in my deploy, would be in populating a database with only BIND operations. By now this is not possible. Thanks Marco Pizzoli On Sun, Jan 30, 2011 at 9:12 PM, <masarati@aero.polimi.it> wrote: > > This request is spotted by some ldap clients that I have that every > > 30seconds do a dummy ldap search only to keep alive their connection > > to the ldap server. These searches are frequent and I have many of > > these clients in my deploy, so my accesslog become full of not > > significant entries. > > For this specific purpose, your clients could perform an operation that is > not logged; for example, search the rootDSE. > > p. > > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison
moved from Incoming to Software Enhancements
changed notes changed state Open to Test
marco.pizzoli@gmail.com wrote: > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations that match > some sort of filter, or, in particular, to not to log searches that matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every 30seconds do > a dummy ldap search only to keep alive their connection to the ldap server. > These searches are frequent and I have many of these clients in my deploy, so my > accesslog become full of not significant entries. I've added a simple subtree-matching feature to accesslog in HEAD. Please test and let us know if it addresses this request. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logged. If I would like to exclude one subtree from my principal tree, I need to specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? Thanks again Marco On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc@symas.com> wrote: > marco.pizzoli@gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: ALL >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.41.84.11) >> >> >> Hi, >> this is a feature request. >> >> I would like to have accesslog writing to his db only ldap operations that >> match >> some sort of filter, or, in particular, to not to log searches that >> matches a >> specific pattern. >> >> This request is spotted by some ldap clients that I have that every >> 30seconds do >> a dummy ldap search only to keep alive their connection to the ldap >> server. >> These searches are frequent and I have many of these clients in my deploy, >> so my >> accesslog become full of not significant entries. >> > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- 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
Marco Pizzoli wrote: > Hi Howard, > thanks for this work. > > I noticed that you give me a baseDN under which I can have operations logged. > If I would like to exclude one subtree from my principal tree, I need to > specify all the baseDN of other sibling-subtrees. > To do this do I need to poli-invoke accesslog overlay? No, you can specify logbase multiple times in a single overlay. Possibly we can extend the directive to handle exclusion as well as inclusion, to simplify this case. > > Thanks again > Marco > > On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc@symas.com > <mailto:hyc@symas.com>> wrote: > > marco.pizzoli@gmail.com <mailto:marco.pizzoli@gmail.com> wrote: > > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations > that match > some sort of filter, or, in particular, to not to log searches that > matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every > 30seconds do > a dummy ldap search only to keep alive their connection to the ldap > server. > These searches are frequent and I have many of these clients in my > deploy, so my > accesslog become full of not significant entries. > > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- 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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc@symas.com> wrote: > Marco Pizzoli wrote: > >> Hi Howard, >> thanks for this work. >> >> I noticed that you give me a baseDN under which I can have operations >> logged. >> If I would like to exclude one subtree from my principal tree, I need to >> specify all the baseDN of other sibling-subtrees. >> To do this do I need to poli-invoke accesslog overlay? >> > > No, you can specify logbase multiple times in a single overlay. > Ok, thanks. > Possibly we can extend the directive to handle exclusion as well as > inclusion, to simplify this case. > This is effectively what I would need, in this case.
On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc@symas.com wrote: > Possibly we can extend the directive to handle exclusion as well as inclusion, > to simplify this case. Extending this idea slightly, would it be possible to have exclusions based on changes to specific attributes? The particular case I have in mind is where accesslog is used to keep a permanent audit log of changes, and ppolicy is also in use, resulting in one audit entry for every login failure. I have one site where a large proportion of the auditlog entries are login failures... Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
Andrew Findlay wrote: > On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc@symas.com wrote: > >> Possibly we can extend the directive to handle exclusion as well as inclusion, >> to simplify this case. > > Extending this idea slightly, would it be possible to have > exclusions based on changes to specific attributes? The > particular case I have in mind is where accesslog is used to > keep a permanent audit log of changes, and ppolicy is also > in use, resulting in one audit entry for every login > failure. I have one site where a large proportion of the auditlog > entries are login failures... Perhaps in that case, it would be simpler just to set ppolicy's mods to be internal-only and bypass the accesslog overlay. (Currently it does this already, if the server is a single-master replica.) So far you're talking about two different enhancements - the original poster is trying to exclude a set of searches, and you're talking about excluding modify ops. I'm not seeing any way yet to generalize from here such that all operation types are addressed meaningfully, and I don't want to introduce multiple special cases to the config language. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Andrew Findlay wrote: >> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc@symas.com wrote: >> >>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>> to simplify this case. >> Extending this idea slightly, would it be possible to have >> exclusions based on changes to specific attributes? The >> particular case I have in mind is where accesslog is used to >> keep a permanent audit log of changes, and ppolicy is also >> in use, resulting in one audit entry for every login >> failure. I have one site where a large proportion of the auditlog >> entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods to be > internal-only and bypass the accesslog overlay. (Currently it does this > already, if the server is a single-master replica.) > > So far you're talking about two different enhancements - the original poster > is trying to exclude a set of searches, and you're talking about excluding > modify ops. I'm not seeing any way yet to generalize from here such that all > operation types are addressed meaningfully, and I don't want to introduce > multiple special cases to the config language. A URI-based restriction specification could include/exclude based on suffix, filter and listed attributes with a unified syntax. p.
masarati@aero.polimi.it wrote: > hyc@symas.com wrote: >> Andrew Findlay wrote: >>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc@symas.com wrote: >>> >>>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>>> to simplify this case. >>> Extending this idea slightly, would it be possible to have >>> exclusions based on changes to specific attributes? The >>> particular case I have in mind is where accesslog is used to >>> keep a permanent audit log of changes, and ppolicy is also >>> in use, resulting in one audit entry for every login >>> failure. I have one site where a large proportion of the auditlog >>> entries are login failures... >> >> Perhaps in that case, it would be simpler just to set ppolicy's mods to be >> internal-only and bypass the accesslog overlay. (Currently it does this >> already, if the server is a single-master replica.) >> >> So far you're talking about two different enhancements - the original poster >> is trying to exclude a set of searches, and you're talking about excluding >> modify ops. I'm not seeing any way yet to generalize from here such that all >> operation types are addressed meaningfully, and I don't want to introduce >> multiple special cases to the config language. > > A URI-based restriction specification could include/exclude based on > suffix, filter and listed attributes with a unified syntax. Yes... But what does the filter *mean* in a modify op? filter on the target entry before it was modified, or after? a search op? match the search request's filter, or filter on the search base? a compare op? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Wed, Feb 23, 2011 at 05:25:28AM -0800, Howard Chu wrote: > >Extending this idea slightly, would it be possible to have > >exclusions based on changes to specific attributes? The > >particular case I have in mind is where accesslog is used to > >keep a permanent audit log of changes, and ppolicy is also > >in use, resulting in one audit entry for every login > >failure. I have one site where a large proportion of the auditlog > >entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods > to be internal-only and bypass the accesslog overlay. (Currently it > does this already, if the server is a single-master replica.) There are all sorts of problems to do with ppolicy and replication... Bypassing accesslog is an interesting idea, but I can see that people who use n-failure-lockout might want the lockout events to be auditable. I wonder if there might be some benefit to giving such control on a per-operation basis. Then ppolicy might be configurable to have some automatic ops logged and others not. It could also be the start of a way to make ppolicy actions rather more global across a replication group (e.g. by putting in the ability to queue some ops for replication back to a master server). > So far you're talking about two different enhancements - the > original poster is trying to exclude a set of searches, and you're > talking about excluding modify ops. I'm not seeing any way yet to > generalize from here such that all operation types are addressed > meaningfully, and I don't want to introduce multiple special cases > to the config language. Rather than logbase <operations> <baseDN> how about logfilter <operations> <LDAP URL> where the whole clause may be repeated as many times as needed? The LDAP URL can then specify a search base, a filter, and a list of attributes of interest. Extending this to support both inclusion and exclusion clauses might be harder, as you would then need some way to give them an order of precedence. The case I mentioned before would need a rule of the form 'dont log this op if the only change concerns the atttribute pwdFailureTime'. Perhaps a simple list of rules: logrecord <operations> <LDAP URL> logignore <operations> <LDAP URL> ... and if anything is left at the end of the list then it gets logged. The filters would determine whether a log entry would be made at all, and the attribute lists would determine the content. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
On Wed, Feb 23, 2011 at 02:02:17PM +0000, hyc@symas.com wrote: > > A URI-based restriction specification could include/exclude based on > > suffix, filter and listed attributes with a unified syntax. > > Yes... But what does the filter *mean* in > a modify op? filter on the target entry before it was modified, or after? Hmm - I was thinking of matching on the *modified attributes* (just their presence, not taking account of value). However, I can see that pre- and post-conditions might matter so: logrecord <operations> prefilter|changefilter|postfilter <LDAP URL> logignore <operations> prefilter|changefilter|postfilter <LDAP URL> ... > a search op? match the search request's filter, or filter on the search base? Both if present. Again, I might restrict the filter to matching on the presence of attributes in the filter rather than their actual value. > a compare op? Whatever works for search should be very close. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
I tried today to compile accesslog with this feature. Probably I didn't follow the correct procedure, but I would prefer to ask anyway to leave myself any doubt. - I took the vanilla openldap-2.4.25 distribution - unpacked the archive - substituted the accesslog.c file with the corresponding one as available in HEAD/MASTER - compiled the software as if it were the 2.4.25 vanilla distribution Now I obtain the following, at the startup: [cut] line 24 (logpurge 10+00:00 08:00) line 28 (logsuccess FALSE) line 30 (logbase all ou=people,dc=lancse,dc=csebo.it) /opt/openldap2.4.25/libexec/slapd: symbol lookup error: /opt/openldap2.4.25/libexec/openldap/accesslog-2.4.so.2: undefined symbol: verbstring_to_mask Could you help me? Thanks in advance Marco On Wed, Feb 23, 2011 at 10:02 AM, Marco Pizzoli <marco.pizzoli@gmail.com>wrote: > > On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc@symas.com> wrote: > >> Marco Pizzoli wrote: >> >>> Hi Howard, >>> thanks for this work. >>> >>> I noticed that you give me a baseDN under which I can have operations >>> logged. >>> If I would like to exclude one subtree from my principal tree, I need to >>> specify all the baseDN of other sibling-subtrees. >>> To do this do I need to poli-invoke accesslog overlay? >>> >> >> No, you can specify logbase multiple times in a single overlay. >> > > Ok, thanks. > > > >> Possibly we can extend the directive to handle exclusion as well as >> inclusion, to simplify this case. >> > > This is effectively what I would need, in this case. > > > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison
I compiled HEAD/Master branch and I tried setting logbase directive. It seems to work as requested! Thanks Marco
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?
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/
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@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
changed notes changed state Test to Release
changed notes changed state Release to Closed
in HEAD in RE24