On Sat, Feb 19, 2011 at 10:37 AM, Leonardo Carneiro chesterman86@gmail.comwrote:
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.