On Sat, Feb 19, 2011 at 10:37 AM, Leonardo Carneiro <chesterman86@gmail.com> wrote:
On Sat, Feb 19, 2011 at 10:16 AM, <masarati@aero.polimi.it> wrote:
> On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati <
> masarati@aero.polimi.it> wrote:
>
>> Dieter Kluenter wrote:
>>
>>> Am Thu, 17 Feb 2011 11:28:59 -0200
>>> schrieb Leonardo Carneiro <chesterman86@gmail.com>:
>>>
>>>  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:
>>>>>
>>>>>  [...]
>>>
>>>> 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.
>>>>
>>>>  [...]
>>>
>>>> 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"
>>>>
>>>
>>> here uid=lscarneiro has been found
>>>
>>>  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=
>>>>
>>>
>>> invalid credentials were presented
>>>
>>
>> Or insufficient access or any other error that would not be disclosed
>> occurred.
>>
>> p.
>>
> Hi guys. i saw something interesting now look at here:
>
> fileserver:/etc/ldap/slapd.d# smbldap-usershow lscarneiro | grep
> userPassword
> userPassword: {CRYPT}$1$IDz3CwLp$r5MsSU8QyMyoHUv8r.eqi.
> fileserver:/etc/ldap/slapd.d# ldapsearch -v -LLL -h 192.168.0.2 -b
> "dc=dominio,dc=com,dc=br" -D "cn=root,dc=dominio,dc=com,dc=br" -w
> [password]
> "(uid=lscarneiro)"
> ldap_initialize( ldap://192.168.0.2 )
> filter: (uid=lscarneiro)
> requesting: All userApplication attributes
> userPassword:: e0NSWVBUfSQxJElEejNDd0xwJHI1TXNTVThReU15b0hVdjhyLmVxaS4=
>
> I think this explains why every single bind that i try with users other
> than
> cn=root gives me "invalid credentials". Is my assumption correct? Anyone
> knows why this passwords are not matching?

The two passwords match perfectly; only, the latter is base64-encoded for
LDIF presentation (as indicated by the double colon ('::')).

I suggest you run slapd with -d acl in order to see whether the
authentication failure is related to access control, incorrect password or
so.

p.

Thanks for the tip Masarati

I runned the test you told me and try to authenticate my apache in ldap. First it uses the cn=root to bind and search the uid informed by the user. Then, it trys to bind anonymous and match the password. I didn't understood this part of the log quite well. Here it is:


Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 
Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 BIND anonymous mech=implicit ssf=0 
Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 BIND dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128 
Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: result not in cache (userPassword) 
Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: auth access to "uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" "userPassword" requested 
Feb 19 10:24:07 fileserver slapd[18421]: => acl_get: [1] attr userPassword 
Feb 19 10:24:07 fileserver slapd[18421]: => acl_mask: access to entry "uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br", attr "userPassword" requested 
Feb 19 10:24:07 fileserver slapd[18421]: => acl_mask: to value by "", (=0)  
Feb 19 10:24:07 fileserver slapd[18421]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 
Feb 19 10:24:07 fileserver slapd[18421]: <= check a_dn_pat: * 
Feb 19 10:24:07 fileserver slapd[18421]: <= acl_mask: [2] applying +0 (break) 
Feb 19 10:24:07 fileserver slapd[18421]: <= acl_mask: [2] mask: =0 
Feb 19 10:24:07 fileserver slapd[18421]: => dn: [2]  
Feb 19 10:24:07 fileserver slapd[18421]: => dn: [3] cn=subschema 
Feb 19 10:24:07 fileserver slapd[18421]: <= acl_get: done. 
Feb 19 10:24:07 fileserver slapd[18421]: => slap_access_allowed: no more rules 
Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: no more rules 
Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 RESULT tag=97 err=49 text= 
Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=3 UNBIND 
Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 fd=15 closed

What can i learn from this?

Hey, it finally worked! I've added the follwing in the cn=config database:

olcAccess: {0}to *  by * read

Since there was no acl rules for this cn or the bdb.

I cannot thanks enough everyone that helped me, specially Andrews, Howard and Piearangelo for the killing tips.