On Sat, Feb 19, 2011 at 10:37 AM, Leonardo Carneiro <[email protected]>wrote:
> On Sat, Feb 19, 2011 at 10:16 AM, <[email protected]> wrote: > >> > On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < >> > [email protected]> wrote: >> > >> >> Dieter Kluenter wrote: >> >> >> >>> Am Thu, 17 Feb 2011 11:28:59 -0200 >> >>> schrieb Leonardo Carneiro <[email protected]>: >> >>> >> >>> On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < >> >>>> [email protected]> 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.
