Hi all,
I'm currently doing a long overdue upgrade from 5.5 to 5.7, but I hit
what appears to be a regression in ldapd-5.6. Namely, a functional
ldapsearch with ldapd-5.5 fails with -5.6. Where this is more
problematic is that all other authentication attempts similarly fail
with 'Operations error (1)'. The root user, however, has no issue
binding, reading or writing the directory.
I have the following configuration file:
# $OpenBSD: ldapd.conf,v 1.2 2010/06/29 02:50:22 martinh Exp $
schema "/etc/ldap/core.schema"
schema "/etc/ldap/inetorgperson.schema"
schema "/etc/ldap/nis.schema"
listen on lo0 secure
listen on sis0 ldaps
listen on "/var/run/ldapi"
namespace "dc=example,dc=net" {
rootdn "cn=operator,dc=example,dc=net"
rootpw "{BSDAUTH}operator"
index cn
index uid
index mail
# deny access to any by any
# allow bind access to "cn=lookup,dc=example,dc=net" by any
# allow read access to any by "cn=lookup,dc=example,dc=net"
# #allow read access to children of
"ou=people,dc=example,dc=net" by "cn=lookup,dc=example,dc=net"
# allow bind access to children of "ou=people,dc=example,dc=net"
by any
# allow read access to any by self
}
With ldapd-5.5, running the following command and providing the user's password
returns the LDIF record for this user as expected.
ldapsearch -x -W -D uid=user,ou=people,dc=example,dc=net uid=user
Meanwhile, the ldapd-5.5 reports the following at -dv
Jul 14 12:59:17.570 [22255] accepted connection from 127.0.0.1 on fd 17
Jul 14 12:59:17.572 [22255] consumed 66 bytes
Jul 14 12:59:17.572 [22255] got request type 0, id 1
Jul 14 12:59:17.572 [22255] bind dn =
uid=user,ou=people,dc=example,dc=net
Jul 14 12:59:17.572 [22255] requesting 10 access to
uid=user,ou=people,dc=example,dc=net by any, in namespace dc=example,dc=net
Jul 14 12:59:17.573 [22255] successfully authenticated as
uid=user,ou=people,dc=example,dc=net
Jul 14 12:59:17.573 [22255] sending response 1 with result 0
Jul 14 12:59:17.574 [22255] consumed 63 bytes
Jul 14 12:59:17.574 [22255] got request type 3, id 2
Jul 14 12:59:17.574 [22255] base dn = dc=example,dc=net, scope = 2
Jul 14 12:59:17.574 [22255] requesting 01 access to dc=example,dc=net
by uid=user,ou=people,dc=example,dc=net, in namespace dc=example,dc=net
Jul 14 12:59:17.575 [22255] init index scan on [uid=user,]
Jul 14 12:59:17.575 [22255] found index uid=user,uid=user,ou=people,
Jul 14 12:59:17.575 [22255] lookup indexed key
[uid=user,ou=people,dc=example,dc=net]
Jul 14 12:59:17.575 [22255] found dn
uid=user,ou=people,dc=example,dc=net
Jul 14 12:59:17.575 [22255] requesting 01 access to
uid=user,ou=people,dc=example,dc=net by uid=user,ou=people,dc=example,dc=net,
in namespace dc=example,dc=net
Jul 14 12:59:17.576 [22255] found index uid=thom,uid=thom,ou=people,
Jul 14 12:59:17.576 [22255] scanned past index prefix [uid=user,]
Jul 14 12:59:17.576 [22255] 1 scanned, 1 matched, 0 dups
Jul 14 12:59:17.576 [22255] sending response 5 with result 0
Jul 14 12:59:17.576 [22255] finished search on msgid 2
Jul 14 12:59:17.576 [22255] consumed 7 bytes
Jul 14 12:59:17.576 [22255] got request type 2, id 3
Jul 14 12:59:17.576 [22255] current bind dn =
uid=user,ou=people,dc=example,dc=net
Jul 14 12:59:17.576 [22255] closing connection 17
With ldapd-5.6, however, the same ldapsearch command results in the following
error.
ldap_bind: Operations error (1)
There is also some binding errors in the much shorter server log.
Jul 14 13:02:18.732 [30050] accepted connection from 127.0.0.1 on fd 17
Jul 14 13:02:18.734 [30050] consumed 66 bytes
Jul 14 13:02:18.734 [30050] got request type 0, id 1
Jul 14 13:02:18.734 [30050] bind dn =
uid=user,ou=people,dc=example,dc=net
Jul 14 13:02:18.734 [30050] requesting 10 access to
uid=user,ou=people,dc=example,dc=net by any, in namespace dc=example,dc=net
Jul 14 13:02:18.734 [30050] sending response 1 with result 1
Jul 14 13:02:18.735 [30050] consumed 7 bytes
Jul 14 13:02:18.735 [30050] got request type 2, id 2
Jul 14 13:02:18.735 [30050] current bind dn = (null)
Jul 14 13:02:18.735 [30050] closing connection 17
Apparently, there is a problem authenticating (yes, I did type the password
properly), resulting in an empty bind, which leads to a failure to continue
further.
Did anybody encounter the same issue? Is there a known cause? How could this be
solved?
I now this is 5.6, and I should be worrying about 5.7, but I would rather have
a fully functional system before I move on to the next step.
Cheers.
--
Olivier Mehani <[email protected]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.
