Re: proxy control does not verify existance of sasl-regex resulting dn (ITS#2965)

[igor@ipass.net]

On Fri, 13 Feb 2004, Pierangelo Masarati wrote:

>
> >
> > On Thu, 12 Feb 2004, Pierangelo Masarati wrote:
> >
> >>
> >> > Full_Name: Igor Brezac
> >> > Version: OPENLDAP_REL_ENG_2_1
> >> > OS: Solaris 9
> >> > URL: ftp://ftp.openldap.org/incoming/
> >> > Submission from: (NULL) (209.170.142.3)
> >> >
> >> >
> >> > Consider the following example:
> >> >
> >> > $ ldapwhoami -U igor -e '!authzid=u:adfasd'
> >> > SASL/DIGEST-MD5 authentication started
> >> > Please enter your password:
> >> > SASL username: igor
> >> > SASL SSF: 128
> >> > SASL installing layers
> >> > dn:cn=adfasd,ou=people,o=pb
> >> >
> >> > Where cn=adfasd,ou=people,o=pb does not exist and adfasd is a not a
> >> valid id.
> >>
> >> how did you set the sasl-authz-policy
> >> and what's the saslAuthzTo in "igor"'s
> >> entry?
> >>
> >
> > saslAuthzTo: cn=.*
>
> I suspect this is a "feature"; we need to be able to authz
> to users outside a single DSA's naming context, so, if you accept
> that saslAuthzTo can map to whatever identity, you implicitly
> accept authz'ing to non-existing users.  This is a(n undesirable)
> side effect of using a broad saslAuthzTo.
>
> Maybe it can be fixed by adding mure strict requirements on the
> existence of the authz'd identity, at least if its naming context
> is inside the directory; draft-weltman-ldapv3-proxy does not
> state anything about the existence or validity of the above
> identity; as a consequence, it is the responsibility of those who
> set "saslAuthzTo" to ensure it does not allow invalid identities
> to be assigned.  The importance of protecting it from unadvertent
> or malicious setting is noted in the docs, at least in slapd.conf(5).

I suppose I can enforce the existance of DN by using a subsearch in either
sasl-regex or saslAuthzTo or both.  This can create performance issues if
an admin is not careful.

Thanks,
-- 
Igor