Problème de connexion ldapsearch sur un AD LDS

J'ai été confronté à un problème curieux d'accès à un serveur AD LDS à partir d'un container de type Forgerock DS. 

Côté réseau, tout était OK, les ports ouverts d'un côté comme de l'autre.

Par contre une commande ldapsearch tombait en erreur :

/opt/opendj/bin/ldapsearch  --hostname 10.1.2.3 --port 389 -D "CN=admin,CN=Admin-Users,dc=example,dc=fr" -w admin2003 \
-b "CN=Applications,DC=example,DC=fr" "(objectclass=exApplications)"
Unable to connect to the server: 91 (Connect Error)
Additional Information:  Remote close

Pas très parlant.

Côté AD LDS, en modifiant le niveau de logs, on a :

Internal event: The LDAP server returned an error.
 
Additional Data
Error value:
00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v4563

Peu d'éléments complémentaires. Sachant qu'en plus, en local sur la machine AD LDS, la même connexion se fait sans problème.

En investiguant un peu plus, je tente une connexion en mode "startSSL", pour voir si j'ai le même comportement :

/opt/opendj/bin/ldapsearch --useStartTls --hostname 10.1.2.3

Et là, le message d'erreur côté machine cliente est différent et me met sur la piste :

An error occurred while parsing the command-line arguments:  You may not
provide both the --useStartTls and the --useSsl arguments

See "ldapsearch --help" to get more usage help

Comme je n'ai pas précisé les 2 options (useStartTls et useSsl) dans ma ligne de commande, l'option useSsl doit venir d'un paramétrage par défaut.

Et en effet, par défaut les commandes ldap utilisent un fichier de propriétés (/opt/opendj/config/tools.properties) qui définit un certain nom de paramètres par défaut.
On y trouvait notamment :

useSsl=true
trustAll=true

Du coup lorsque je tentais une connexion "en clair" sur le port 389, AD LDS recevait une requête sur un port non chiffré, mais avec une instruction qui disait que la connexion devait être chiffrée... d'où les messages d'erreur.

En utilisant l'option "--noPropertiesFile" dans le ldapsearch, on peut du coup accéder en LDAP sur le port 389, et récupérer les données.

L'autre option (plus sécurisée), serait d'utiliser du LDAPS entre les deux serveurs.