Red Hat Bugzilla – Bug 1335492
Modifier's name is not recorded in the audit log with modrdn and moddn operations
Last modified: 2016-11-03 16:41:59 EDT
Description of problem: Modifier's name is not recorded in the audit log with modrdn and moddn operations Version-Release number of selected component (if applicable): RHEL Version: RHEL 7.3 x86_64 Server DS Version: 389-ds-base-libs-1.3.5.3-1.el7.x86_64 389-ds-base-1.3.5.3-1.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a new DS instance 2. Enable audit logging 3. Add a user entry as below [root@corp ~]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: inetorgperson uid: tuser cn: test user sn: user adding new entry "uid=tuser,ou=people,dc=example,dc=com" 4) Perform a modrdn operation on the entry as below [root@corp ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=people,dc=example,dc=com changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 modifying rdn of entry "uid=tuser,ou=people,dc=example,dc=com" 5) Check the audit log in /var/log/dirsrv/slapd-corp/ directory, only this information is recorded time: 20160512143153 dn: uid=tuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 as can be seen, the modifiers name is missing here 6) Perform a moddn operation on the entry as below [root@corp ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=testuser,ou=people,dc=example,dc=com changetype: moddn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=groups,dc=example,dc=com modifying rdn of entry "uid=testuser,ou=people,dc=example,dc=com" 7) check the audit logs time: 20160512143829 dn: uid=testuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 again, the modifiers name is missing here Expected results: The modifier's name should be recorded in the audit logs with modrdn and moddn operations
Upstream ticket: https://fedorahosted.org/389/ticket/48834
The change type recorded in the audit log for moddn operation on an entry is modrdn, here are the steps performed: 1. Modified the dn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=testuser,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifying rdn of entry "uid=testuser,ou=People,dc=example,dc=com" As can be seen, I've changed the rdn of the entry as well the the subtree to which it belongs. 2. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623153022 dn: uid=testuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn #The change type is modrdn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifiersname: cn=directory manager Is this correct?
It's an easy fix. Reopening a bug... diff --git a/ldap/servers/slapd/auditlog.c b/ldap/servers/slapd/auditlog.c index 0f4cc94..4605ae5 100644 --- a/ldap/servers/slapd/auditlog.c +++ b/ldap/servers/slapd/auditlog.c @@ -330,7 +330,7 @@ write_audit_file( case SLAPI_OPERATION_MODDN: newrdn = ((char **)change)[0]; addlenstr( l, attr_changetype ); - addlenstr( l, ": modrdn\n" ); + addlenstr( l, ": moddn\n" ); addlenstr( l, attr_newrdn ); addlenstr( l, ": " ); addlenstr( l, newrdn );
Sorry, let me take back my previous comment #c5. The changetype moddn is an alias of modrdn. So, the server does not distinguish them. Internally, there is only one operation which is MODRDN (e.g., the following log messages are from the access log. So, please ignore the difference in the audit log, too. dn: uid=tuser0,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=tuser00 deleteoldrdn: 1 [..] conn=6 op=1 MODRDN dn="uid=tuser0,ou=People,dc=example,dc=com" newrdn="uid=tuser00" newsuperior="(null)" [..] conn=6 op=1 RESULT err=0 tag=109 nentries=0 etime=0 dn: uid=tuser00,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser000 deleteoldrdn: 1 [..] conn=8 op=1 MODRDN dn="uid=tuser00,ou=People,dc=example,dc=com" newrdn="uid=tuser00" newsuperior="(null)" [..] conn=8 op=1 RESULT err=0 tag=109 nentries=0 etime=0 Thanks.
DS builds: 389-ds-base-1.3.5.6-1.el7.x86_64 389-ds-base-libs-1.3.5.6-1.el7.x86_64 Following are the steps performed for verification: 1. Enabled audit logging on a standalone DS instance [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on modifying entry "cn=config" 2. Added a user entry [root@ds ~]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: inetOrgPerson uid: tuser cn: test user sn: user adding new entry "uid=tuser,ou=People,dc=example,dc=com" 3. Modified the rdn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=People,dc=example,dc=com Changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 modifying rdn of entry "uid=tuser,ou=People,dc=example,dc=com" 4. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623152639 dn: uid=tuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 modifiersname: cn=directory manager 5. Modified the dn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=testuser,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifying rdn of entry "uid=testuser,ou=People,dc=example,dc=com" 6. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623153022 dn: uid=testuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifiersname: cn=directory manager
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html