none
SChannel Event ID 36888 RRS feed

  • Question

  • Hi! I'm getting this error regularly on a domain controller:

    The following fatal alert was generated: 20. The internal error state is 960. (SChannel Event ID 36888)

    All threads I've found refer to an invalid certificate on IIS. However, for me this occurs on a domain controller where IIS is not installed. So, Google hasn't been too helpful.

    Any suggestions what could cause this? AD DS, DNS and File Services (namespace + DFSR) are installed on the machine.

    Sunday, September 11, 2016 3:26 PM

Answers

  • What FQDN is the LDAP client pointing to?  If you've placed Subject Alternative Name of the AD domain name into the certificate, which is common practice, and works for most software, it will not work at all with PHP unless you are running PHP 5.6 or above.  In general, PHP handles SSL/TLS poorly, and by extension, will handle LDAPS poorly as well.  I small network will mask problems, but I think they will present their ugly head when one or the other ends of the transaction are under load.

    Best Regards, Todd Heron | Active Directory Consultant

    • Proposed as answer by AlvwanModerator Monday, September 19, 2016 2:14 AM
    • Marked as answer by Aleksiv95 Monday, September 19, 2016 4:10 PM
    Sunday, September 18, 2016 8:18 PM
  • Hi, I think I got this resolved. I transferred the site from a PHP 5.5 web server to a PHP 7 one and I haven't seen the SChannel events or related errors in the PHP log since. I also changed the LDAP address from ldap://domain.company.com to ldap://some-specific-dc.domain.company.com but I think that is irrelevant. So you were right about PHP, I'm still scratching my head wondering what caused these issues to start after many years with not a single problem. Well, it works now, that's the important part. Now I'll start working on the 700 compatibility issues with PHP 7 ;) Thank you for your help!

    EDIT: Oh, I forgot to mention. Wireshark revealed that the PHP occasionally sent a RESET packet after encrypted handshake message from the DC, so this also suggests that the LDAP implementation in PHP is the culprit.
    • Edited by Aleksiv95 Monday, September 19, 2016 4:15 PM added the note about wireshark
    • Proposed as answer by Todd Heron Monday, September 19, 2016 9:45 PM
    • Marked as answer by Aleksiv95 Tuesday, September 20, 2016 3:31 AM
    Monday, September 19, 2016 4:10 PM

All replies

  • I have seen this before on DCs without IIS but am not sure what causes it.  I have some theories.  Perhaps a non-Microsoft based LDAP application connecting to AD over LDAPS (TCP port 636) - which is also a secure channel and the software has known issues with newer (or older) ciphers.  This is just a theory.  You'll have to think of what kind of applications are connecting to your AD domain controllers.  Please reply if you find a resolution.

    Best Regards, Todd Heron | Active Directory Consultant


    • Edited by Todd Heron Sunday, September 11, 2016 8:38 PM Corrected typo in port number
    Sunday, September 11, 2016 8:37 PM
  • Hi! That's a great theory - I noticed that every time I get the SChannel error, my PHP application (that binds to this very DC) logs the following:

    PHP Warning:  ldap_start_tls(): Unable to start TLS: Connect error

    Both problems started around the same time but for some reason I haven't been able to figure out they're related. Okay, so, the PHP app is using LDAP version 3 and is able to start TLS and bind normally 95% of the time. Now this 5% needs to be resolved.

    These problems started around the same time that I removed a domain controller from a remote AD Site, but I find it really hard to believe that could be the cause. The removed DC didn't have any master roles and the remote site still has another DC. All referrals to the removed DC have been removed in the environment and the PHP app has bound to the local (not remote) DC since always. I cannot recall any other changes in the environment.

    Do you happen to have more good theories? :)

    Monday, September 12, 2016 8:50 AM
  • As your PHP application runs LDAP version 3 and AD also runs LDAP version 3, I think this error could be generated by something other than a software problem as the 95% / 5% ratio makes me think some sort of capacity problem is the cause.  The encrypted TCP stream may be getting overly chopped up (corrupt packets) causing the AD DC to throw the SCHANNEL error.  This is purely speculative. Perhaps either a NIC-driver issue on the AD domain controller or on your application server - or some combination of both, or network congestion causing this.  Make sure both servers are running at equivalent network port speeds and are not CPU-overloaded.

    EDIT: I thought more about this.  Since I think we have it narrowed down to the non-Microsoft application (PHP) causing this.  During the SPENGO process, two computers try to figure out which authentication protocol the opposite endpoint accepts. Also part of this, the highest common denominator encryption ciphers are also chosen.  I found an article which reserves harsh treatment about the way PHP handles encryption.  Give this a read, and you may well come away with the understanding that it is the PHP encryption implementation which is causing the problem and not the AD DC, which was my takeaway. Don't know if it will help, but there are some examples given in the article to make it work better:

    Insufficient Transport Layer Security (HTTPS, TLS and SSL)


    Best Regards, Todd Heron | Active Directory Consultant


    • Edited by Todd Heron Tuesday, September 13, 2016 5:48 AM
    Tuesday, September 13, 2016 3:21 AM
  • Hi and thank you for the link! I will take that into consideration, although I doubt it could be PHP since the AD module has been untouched for years and last month was the first time I encounter this error.

    This is a very small office and network congestion cannot be the cause. The DC and application server are connected via a gigabit link with two switches in between. At this point a failing switch or a buggy network driver (as you suggested) seem the most likely reasons. I'll need to give Wireshark a go and see what's going on in there.

    Wednesday, September 14, 2016 8:20 AM
  • What FQDN is the LDAP client pointing to?  If you've placed Subject Alternative Name of the AD domain name into the certificate, which is common practice, and works for most software, it will not work at all with PHP unless you are running PHP 5.6 or above.  In general, PHP handles SSL/TLS poorly, and by extension, will handle LDAPS poorly as well.  I small network will mask problems, but I think they will present their ugly head when one or the other ends of the transaction are under load.

    Best Regards, Todd Heron | Active Directory Consultant

    • Proposed as answer by AlvwanModerator Monday, September 19, 2016 2:14 AM
    • Marked as answer by Aleksiv95 Monday, September 19, 2016 4:10 PM
    Sunday, September 18, 2016 8:18 PM
  • Hi, I think I got this resolved. I transferred the site from a PHP 5.5 web server to a PHP 7 one and I haven't seen the SChannel events or related errors in the PHP log since. I also changed the LDAP address from ldap://domain.company.com to ldap://some-specific-dc.domain.company.com but I think that is irrelevant. So you were right about PHP, I'm still scratching my head wondering what caused these issues to start after many years with not a single problem. Well, it works now, that's the important part. Now I'll start working on the 700 compatibility issues with PHP 7 ;) Thank you for your help!

    EDIT: Oh, I forgot to mention. Wireshark revealed that the PHP occasionally sent a RESET packet after encrypted handshake message from the DC, so this also suggests that the LDAP implementation in PHP is the culprit.
    • Edited by Aleksiv95 Monday, September 19, 2016 4:15 PM added the note about wireshark
    • Proposed as answer by Todd Heron Monday, September 19, 2016 9:45 PM
    • Marked as answer by Aleksiv95 Tuesday, September 20, 2016 3:31 AM
    Monday, September 19, 2016 4:10 PM