Add log file for rejected changes
time: 20150319052306Z dn: cn=hr,ou=Groups,dc=gsslab,dc=pnq,dc=redhat,dc=com changetype: add objectClass: posixGroup cn: hr memberUid: pabqrodrigues memberUid: shapgoh memberUid: carfmeijer modifiersname: cn=manager,dc=gsslab,dc=pnq,dc=redhat,dc=com
Most companies use a lot of third party products with their LDAP servers. In many cases, with the current software, to figure out how the client application is broken, we need to do a session packet capture, and analyze the traffic. This is a pretty time-consuming method of figuring out what the client is doing wrong, considering that the LDAP server has to have the data to log at the point where it is rejecting the modify operation. In our environment, it's not something we can just turn on for both of our production master servers with little provocation. Typically, we handle that by sending the application back to our dev environment - but sometimes, the app only has a prod instance so they don't want to do that. We also have one high profile app - which happens to be the one that runs into situations where we would want this feature the most - which takes a minimum of 30 minutes to change which LDAP environment it points at - and it generates hundreds of thousands of LDAP queries against the new LDAP environment during those 30 minutes.
This feature would normally not be turned on. We'd enable it when we were working with a problematic third-party app, and then disable it.
Undo this change.
Milestone changed from 1.3.5 backlog to 1.2.11.33
Initial implementation of auditfail logging capability. 0001-Ticket-48145-RFE-Add-log-file-for-rejected-changes.patch
Still to be added:
Thank you for the fixes and explanations to my review comments, William. You have my ack.
Mark, if you agree, please set "ack" to Review.
Thanks!
Pushed to master commit 5420e15
Allow the logging events to be merged into the auditlog. 0001-Ticket-48145-Allow-merged-logging-of-audit-events.patch
When nsslapd-auditfaillog is not specified the value of nsslapd-auditlog will be used for audit and auditfail events. If auditfaillog is specified, all results with RC != LDAP_SUCCESS (0) will go to the auditfail handler.
Replying to [comment:12 firstyear]:
Looks like you removed the auditfail log rotation policy attributes in your recent patch. If we have a fail-log it will need its own rotation policy. Can't have it growing out of control.
I remove the options in the template, but there are defaults still in the DS code for this.
I removed them to reduce confusion about the audit log in the default case, where you have audit and auditfail going to the same log, you only need the audit log rotation settings.
If you have the auditfail rotation settings there, but no file specified this could confuse people as to what it's doing there.
I can re-add the template defaults if you like, but I think it's better to remove them.
Ack
commit 6c35d364beccda13d0295b62776976ab112992a7
To ssh://git.fedorahosted.org/git/389/ds.git 026956c..b408ffc master -> master
Thank you!
Metadata Update from @firstyear: - Issue assigned to firstyear - Issue set to the milestone: 1.3.5 backlog
As per design doc http://directory.fedoraproject.org/docs/389ds/design/audit_improvement.html, the fail log (and audit log) has now the format:
time: 20151111152800 dn: uid=test,dc=example,dc=com result: 65 / New field / changetype: modify replace: objectClass objectClass: account objectClass: posixGroup objectClass: simpleSecurityObject objectClass: top -
Since the access and error logs now use high resolution time stamps (ex. [17/May/2017:14:25:09.766543177 +0200]), it would be very helpful and coherent to display the same HR time instead of low-resolution "time: 20151111152800" in audit and audit fail logs.
Yes, it would be actually. I'll see about if this can be done easily or not. Thanks @pj101
I also had a query on IRC if it's possible to specify own format of timestamps for access logs. Right now it's hardcoded and doesn't respect system locale settings.
Metadata Update from @firstyear: - Issue set to the milestone: 1.4 backlog (was: 1.3.5 backlog)
https://pagure.io/389-ds-base/issue/49260 will address this :)
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1476
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.