skbarnard
asked on
Can't connect to LDAP over SSL (port 636)
I have an application where I run an 'environment check'. When it goes through its server check (mostly DNS forest), on some of the servers I receive the following error:
ERROR: javax.naming.Communication Exception: simple bind failed: 10.X.X.200:636 [Root exception is java.net.SocketException: Connection reset]
I am also using LDP.EXE which allows me to check the connection or binding to a server using port 636 (LDAP over SSL) or the standard LDAP port 389. The connection fails every time when trying to establish the connection on port 636 but WILL work every time when using the standard 389 port.
The servers in question are newly added domain controllers running Server 2012 R2 but 98% of our domain controllers are at that OS level so that's what adds to my confusion -- why can't we connect via port 636 on these newly added servers? The new servers are an HP Proliant DL60 Gen9 server (if that's necessary information)
We do have an internal CA server which I know is set up properly - has been for years - and is currently up to date and functional. In fact, the application I'm running the environment check through is already pointing to that server for authentication etc.
Any help, as always, is greatly appreciated.
ERROR: javax.naming.Communication
I am also using LDP.EXE which allows me to check the connection or binding to a server using port 636 (LDAP over SSL) or the standard LDAP port 389. The connection fails every time when trying to establish the connection on port 636 but WILL work every time when using the standard 389 port.
The servers in question are newly added domain controllers running Server 2012 R2 but 98% of our domain controllers are at that OS level so that's what adds to my confusion -- why can't we connect via port 636 on these newly added servers? The new servers are an HP Proliant DL60 Gen9 server (if that's necessary information)
We do have an internal CA server which I know is set up properly - has been for years - and is currently up to date and functional. In fact, the application I'm running the environment check through is already pointing to that server for authentication etc.
Any help, as always, is greatly appreciated.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
LDP isn't the type of application that will use a port other than what you specify. If you really want to verify, then run a network capture during a connection and you will see where the traffic is directed.
For LDAPS, I'm pretty certain that you have to use the name. Just like HTTPS, the destination name has to match what's in the certificate. Unless your certificate included the IP address, I wouldn't expect it to work.
For LDAPS, I'm pretty certain that you have to use the name. Just like HTTPS, the destination name has to match what's in the certificate. Unless your certificate included the IP address, I wouldn't expect it to work.
ASKER
We're still investigating this - turns out it could be the DNS replication between the parent and child domain; we've made a couple of tweaks this morning and we're monitoring the replication.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is a certificate authority server error, relating to DNS issues
ASKER
When using LDP.exe, I'm connecting using the IP and port 636 and SSL is checked (enabled); I get the error with these options.
I've tried LDP.exe using the DC name, still port 636 and SSL checked and it connects. I don't see any indication whether it truly connected on port 636 or defaulted to port 389. Do you know of any way for me to check that?