Hi, A Windows 2012 R2 server running Exchange 2013 started logging Schannel errors, which according to this post (http://blog.ittoby.com/2014/07/why-schannel-eventid-36888-36874-occurs.html) is a result of the cipher mismatch.
I am seeing RST packets in the LDAP communication between the exchange server and the domain controller, where RST is sent by the DC to Exchange. Not sure if I grabbed the correct stream, but the time of the Windows Event with the schannel error matches the time stamp of the RST packet. Should LDAP communication end with an RST packet? Thanks asked 23 Jun '16, 14:02  net_tech edited 23 Jun '16, 14:56 |
One Answer:
Any application using TCP as transport may terminate the TCP session using RST to distinguish a "peaceful" termination from an emergency one. But your screenshot doesn't indicate any cipher issue, as a cipher negotiation has to be successfully completed before the ciphered communication may start. In your case, LDAP exchange was already in progress and the RST came in response to LDAP So I'd suspect something else to be broken, either at the DC side or with the contents of the answered 24 Jun '16, 02:14  sindy showing 5 of 7 show 2 more comments |
Thanks sindy.
I am wondering now if there is an issue at all? unbindRequest is a signlal to the directory server from exchange server that it is about to close its connection. DC sends an RST and the connection is peacefully closed.
I don't know whether there is an issue from user point of view. From protocol point of view, there definitely is: if the contents of the LDAP
unbindRequestwas OK, the DC should have responded it with a proper LDAP response, and then maybe terminate the TCP session using FIN, but surely not using RST. As said, RST is reserved for emergency termination of a session.There may also be an issue at client side at TCP level, but as also already said, this can be found from capture file but not from a screenshot.
Users are not reporting any issues that are related to Schannel errors. What packet would be of interest to you? Not sure I could post the entire stream without revealing too much of corporate information.
here is the last 4 packets
https://www.cloudshark.org/captures/2ffe4ec37b5a
I was suspecting that the reason for RST could have been that the TCP window size announced in the packet carrying the
unbindRequestwas zero so the answer would not fit, but your capture shows it is not the case.As the LDAP payload cannot be decrypted from this 4-packet capture, can you add to the Question (as pictures in comments destroy page layout) a screenshot of the fully expanded dissection of the LDAP part of the
unbindRequestpacket (the one right before the RST)?Sure
OK, I give up. There are no parameters to
unbindRequestand Wireshark doesn't claim any error of SASL. So nothing at TCP or LAPD level suggests why the server should send a TCP RST rather than a regular response to theunbindRequest.