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

Re: SASL / DIGEST-MD5



--On Friday, March 14, 2003 4:33 PM +0100 Francois Beretti <francois.beretti@enatel.com> wrote:

Hi Quanah,

Le ven 14/03/2003 à 15:22, Quanah Gibson-Mount a écrit : 
Francois,

When you first bind to the ldap server, it has no idea who <you> are.
So  what happens is that you are at first seen as an "anonymous" user in
the  initial stages of the authentication process.  Since you are not
giving  search access to the objectclass it needs to figure out who you
are, it is  ending.


You are right, it's an ACL problem because if I have a "access to * by *
read" it works :)

Thank you very much, but with your ACLs I still can't authenticate

That doesn't surprise me, I wasn't giving you the ACL's that would allow you to authenticate, as I could tell from your message exactly what it was looking for that you needed to give access to. ;)


Also, your ACL's are likely incorrect in their arrangement.  If you want
cn=root,dc=enatel,dc=local to have write access to your entire tree,
they  should look like:

access to dn.base=""
        by * read

I don't really understand this ACL
you grant read access on empty entry ?
Is this used to list the DNs of the directory ?


No, this allows SASL to query the list of available authentication methods.


access to *
         by dn.base="cn=root,dc=enatel,dc=local" write
         by * break

are you sure of the line "by * break" ?
I believe that break should be used in addition to an access granted
Maybe you meant "by * read break" ?

Nope, I meant by * break. That will have openldap continue on to the other ACL statements and process them.


access to dn=".*,ou=people,dc=enatel,dc=local"
         by self write
         by dn.base="cn=root,dc=enatel,dc=local" write
         by * none


I have to add "by anonymous search" in the third ACL to get it working
And after that I can comment the first ACL without effect

Yup. If you want, and can figure out exactly what it information it is wanting to look at, you can restrict this even more. For us, any incoming connection needs access to the krb5PrincipalName attribute (since we are doing GSSAPI authentication for our applications), so I have the line:

access to attr=krb5PrincipalName,member
       by * search

--Quanah


--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html