Description of problem:
LDAP protocol can be encrypted and protected in multiple ways:

1) LDAP + StartTLS
2) LDAPS (LDAP over TLS on port 636/TCP)
3) LDAP with SASL/GSSAPI with data integrity and data confidentiality layer
4) LDAPI (IPC over Unix socket)

With (1) and (2) the server is authenticated with PKI (X.509 cert) and connection is encrypted and protected with TLS. In case (3) the connection is encrypted and secured with GSSAPI. LDAP client and server libraries install a SASL data security layer at the end of the SASL bind operation, which uses GSSAPI to perform encryption and data integrity checks.

389-DS and OpenLDAP client don't take the outer TLS layer into account when they negotiate and establish the SASL layer. This results in double encryption with TLS as outer layer and SASL/GSSAPI as inner encryption layer. In majority of cases double encryption is an unnecessary overhead, impacts performance and is therefore not wanted.

It is possible to avoid double encryption by setting the minimum and maximum SASL security strength factor (SSF) to 0 on the client side. The trick does not work reliable, e.g. it conflicts with cn=config nsslapd-minssf option.

Version-Release number of selected component (if applicable):
389-ds-base-2.0.8 (also applies to DS base 1.4)
openldap-2.4.57

How reproducible:
Always

Steps to Reproduce:
1. install IPA server
2. ldapwhoami -H ldaps://$(hostname) -Y GSSAPI

Actual results:
SASL/GSSAPI authentication started
SASL username: admin
SASL SSF: 256
SASL data security layer installed.
dn: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test

Expected results:
libldap and 389-DS should not install a SASL data security layer over TLS unless a clients explicitly asks for minimum SSF > 0.

Additional info:
FreeIPA upstream ticket https://pagure.io/freeipa/issue/8970 contains more information.

OpenLDAP has default SSF_MIN=0, SSF_MAX=0x7fffffff.