Bug 1057803

Summary:	logconv errors when search has invalid bind dn
Product:	Red Hat Enterprise Linux 7	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	amsharma
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:33:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Noriko Hosoi 2014-01-24 23:36:08 UTC

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.

Comment 2 Amita Sharma 2014-12-29 10:50:42 UTC

[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.

Comment 4 errata-xmlrpc 2015-03-05 09:33:37 UTC

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