Re: SASL External Clarification

[Dieter Kluenter <dieter@dkluenter.de>]

Hi,

Francois Beretti <francois.beretti@enatel.com> writes:

> Hello all
>
> I am about to close my SASL/External first experience, and try
> SASL/GSSAPI.
> But before this I'd like to answer some questions I have...
>
> I have two users on my system, francois and lambda
> For these two users I have valid certificates, with 
>   cn=francois,ou=people,dc=enatel,dc=local
>   cn=lambda,ou=people,dc=enatel,dc=local
> as subjects. The two are declared in the .ldaprc files, with their
> private keys
> root has also this stuff
>
> I have one entry
>   cn=francois,ou=people,dc=enatel,dc=local
> in my directory.
> I also have an administrator entry :
>   cn=root,dc=enatel,dc=local
>
> I defined these ACLs :
> # ACLs
> access  to dn=".*,ou=people,dc=enatel,dc=local"
>         by self write
>         by dn.base="cn=root,dc=enatel,dc=local" write
>         by * none

The DN cn=francois,ou=people,dc=enatel,dc=local
can only write to his own entry, as write includes read options, you
can read and write your own entry, but that's it, no further
permissions. 

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

only root has write permission, all others have no permissions at
all. 
> when I run ldapsearch -Y EXTERNAL -ZZ as francois,
> I got all the dn "cn=francois,..." data, and nothing else
>
> when I run it as root, I got all the entries data

as only root is allowd to see all entries.

> when I run it as lambda, I got nothing

as far as I understand your entries, lamda doesn't have an entry but
only a certificate, so only an anonymous bind could be made.
>
> All this stuff agrees with my ACLs, it's OK
>
> but when I look at the log for lambda's search, I see :
[...]
> dn="cn=lambda,ou=people,dc=enatel,dc=local" mech=EXTERNAL ssf=0
> Mar 12 10:40:56 linux-integ slapd[2613]: do_bind: SASL/EXTERNAL bind:
> dn="cn=lambda,ou=people,dc=enatel,dc=local" ssf=0

> so the ldapsearch client seems to do a bind with a user who doesn't
> exist in the directory !!

It is an anonymous bind.

> then the client starts the search :
> slapd[2612]: conn=5 op=2 SRCH base="dc=enatel,dc=local" scope=2
> filter="(objectClass=*)"
> indeed, for each entry the access is denied
>
> but according to my ACLs, a user who doesn't exist in the directory
> shouldn't be able to bind to it...
> Dieter said that I was doing an anonymous bind (I haven't yet these
> ACLs)
> Now anonymous bind should be forbidden
> Am I wrong ?

SASL doesn't know of any access control list, it just checks
authentification and authorization. As the private certificate of
lamda has been signed by your Certificate Authority, the certifcate of
lamda is valid, that is, lamda can bind to the server but any further
requests are denied.
[...]

-Dieter

-- 
Dieter Kluenter  | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter@schevolution.com
http://www.schevolution.com/tour