Just check the box and see what happens.

I enabled ldaps in /etc/default/slapd from client host when I run TLS (-Z -H ldap://) it starts TLS on port 389 ldapsearch -x -w pass -Z -H ldap://dc.net123.int -D cn=Manager,dc=net123,dc=int '(cn=autoconfig)' STARTTLS (IP=0.0.0.0:389)

when I run SSL (-H ldaps://) it starts SSL on port 636 ldapsearch -x -w pass -H ldaps://dc.net123.int -D cn=Manager,dc=net123,dc=int '(cn=autoconfig)' (IP=0.0.0.0:636)

And when SSL is enabled in TB it goes to 636 port with failing (IP=0.0.0.0:636) (TLS negotiation failure)

So first question what's wrong with TB and how to tweak it to use system settings like ldapsearch does? May be some libs in TB should be replaced by system ones? The second, how to enable STARTTLS?

I cannot answer this question. If you're still running TB68, you may want to give TB78 a try. https://www.thunderbird.net/

If v78 doesn't work either, I'd suggest to raise a bug in Bugzilla. https://bugzilla.mozilla.org/

If you do this, you may want to post the bug ID here.

Previous situation changed a little

And when SSL is enabled in TB it goes to 636 port with failing (IP=0.0.0.0:636) (TLS negotiation failure)

The problem as found out was with server's certificate with included ip_address in it. TB does not resolve names if 'X509v3 Subject Alternative Name: IP Address:' is set. TB does not trust such certificate even when CA trust is enabled. It does not warn only if IP is set in smtp\imap fields. And vice versa, if certificate does not have ip_address TB trusts only to names, but not to IPs.

So, decision was to change ldaps address book to IP and for postfix\dovecot to remake certificates without ip_address and put names. 'ldapsearch ldaps' replies back from client's host with server's IP and name. It seems like another one TB bug.