Re: Internal states o_dn and o_ndn are the same (ITS#2304)

[B.Candler@pobox.com]

On Fri, Feb 07, 2003 at 01:50:42PM +0000, Pierangelo Masarati wrote:
> > [Reason this is a problem for me: I have an LDAP backend which,
> non-standardly,
> > requires its bind DN to be case-sensitive. I can't validate the DN properly
> in
> > back-foo/search.c if it has been uppercased.]
> 
> I'm afraid yours is a poor assumption.  I understand your point,
> but for many reasons you should not rely on c_dn being not normalized;
> since in many cases it may result from a sasl authc/authz id, it is
> likely to be normalized in any case.

OK. My workaround has been to set 'edn' in my backend bind function, since
this propagates to c_dn without being normalised.

The current behaviour just seems inconsistent, which is why I reported it as
a bug: either c_dn is supposed to hold a normalised DN (in which case it can
be copied directly to o_ndn and there is no need for o_dn at all), or c_dn
is supposed to hold the unnormalised DN (which it doesn't).

> I think you should work on removing
> this limitation from your backend.  In case you plan to move your
> backend to 2.1 (which I stongly suggest) you'll find plenty of functions
> to handle your DNs.

I'll look at 2.1 at some point in the future. I know it's technically a
violation of the protocol, but the DN here needs to be case-sensitive
because it's being used to validate RADIUS and POP3 logins (which are also
case sensitive):

    dn: uid=FOObar, servgrp=pop3, dc=top     # two different accounts
    dn: uid=fooBAR, servgrp=pop3, dc=top

To follow the LDAP model properly I would have to allocate a unique ID which
was not related to the username:

    ("uid=FOObar")  ->   dn: uid=1234, servgrp=pop3, dc=top
    ("uid=fooBAR")  ->   dn: uid=9876, servgrp=pop3, dc=top

But this does not map well to the data model which my backend is having to
authenticate against.

In any case, thank you for your prompt reply.

Regards,

Brian.