This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Schannel errors EventID 36888

0

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.

alt text

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's gravatar image

net_tech
116303337
accept rate: 13%

edited 23 Jun '16, 14:56


One Answer:

0

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 unbindRequest, so the cipher negotiation phase has either completed successfully or no ciphering is used.

So I'd suspect something else to be broken, either at the DC side or with the contents of the unbindRequest sent by the Exchange. As you have provided a screenshot rather than a capture file (which has to be uploaded to Cloudshark or any file sharing service and a link for login-free access to it has to be placed here if you want to share it), there is little more anyone here could tell until you post the capture.

answered 24 Jun '16, 02:14

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

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.

(24 Jun '16, 06:12) net_tech

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 unbindRequest was 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.

(24 Jun '16, 14:16) sindy

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.

(24 Jun '16, 14:34) sindy

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

(28 Jun '16, 10:56) net_tech

I was suspecting that the reason for RST could have been that the TCP window size announced in the packet carrying the unbindRequest was 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 unbindRequest packet (the one right before the RST)?

(29 Jun '16, 03:35) sindy

Sure

alt text

(29 Jun '16, 12:48) net_tech

OK, I give up. There are no parameters to unbindRequest and 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 the unbindRequest.

(29 Jun '16, 13:57) sindy
showing 5 of 7 show 2 more comments