#48145 RFE Add log file for rejected changes
Closed: fixed 2 years ago Opened 4 years ago by rmeggins.

Add log file for rejected changes

err=65: missing required attribute gidNumber

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

Still to be added:

  • Combined log file with audit (Configuration option)
  • Capture of internal events. (for example, memberof rejecting a change due to objectclass violation)
  • Logging code streamline to reduce duplication.

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!

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]:

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.

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.

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

2 years ago

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)

2 years ago

Metadata Update from @firstyear:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata