[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Binding Problems with authentication

Perhaps ACLs wows.

Would you agree that this ACL would search and display all entries and hide the userpassword entry, without using any authentication ?


access to attr=userpassword
 by * search

access to *
  by * read

If so, why doesn't it show any results after a search

Log file snippet (search "joe")
---------------------------------------------
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 fd=6 connection from dyn-2-30.matrox.com (192.168.2.180) accepted.
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=0 BIND dn="" method=128
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=0 RESULT err=0 tag=97 nentries=0
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=1 SRCH base="LOCATION=DORVAL,O=MATROX,C=CA" scope=2 filter="(cn=*JOE*)"
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=1 RESULT err=0 tag=101 nentries=0
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=3 UNBIND
Jul 21 19:07:27 pluton.matrox.com slapd[20240]: conn=3 op=3 fd=6 closed errno=0
---------------------------------------------------






At 01:10 PM 07/21/99 -0700, you wrote: 
[replied back to list to share answer with others... and the archives]

Joe Novielli wrote:
> Is that [ACL restricting anonymous reads] OK?  I don't want anonymous
> to perform searches or reading on any attribute.

Quite understandable.  However, such access controls disallows
use clients which insist on searching for the entry to bind to.
Such "friendly bind" approaches, in my opinion, are only useful
where LDAP is deployed in "friendly" environments.

Clients should just bind to DNs... leaving "friendly" DN mappings
to the server implementations...  Clients that don't allow users
to specify a bind DN are flawed.

Kurt