[horde] Initial DN to bind with for LDAP preferences

[Atif Ghaffar]

Hi Jethro,
Did you get any replies to your mail?
If yes, can you forward them to the list, as the list managers have 
decided not to have a reply-to header after reading some rant "reply-to 
munging considered harmful" written by some bozo. (sorry I am pissed-off 
about this issue)

So about the DN stuff, you are right, this behaviour is not correct nor 
standard.

Should be reverted back to how it was. I havent seen any ldap client 
trying to generate a DN rather than looking up for one. Err wait. I know 
  a program who use to behave like this (MS Exchange server). Did 
someone in the dev group had a peek at their code :=)??


Also see this issue.
uid=aghaffar
ldap_base_dn=o=ispman

uid=aghaffar, o=ispman is not a DN in my directory.

the DN for uid=aghaffar is
uid=aghaffar, domain=developer.ch, o=ispman

I havent verified it, and I hope you are wrong, but considering....

best regards



Jethro R Binks wrote:
> Hi,
> 
> Just looking at the latest release candidates after a while away from
> Horde/IMP.
> 
> I want my users to login using their mail address, not their DN.  To this
> end, their mail address is stored in attribute mailLocalAddress.  The
> naming attribute for DNs is uid, as per convention.  Hence, I have
> $conf['prefs']['params']['uid'] = 'mailLocalAddress';
> in horde/config/horde.php.
> 
> In the previous version I was using, which was revision 1.14.2.3 of
> horde/lib/Prefs/ldap.php, the procedure was open an anonymous connection
> to LDAP server, search for the DN with the uid attribute I specified
> (mailLocalAddress), then bind using that full DN and the password that had
> been entered.
> 
> This behaviour changed in 1.14.2.4, so that afer the anonymous connect, a
> bind_dn string is built from the uid attribute data and the basedn, so in
> my case I end up with something like:
> $bind_dn = "mailLocalAddress=jethro.binks at strath.ac.uk,dc=people,dc=strath,dc=ac,dc=uk"
> Since that isn't a valid DN, the bind fails.  I note that the next step is
> a search for the full DN, which presumably gets used later on.
> 
> Why did this behaviour change in this way?  It's now rather less than
> useful in my case, as it doesn't allow me to abstract the login token I
> tell users to use (their email address) from internal gumph like their
> uid, which just confuses them.
> 
> A compromise might be to specify another bind dn to use while searching
> for the full DN.
> 
> Now it's a bit late here, so maybe I'm missing something a bit
> fundamental, but as it stands it no longer works a useful way for me ..
> 
> Thanks for comments,
> 
> Jethro.
> 
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Jethro R Binks                                   Computing Officer, IT Services
> Mailmaster, Listmaster, Webmaster,       University Of Strathclyde, Glasgow, UK
> Cachemaster                                           jethro.binks at strath.ac.uk
> 
> 


-- 
Atif Ghaffar
---------------------------.
           +41 78 845 31 64 ¦ tel
     aghaffar at developer.ch  ¦ email
     http://atifghaffar.com ¦ www
                    8206786 ¦ icq