Cloud based application having issues with ldaps bind

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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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 DeveloperCommented:
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.
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.