Re: ldap auth does not works after openldap upgrade

To: openldap-technical@openldap.org

Subject: Re: ldap auth does not works after openldap upgrade

From: Leonardo Carneiro <chesterman86@gmail.com>

Date: Thu, 17 Feb 2011 11:28:59 -0200

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=uOco04ZhrzbZwWGQhZAgCMTehaT00bHDBKMw3C1+BfE=; b=vwElH9og/uJx4H5BKTSZ9o0RYQTae+5g6smemwss/h42o5ggVIsr88pThNT4XDzEMP 0T1VB5JvH0iHz4XzmotHx1BIOYNLpV2ftHTy0U0so0N6NPOf5Ira8Yt5JIWdhhSG6LAt TGsKGwvdPmVeZvT4TrsirGJaPxeG1RQKIzCaw=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DgJNbZMSsU5duW5A0dBHVmH8cvktZqnMhIfVNuZQjBU8q6oRceRpTidmArYoCY1VTq tk1KOFLcWcMJQPQugh/q9mrZ99BxDAFdCMcITsqpgdupxtiDaOfP4uQ6FVIy5nHG4kBm KFNMc1GvBmZ7rRF5aAhvmDCGltE5d9hdvmUSg=

In-reply-to: <20110217110950.GL13985@slab.skills-1st.co.uk>

References: <20110215163018.GD13985@slab.skills-1st.co.uk> <AANLkTimz5SB0AYmHnyGF8oDmUcngiyVYyh15sxnEpN9m@mail.gmail.com> <20110215172026.GE13985@slab.skills-1st.co.uk> <AANLkTinJLZhsjq+-P-CXZpwHdkbPP21vo2Ou5MTv9N7R@mail.gmail.com> <20110215184000.GF13985@slab.skills-1st.co.uk> <AANLkTin6mjH+s-3tprRnv8yKyHopZ2JJohojshVj=4nR@mail.gmail.com> <20110216104327.GG22964@slab.skills-1st.co.uk> <4D5BAC27.6030201@symas.com> <20110216121636.GG13985@slab.skills-1st.co.uk> <4D5C5DE9.3080901@symas.com> <20110217110950.GL13985@slab.skills-1st.co.uk>

On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay <andrew.findlay@skills-1st.co.uk> wrote:

On Wed, Feb 16, 2011 at 03:29:45PM -0800, Howard Chu wrote:

> >Similarly I cannot find anything that
> >clearly describes the use of SASL EXTERNAL with ldapi.
>
> http://tools.ietf.org/html/draft-chu-ldap-ldapi-00

Excellent, thanks. That one is remarkably hard to find without a direct
pointer. Could you add it to the doc/drafts directory in the source perhaps?

Andrew

Here is the search that Apache is doing. Note that "usuarios" in the search means "users" in portuguese. It doesn't seems even to check if the user really does part of the group defined in the apache config.

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 fd=21 ACCEPT from IP=172.16.14.2:34691 (IP=0.0.0.0:389)

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 BIND dn="cn=root,dc=dominio,dc=com,dc=br" method=128

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 BIND dn="cn=root,dc=dominio,dc=com,dc=br" mech=SIMPLE ssf=0

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 RESULT tag=97 err=0 text=

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH base="ou=Usuarios,dc=dominio,dc=com,dc=br" scope=2 deref=3 filter="(&(objectClass=*)(uid=lscarneiro))"

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH attr=uid

Feb 17 11:11:39 fileserver slapd[2054]: <= bdb_equality_candidates: (uid) not indexed

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 ENTRY dn="uid=lscarneiro,ou=usuarios,dc=dominio,dc=com,dc=br"

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND anonymous mech=implicit ssf=0

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 RESULT tag=97 err=49 text=

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=3 UNBIND

Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 fd=21 closed