Wondering if Toad For Oracle is capable of connecting to an LDAP server (389 Directory) for database name lookup using the secure port (TLS 1.2).
If you are using an Oracle client and a newer version of Toad, yes this should be no problem. Toad version 16.2 and older used to throw an error if the first port left blank in the LDAP.ora file (like this:
DIRECTORY_SERVERS = (servername.eastus.cloudapp.azure.com::636)
If you are not using an Oracle client, you should be able to connect w/o any problem, assuming your Toad version supports no-client and LDAP.
Thank you for replying. I am using an oracle client to connect to the database ultimately. But when connecting to the name server (Directory 389) using the entry below TOAD just spins when starting up. Any ideas? Is that the proper syntax when using the secure port? Or should it be one colon?
DIRECTORY_SERVERS= (myhost.domain.com::636)
Also, I am using TOAD version 17.0.341
We recently fixed a bug where LDAP dropdown was loading slowly if the LDAP server contained lots (hundreds) of database entries. Could that be the case here?
That was fixed in a recent beta. One workaround was to uncheck the "Connect using Oracle client" checkbox on the login window before attempting to make the connection.
Note, this box is only enabled when Toad does not have any active connections to the database.
I don't think this is the case in my scenario. The only way I get any response from TOAD is if I list port 389 in the DIRECTORY_NAMES parameter in the LDAP.ORA....Is there some configuration I need to do on the TOAD side to tell it to use TLS 1.2?
There is not.
For what it's worth, the only thing Toad uses LDAP for is to populate the dropdown in the login window. The actual connection is made by the Oracle client, and we don't have to tell it to use LDAP or TNSNames - Oracle client figures that out on its own.
To load the dropdown, we are using the oracle client DLLs, using the LDAP_OPEN command. If that is successful, then we call LDAP_SIMPLE_BIND_S, then LDAP_SEARCH to get the list of items in the dropdown.
Some things to check:
- Can you connect using SQL*Plus on the same Oracle client?
- What about if you connect in Toad with "Connect using Oracle client" unchecked?
Maybe LDAP_OPEN does not support TLS 1.2? I am trying to figure that out from the oracle docs
Oh, and I forgot to mention. You can right-click here and choose "Test LDAP". This will cause Toad to try to connect to LDAP and give you a log when it is done so you can see how far it got
For me, the output looks like:
I understand TOAD only connects to LDAP for a listing. But it appears that this connection is where the issue is. And yes, the question ultimately is if TLS 1.2 is supported. I can connect using port 636 with other tools such as APACHE Directory studio. But TOAD seems to be theproblem child right now.
I will check this out and see what it tells us
This is successful when port 389 is used in the directory_servers parameter.
As soon as I use port 636 (secure port) I cannot even get the connect window to come up since it appears it cannot connect to LDAP over secure port.
Can we log this as an enhancement request or bug with Quest?
Yes you can log it as an ER or bug (doesn't matter to me which one, the work is the same). Please go through support for that though. This ToadWorld forum for casual communication.
Absolutely I will log it via support. Thank you for helping to research this issue with me.
1 Like
The next beta (to be released Monday 29-Apr-2024) will support secure LDAP connection port 636 when Toad is not using an Oracle client. This will be in Toad 17.1.
If you are using an Oracle client:
- Maybe it will work. Toad will attempt to use the secure port if it's configured. But at this time I don't even have TNSPing working with the secure port, so it seems that there is some Oracle client configuration that I am missing (maybe like creating a wallet and exchanging it with the server?). I will look at that more next week, but If I need to make further code changes for Toad to use the secure port when an Oracle client is in use, that will probably have to wait until the next version because we are getting close to the release date for 17.1.