If LDAPS is unsupported, the following error [Errno 104] Connection reset by peer may sometimes appear:
Note that the username/password were in fact correct. The reason we are getting incorrect credentials is because the TCP/636/LDAPS service was not available. We confirmed this through an OpenSSL command failing to retrieve the public certificate:
This image shows the port was open via CONNECTED, but no LDAPS was available as a certificate would appear. A similar command worked with port TCP/3389/RDP which uses TLS.
We should add a catch when the LDAPS port was closed OR the LDAPS service was inaccessible on an open port. This should be output (stdout/file) to the user as well. Not sure how this tool works with STARTTLS over TCP/389. If it does use this secure LDAP method also, we would need a similar exception process there if it differs.
If LDAPS is unsupported, the following error
[Errno 104] Connection reset by peermay sometimes appear:Note that the username/password were in fact correct. The reason we are getting incorrect credentials is because the TCP/636/LDAPS service was not available. We confirmed this through an OpenSSL command failing to retrieve the public certificate:
This image shows the port was open via
CONNECTED, but no LDAPS was available as a certificate would appear. A similar command worked with port TCP/3389/RDP which uses TLS.We should add a catch when the LDAPS port was closed OR the LDAPS service was inaccessible on an open port. This should be output (stdout/file) to the user as well. Not sure how this tool works with STARTTLS over TCP/389. If it does use this secure LDAP method also, we would need a similar exception process there if it differs.