Re:[turba] Re: Using imp and turba with an Exchange 2000 mail server yvon.quere at
Tue Apr 1 09:19:58 PST 2003

>Actually, my first name is Giannis, which is the greek
equivelent of the 
>English name "John". No harm done :)

Ok, got that one Giannis ;-)

>Regarding your configuration:

I'm gonna make myself clearer : here's another tweaked conf :

    'params' => array(
        'server' => 'dummyad',
	'root' => 'dc=linux,dc=local',
        'bind_dn' =>
	'bind_password' => 'airial',
       	'dn' => array('cn'),
	'objectClass' => array('organizationalPerson'),
       	'encoding' => 'utf8',
	'version' => 3,
	'filter' => 'objectClass=organizationalPerson',

>1) port: My port is 3268. Unless you have only one server,
you should >use the 
>server running the Global Catalog service. This is usually
the first >server in 
>your domain.

I'm not a W2K specialist despite having a couple ones working
with me. Mail clients are used to "talk" LDAP to this server
on port 389 and I honestly don't understand (someone tried to
explain to me but failed) the Global Catalog Service thing
compared to "Active Directory".

>2) bind_dn: You should use ONLY the username. For security
reasons, I >wouldn't 
>use the administrator's account, becouse you would put his
passowrd in 

That's for sure Giannis. You're absolutely right on that one.
I've setup a test W2K to figure all the problems out of Turba
so I didn't care about security. Of course, I should create a
turba-specific user. I agree with you.

This leads me to another question : can Active Directory
answer to anonymous LDAP bind requests ? OpenLDAP can. And
regarding Turba configuration, I'd prefer not to include any
password, even if it's the one of an unprivileged, accountless

>3) dn & objectClass: remove these for now. These are just
used to filter >our 
>results. You should first get SOME results, and they try to
filter them.

I've gone a step further. As you see, I've refined my filters
after confirming that I *defintely* had results from the LDAP
queries. People I want returned are all orgPerson, thus the
filter and the objectClass.

Problem is that I get a correct result with ldapsearch :

ldapsearch -D 'cn=Administrateur,cn=Users,dc=linux,dc=local'
-w airial -h dummyad  -b 'dc=linux,dc=local'  -v  -x -P 3
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
name: Administrateur
# numEntries: 1

Debug info in Turba with such a request (Name=Ad) :

[turba] LDAP search by yvon.quere at
root = dc=linux,dc=local (dummyad); filter =

Looks good.

I've added additionnal debug logging in the code (ldap.php) :

    function read($criteria, $dn, $fields)


	Horde::logMessage(sprintf('LDAP result entry %s: dn = %s
(%s); filter = "%s"; attributes = "%s"',
                                  $this->ds, $dn,
$this->server, $filter, implode(', ', $attr)),
                          __FILE__, __LINE__, LOG_DEBUG);

        $res = @ldap_read($this->ds, $dn, $filter, $attr);
        if (!$res) {
	  Horde::logMessage("Nothing returned by ldap_read
:-(",__FILE__, __LINE__, LOG_DEBUG);

Output in syslog is :

[turba] LDAP result entry Resource id #1: dn =
CN=Administrateur,CN=Users,DC=linux,DC=local (dummyad); filter
= ""; attributes = "dn, cn, mail, sn"

So the initial LDAP query filtered out the (only) real user
(orgPerson) with name matching *Ad*, looks good but then ...

[turba] Nothing returned by ldap_read :-(

Looks like the ldap_read fails ! And then Turba displays no
result at all !
What is done by this the ldap read ? Getting additionnal
fields out of the matching people obtained by the first
request I guess. Why does it fail ?

That's why I guess my sources.php entry is not so bad but ...

I'm wondering if the various attributes seen (dn,cn,mail,sn)
*MUST* be present on each entry ?!?

I've checked with GQ and user "Administrateur" DOES have
non-empty such attributes...

How can I go further ? Can I trace (which tool ?) LDAP
requests/answers on the W2K side ???

Any help appreciated


Accédez au courrier électronique de La Poste : ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"

More information about the turba mailing list