I'd need to contact my servers over SSL protected connections (port 636).
Additionally, the client has to provice a client certificate. I found your FAQ
about SSL and I'm familar with windows SSL (certificate) handling, but I have
no idea how to make ldapadmin provide the installed client certifiacte.
But also if I relax security one step and allow SSL connections without client
certificates, I couldn't manage to get ldapadmin to connect to the server. I
only get "server down" error, and in the servers log I can't see any
connection attempt. Seems TCP socket 636 doesn't work at all???
Thanks for any help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LdapAdmin can not use client certificates at the time. But if you allow
connections without the client certificates it should work. With no connection
attempt logged, this is a kind of behaviour I could expect if
a.) There is a networking problem (port is blocked by router or firewall or
unaccessible from the client machine)
b.) The ssl serveces/deamons are not started (server is not listening for the
ssl)
c.) The port is configured to something else then 636 (either on client or on
the server side)
Also, you could run into this problem if you are using pre-XPSP3 OS, but then
at least a failed connection attempt should appear in the logs.
FYI, I have just uploaded the new release with TLS support included. I wanted
to add the client certificate support but didn't have enough time, this should
be in the next release.
Cheers,
Tihomir
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot for your ongoing work to continously improve ldapadmin, the
already best tool out there in my opinion.
Unfortunately I can roule out all 3 points you mentioned as the source of the
problem. (telnet ip 636 works, ldapsearch with uri ldaps://ip works, both
previous confirm that 636 is in use)
But I have another gimmick: Probably XPproSP3 doesn't support AES. I have
limited SSL ciphers to AES (since my crypto hardware only supports AES ).
While trying to protect the connection with IPSec transport mode, which I did
for all my unix (FeeeBSD) workstations, I saw that I can only use 3des (and
des) for ESP in XP....
If i'll ever proofe that, I'll let you know, everybode else seeing that
problem is welcome to try without cipher limitations and post...
One different question: Do you test ldapadmin with wine? As you may have
noticed, I'm actual using unix only, just because I'm dependent on VMwares VI-
Client, I have on PX virtual machine, where I currently run ldapadmin. But of
course I'd prefer a native version, or at least the ability tu run locally
with only wine dependency... Have you ever considered a QT or GTK port?
Thanks a lot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Curiosity was too strong - neglected any todo list - and was corwned with
complete success :-) Even client certificates work!
After I had added DES-CBC3-SHA as allowed cipher (in slapd.conf), the
connection from XP worked.
I forced to check for valid client certificate, and to my big astonishment, I
got a WinXP popup window requesting my confirmation that a application want's
to make use of my private secret key :-)
I falsified that and deinstalled my client certificate, and connection was
rejected. Once installed the pkcs12 cert again, connection works!! :-))
(ldapadmin version 1.2.0.0)
Very curious if there's any chance that wine provides the same SSL protection
mechanisms... Any hints welcome!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds great, I was about to implement the client certificate support
into LdapAdmin and it looks as it's not needed at all! The functionality seems
to be built into the OS. I guess that Vista and 7 would behave the same way.
Great news, thanks to your curiosity ;-)
If you some day try to get a fund for porting (extend ldapadmin to be
portable), count on me - I'll donate something...
(ldapadmin would also make sense on SymbianS60 (via qt), android, iOS...)
Good to know that wine and ldapadmin work. If wine's crypto API doesn't
provide client certificate support, I'll post. But it's not relevant for me,
my ldap connections are IPsec protected on FreeBSD unix.
But there's one point where you may still want to pimp ldapadmin for client
certificate support: If the user has more than one certificate, I can't
imagine how windows would decide which one to use. I guess, the application
has to tell windows what certifacte to offer to the peer. Out of curiosity,
what IDE do you use? I'm wondering how automagic SSL handling for network
sockets is done? I'd like to read the used APIs, just for fun (and security
clues). I'm no windows coder, nor will I really understand the API I guess,
but I'd like to try to get an idea.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, basically the Windows doesn't decide, the server does. The server
requests a client certificate and sends a list of trusted CA's. The client
loooks up in the certificate store to see if it has a client certificate
issued by one of the server-trusted CA's and returns a certificate context if
so. There is no need for the application to decide which certificate to use,
it just has to be a valid certificate issued by one of the server-trusted
CA's.
I'm using Delphi 5 and Delphi 7, but the next release will probably get a port
to XE2, if I manage to acqure one.
The SSL automagic is contained in Windows LDAP API. In short, ldap_sslinit
initializes ssl connection and ldap_start_tls stats a TLS conection. It all
works well if you have a valid certificate in the store, but if not, the
connection would just be shut down with the 'server down' message without any
hint on what's going on. The complicated part is to inform the user that the
certificate cannot be trusted and to let him decide whether to accept or deny
the connection (VERIFYSERVERCERT callback function).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
P.S. The XE2 apparently has a multiplatform support for windows, mac and ios -
maybe there is a chance after all, I have to investigate this possibility.
Nice from you to offer help, thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2013-02-20
i am try to connect openLdap from LdapAdmin tool, I am getting "LDAP error ! Unavailable: Proxy cannot contact remote server." I am running this on port 636. Samething is working fine for port 389. Can you please suggest me where should i change and where i am wrong.
Thanks in advance.
If possible please send detail on my mail id tothekaushal@gmail.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It look like you are connecting to the proxy server and the the proxy server accepts ssl connections but the upstream server does not. Just a guess, however...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2013-09-19
LDAP admin is not able to connect to a different port than 636 for SSL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your LDAP database is probably empty so that would be normal. You have to have at least root dn in your database. You can create this with LDAPAdmin editor or import it from LDIF file.
Cheers,
Tihomir
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because this library wasn't even existant at the time LdapAdmin was started and the port would be a major task. Also, beeing basicaly a Windows tool (unfortunately, due to compiler restrictions) the Windows LDAP API is a logical choice. Besides, the Windows LDAP API is there for almos 20 years now and a VITAL part of Windows OS. It is very mature, stable and reliable. If you take a look at the LDAPAdmin forums, you will see that the problems which can be traced to the Windows API are a really rare and very special (such as limited Cypher support). And, there is no library without problems. There is a port of LdapAdmin to FreePascal maintained by Ivo Brhel, you can check it here: http://ivb.sweb.cz/ldap-en.html. He's doing a great job of porting but it is a major effort and not everything is yet ported. You should check this out. I am trying to support him and I've changed some libraries already to provide a better portability support and as I wrote the 1.8 release, I was keeping the code as portable as I could. So, at some point LdapAdmin may be OS independant but it's still a long way to go.
Cheers,
Tihomir
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'd need to contact my servers over SSL protected connections (port 636).
Additionally, the client has to provice a client certificate. I found your FAQ
about SSL and I'm familar with windows SSL (certificate) handling, but I have
no idea how to make ldapadmin provide the installed client certifiacte.
But also if I relax security one step and allow SSL connections without client
certificates, I couldn't manage to get ldapadmin to connect to the server. I
only get "server down" error, and in the servers log I can't see any
connection attempt. Seems TCP socket 636 doesn't work at all???
Thanks for any help!
The LdapAdmin can not use client certificates at the time. But if you allow
connections without the client certificates it should work. With no connection
attempt logged, this is a kind of behaviour I could expect if
a.) There is a networking problem (port is blocked by router or firewall or
unaccessible from the client machine)
b.) The ssl serveces/deamons are not started (server is not listening for the
ssl)
c.) The port is configured to something else then 636 (either on client or on
the server side)
Also, you could run into this problem if you are using pre-XPSP3 OS, but then
at least a failed connection attempt should appear in the logs.
FYI, I have just uploaded the new release with TLS support included. I wanted
to add the client certificate support but didn't have enough time, this should
be in the next release.
Cheers,
Tihomir
Thanks a lot for your ongoing work to continously improve ldapadmin, the
already best tool out there in my opinion.
Unfortunately I can roule out all 3 points you mentioned as the source of the
problem. (telnet ip 636 works, ldapsearch with uri ldaps://ip works, both
previous confirm that 636 is in use)
But I have another gimmick: Probably XPproSP3 doesn't support AES. I have
limited SSL ciphers to AES (since my crypto hardware only supports AES ).
While trying to protect the connection with IPSec transport mode, which I did
for all my unix (FeeeBSD) workstations, I saw that I can only use 3des (and
des) for ESP in XP....
If i'll ever proofe that, I'll let you know, everybode else seeing that
problem is welcome to try without cipher limitations and post...
One different question: Do you test ldapadmin with wine? As you may have
noticed, I'm actual using unix only, just because I'm dependent on VMwares VI-
Client, I have on PX virtual machine, where I currently run ldapadmin. But of
course I'd prefer a native version, or at least the ability tu run locally
with only wine dependency... Have you ever considered a QT or GTK port?
Thanks a lot!
Curiosity was too strong - neglected any todo list - and was corwned with
complete success :-) Even client certificates work!
After I had added DES-CBC3-SHA as allowed cipher (in slapd.conf), the
connection from XP worked.
I forced to check for valid client certificate, and to my big astonishment, I
got a WinXP popup window requesting my confirmation that a application want's
to make use of my private secret key :-)
I falsified that and deinstalled my client certificate, and connection was
rejected. Once installed the pkcs12 cert again, connection works!! :-))
(ldapadmin version 1.2.0.0)
Very curious if there's any chance that wine provides the same SSL protection
mechanisms... Any hints welcome!
This sounds great, I was about to implement the client certificate support
into LdapAdmin and it looks as it's not needed at all! The functionality seems
to be built into the OS. I guess that Vista and 7 would behave the same way.
Great news, thanks to your curiosity ;-)
I've never tested LdapAdmin on the wine but I know that there are folks out
there using it so. There is a wine compatibility report here: http://appdb.wi
nehq.org/objectManager.php?sClass=application&iId=11115.
As for the porting, I did think about that but it would be a LOT work to do so
it's not very probable...
If you some day try to get a fund for porting (extend ldapadmin to be
portable), count on me - I'll donate something...
(ldapadmin would also make sense on SymbianS60 (via qt), android, iOS...)
Good to know that wine and ldapadmin work. If wine's crypto API doesn't
provide client certificate support, I'll post. But it's not relevant for me,
my ldap connections are IPsec protected on FreeBSD unix.
But there's one point where you may still want to pimp ldapadmin for client
certificate support: If the user has more than one certificate, I can't
imagine how windows would decide which one to use. I guess, the application
has to tell windows what certifacte to offer to the peer. Out of curiosity,
what IDE do you use? I'm wondering how automagic SSL handling for network
sockets is done? I'd like to read the used APIs, just for fun (and security
clues). I'm no windows coder, nor will I really understand the API I guess,
but I'd like to try to get an idea.
Thanks!
Well, basically the Windows doesn't decide, the server does. The server
requests a client certificate and sends a list of trusted CA's. The client
loooks up in the certificate store to see if it has a client certificate
issued by one of the server-trusted CA's and returns a certificate context if
so. There is no need for the application to decide which certificate to use,
it just has to be a valid certificate issued by one of the server-trusted
CA's.
I'm using Delphi 5 and Delphi 7, but the next release will probably get a port
to XE2, if I manage to acqure one.
The SSL automagic is contained in Windows LDAP API. In short, ldap_sslinit
initializes ssl connection and ldap_start_tls stats a TLS conection. It all
works well if you have a valid certificate in the store, but if not, the
connection would just be shut down with the 'server down' message without any
hint on what's going on. The complicated part is to inform the user that the
certificate cannot be trusted and to let him decide whether to accept or deny
the connection (VERIFYSERVERCERT callback function).
P.S. The XE2 apparently has a multiplatform support for windows, mac and ios -
maybe there is a chance after all, I have to investigate this possibility.
Nice from you to offer help, thank you!
i am try to connect openLdap from LdapAdmin tool, I am getting "LDAP error ! Unavailable: Proxy cannot contact remote server." I am running this on port 636. Samething is working fine for port 389. Can you please suggest me where should i change and where i am wrong.
Thanks in advance.
If possible please send detail on my mail id tothekaushal@gmail.com
It look like you are connecting to the proxy server and the the proxy server accepts ssl connections but the upstream server does not. Just a guess, however...
LDAP admin is not able to connect to a different port than 636 for SSL
I can not confirm this (I'm able to connect to different port). Can you provide more details about your setup and error?
Cheers,
Tihomir
View and moderate all "Open Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Can't connect to Ldap Server by Ldapadmin from windows7 64 bit. Ldap error: no such object.
Please help me regarding this issue.
Your LDAP database is probably empty so that would be normal. You have to have at least root dn in your database. You can create this with LDAPAdmin editor or import it from LDIF file.
Cheers,
Tihomir
Also, take a look at this thread: https://sourceforge.net/p/ldapadmin/discussion/305548/thread/278ace17/?limit=25#73d3/21f7
View and moderate all "Open Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Why not using openssl libraries binding for Pascal available for FreePascal. This would overcome the incompatibilities made by windows.
Because this library wasn't even existant at the time LdapAdmin was started and the port would be a major task. Also, beeing basicaly a Windows tool (unfortunately, due to compiler restrictions) the Windows LDAP API is a logical choice. Besides, the Windows LDAP API is there for almos 20 years now and a VITAL part of Windows OS. It is very mature, stable and reliable. If you take a look at the LDAPAdmin forums, you will see that the problems which can be traced to the Windows API are a really rare and very special (such as limited Cypher support). And, there is no library without problems. There is a port of LdapAdmin to FreePascal maintained by Ivo Brhel, you can check it here: http://ivb.sweb.cz/ldap-en.html. He's doing a great job of porting but it is a major effort and not everything is yet ported. You should check this out. I am trying to support him and I've changed some libraries already to provide a better portability support and as I wrote the 1.8 release, I was keeping the code as portable as I could. So, at some point LdapAdmin may be OS independant but it's still a long way to go.
Cheers,
Tihomir
View and moderate all "Open Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
hello, please help to check how to solve this problem, thanks.