Cloud based application having issues with ldaps bind

curious7 used Ask the Experts™
Cloud based application having issues with ldaps bind to our Domain Controller in DMZ.
The application vendor is seeing the follwoing log entries on their side:
           [7:Public User][1024:application notice][R] (:) - Unable to bind to the LDAP server.

Based on this they have taken a wireshark capture and seen the following sequence of packets:-
Source -> destination (DC)   TCP    49662->636 [ACK] Seq=805 Ack=12910
Source -> destination (DC)   TLSv1  Application data
Source -> destination (DC)   TLSv1  Encrypted Alert
Source -> destination (DC)   TCP    49662->636 [FIN, ACK] Seq=927 Ack=12910
destination (DC) -> Source   TCP    636->49662 [ACK] Seq=12910 Ack=928
destination (DC) -> Source   TCP    636->49662 [RST,ACK] Seq=12910 Ack=928

They are saying that the reason packet analyser highlights the [RST, ACT] packets in red is because after the connection closure by Cloud Application server (source) [FIN, ACK] , server is expecting a final [FIN, ACK] from Domain Controller  (destination) but [RST, ACK] arrives instead. And thus they believe that it could be a issue with the Domain Controller.

Is this claim correct?
What can we do to troubleshoot this further?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I would suggest using the softerra LDAP browser locally to see if you can connect over LDAPS, and then try over the firewall.

Could  your firewall be interfering with the  LDAPS traffic ?
mccarlIT Business Systems Analyst / Software Developer
Top Expert 2015

Whilst it is probably not "nice" of the DC to send the RST, it shouldn't have affected the application, as it had already sent the FIN so it shouldn't care. (Also, there may be more to this that we are not seeing, due to the simple text version of the capture that you have given to us)

Anyway, my assumption is that the "unable to bind" is due to some other reason that you need to look into. This particular issue with the packet capture may be leading you down the wrong path.
jrhelgesonSolutions Architect

RST is usually sent by a device like a firewall to prevent information leakage. The purpose is to kill the connection, not close it gracefully.  I would do a packet capture on the DC to see what you're actually sending.

Is the windows firewall or host based anti-virus interfering with the query?  It could be getting flagged as an information leak.

I agree with ArneLovius suggestion of using an LDAP browser such as LDP or the Softerra option.  If you are not specifying the proper search path, or have DN= where it should be DC= in your search path, it could also fail to return a valid result and hard fail you.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial