Hi,

 > Could you show me what is different between the config. and the
 > following one?

before my first posting the config was:

-P192.168.25.50:389
SERVER=ldap
FSV=sslway
PERMIT="ldap:1.2.3.4:*"
VARDIR=${EXECDIR}

It worked, but I had to append "@1.2.3.4:636" to the base-dn.
And the response dn contained the "@1.2.3.4" suffix, too.


Between the first and second post, I had trouble with the MOUNT option.
First I tried something like this:
MOUNT="ou=* ldaps://147.172.30.84:636 nocase"
MOUNT="ou=uni* ldaps://147.172.30.84:636 nocase"
but nothing worked.

Before the second posting the config was:

-P192.168.25.50:389
SERVER=ldap
FSV=sslway
PERMIT="ldap:1.2.3.4:*"
VARDIR=${EXECDIR}
MOUNT="* ldaps://1.2.3.4:636 nocase"
OWNER=delegate/delegate
DGROOT=/opt/local/app/delegate-9.6.3

But I had to tweak the source code:

src/ldap.c, mount() function:

   if( strneq(server,"ldaps://",8) ){
     setVStrElem(srchroot,0,'@');
     dp = wordscanY(server+8,QVStr(srchroot+1,srchroot),256,"^/");
       if( *dp == '/' ){


After your answer I undid these changes and removed the "s" in the MOUNT:

-P192.168.25.50:389
SERVER=ldap
FSV=sslway
PERMIT="ldap:1.2.3.4:*"
VARDIR=${EXECDIR}
MOUNT="* ldap://1.2.3.4:636 nocase"
OWNER=delegate/delegate
DGROOT=/opt/local/app/delegate-9.6.3

It didnt matter wheather I had the "@1.2.3.4" in the base_dn or not.
The dn suffix in the response is still there, in both cases.


Now I tried the tcp relay.
Thanks for the hint concercing the tcp relay :)

-P192.168.25.50:389
SERVER=tcprelay://1.2.3.4:636
FSV=sslway
VARDIR=${EXECDIR}
OWNER=delegate/delegate
DGROOT=/opt/local/app/delegate-9.6.3

Great, works on the fly.

I consider using this configuration.
I think, there is no risk of abusing the tcp relay, because the 
destination port and IP are not freely selectable.


But if you had a patch for the ldap.c, I would use this.
There must be some code in the ldap.c, which append the "@1.2.3.4" to 
the dn in the response. :-)



Bye,

Kevin