Exchange 2013 / Exchange 2010, Windows Server 2012 – SChannel Event ID:36888 (1203) – TLS/SSL error – The root cause


I have problems in some environments, where these SChannel errors are generated. Well. It took me several days to find reasonable “why” it is logged.

Problem:

The event ID from the picture can be seen from time to time:

EventID-Error

Solution:

Based on several articles I have read and some discussions. First you have to make sure, that the process causing this error is LSASS.exe, which is by the way local security authentication server (authenticating users to winlogon service, using authentication such as msgina.dll and so on). To make sure it is LSASS.EXE. Open Event ID and check the Event ID details, Click on Details tab -> Expand System while friendly view is selected. Check Process ID.

EventID_Details

Then use powershell and run:

Get-Process | select name,id | sort id

Result should give you the name of the processes. It will be lsass.exe.

Why:

Reason is simple. Not standard or corrupted behavior of web browsers or users. The problem behind SChannel and Exchange 2012 is, that sometimes users use HTTP protocol, but on port 443, which expects certificates exchange rather than GET command.

How to test:

Option 1#:

Test is easy. For example you can input URL to your browser address bar, which is obviously wrong and see the results: HTTP://MAIL.DOMAIN.LOCAL:443/OWA – It says to use HTTP protocol (not HTTPS) on the 443 port and it generates errors immediately.

Option 2#:

Run Telnet and test command:

Telnet localhost 443 (to connect to HTTPS)

In Telnet window:

Get /index.htm (on HTTPS SSL must be established first so it will generate errors immediately. Result will not be seen in telnet window)

What is the solution?

Solution #1:

Some IT guys recommend to disable SCHannel logging to get rid of these events, but I cannot recommend that. To be honest. It is better to see, that somebody is trying to connect using HTTP on HTTPS port, because this might be some attempt to DoS attack or info, that users don´t know how to type OWA URL correctly. Shortly it is better to know something is wrong than disable logging.

Solution #2:

I suspect wrong redirect configuration for the websites from HTTP to HTTPS. I would check IIS if redirect is set correctly. For those having this issue without redirect I would suspect problem in web browser area.

Links:

To test SSL via command line:

http://www.bearfruit.org/2008/04/17/telnet-for-testing-ssl-https-websites/

LSASS description:

http://www.neuber.com/taskmanager/process/lsass.exe.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s