Red Hat Bugzilla – Bug 1057803
logconv errors when search has invalid bind dn
Last modified: 2015-03-05 04:33:37 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47675 If there is a search request with an invalid base dn, the access log will look like this: [01/Jan/2014:23:23:23 -0800] conn=1 op=1 SRCH dn="uid=,ou=people,dc=example,dc=com" authzid="(null)", invalid dn [01/Jan/2014:23:23:23 -0800] conn=1 op=1 RESULT err=34 tag=101 nentries=0 etime=0 This causes logconv.pl to report uninitialized variable use. It doesn't know how to parse the authzid and invalid dn parts.
[root@dhcp201-126 ~]# ldapsearch -LLL -D "cn=directory manager" -w Secret123 -p 389 -h localhost -b dn="uid=,ou=people,dc=example12,dc=com" No such object (32) Access Logs ============== [29/Dec/2014:16:19:42 +051800] conn=18 fd=64 slot=64 connection from ::1 to ::1 [29/Dec/2014:16:19:42 +051800] conn=18 op=0 BIND dn="cn=directory manager" method=128 version=3 [29/Dec/2014:16:19:42 +051800] conn=18 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [29/Dec/2014:16:19:42 +051800] conn=18 op=1 SRCH base="dn=uid=,ou=people,dc=example,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL [29/Dec/2014:16:19:42 +051800] conn=18 op=1 RESULT err=32 tag=101 nentries=0 etime=0 [29/Dec/2014:16:19:42 +051800] conn=18 op=2 UNBIND [29/Dec/2014:16:19:42 +051800] conn=18 op=2 fd=64 closed - U1 [29/Dec/2014:16:20:04 +051800] conn=19 fd=64 slot=64 connection from ::1 to ::1 [29/Dec/2014:16:20:04 +051800] conn=19 op=0 BIND dn="cn=directory manager" method=128 version=3 [29/Dec/2014:16:20:04 +051800] conn=19 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [29/Dec/2014:16:20:04 +051800] conn=19 op=1 SRCH base="dn=uid=,ou=people,dc=example12,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL [29/Dec/2014:16:20:04 +051800] conn=19 op=1 RESULT err=32 tag=101 nentries=0 etime=0 [29/Dec/2014:16:20:04 +051800] conn=19 op=2 UNBIND [29/Dec/2014:16:20:04 +051800] conn=19 op=2 fd=64 closed - U1 Logs don't have authzid and invalid dn parts, hence marking VERIFIED.
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-2015-0416.html