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?
