Ok, I think this reply from upstream summarizes it quite well:
https://<email address hidden>/msg07415.html
"""
Hi,
this was already discussed here on the list. To summarize:
SASL:
- no changes are needed for the default AD provider configuration with
SASL/GSSAPI, there are event log messages saying that signing is
missing on the connection but everything is still working even when
signing is enforced, so imo the event log messages can be ignored
- you can prevent the event log message by switching to GSS-SPNEGO with
the help of the 'ldap_sasl_mech' option, see man sssd-ldap for details
- we plan to change the default from GSSAPI to GSS-SPNEGO in one of the
next release
LDAPS:
- afaik there is no document from Microsoft saying that the default LDAP
port 389 will be disabled or should not be used anymore as long as
LDAP signing is used, so in general there is no need to switch to
LDAPS
- if you have a manual configuration with LDAPS using a simple bind,
i.e. Bind DN and password to my knowledge no changes are needed
- if you use a manual configuration with LDAPS and SASL bind you have to
wait for some fixes related to channel binding in OpenLDAP
Ok, I think this reply from upstream summarizes it quite well: /msg07415. html
https://<email address hidden>
"""
Hi,
this was already discussed here on the list. To summarize:
SASL:
- no changes are needed for the default AD provider configuration with
SASL/GSSAPI, there are event log messages saying that signing is
missing on the connection but everything is still working even when
signing is enforced, so imo the event log messages can be ignored
- you can prevent the event log message by switching to GSS-SPNEGO with
the help of the 'ldap_sasl_mech' option, see man sssd-ldap for details
- we plan to change the default from GSSAPI to GSS-SPNEGO in one of the
next release
LDAPS:
- afaik there is no document from Microsoft saying that the default LDAP
port 389 will be disabled or should not be used anymore as long as
LDAP signing is used, so in general there is no need to switch to
LDAPS
- if you have a manual configuration with LDAPS using a simple bind,
i.e. Bind DN and password to my knowledge no changes are needed
- if you use a manual configuration with LDAPS and SASL bind you have to
wait for some fixes related to channel binding in OpenLDAP
https:/ /git.openldap. org/openldap/ openldap/ -/merge_ requests/ 26
and CyrusSASL
https:/ /github. com/cyrusimap/ cyrus-sasl/ pull/601 (already merged
upstream)
with those fixes LDAPS with SASL should work with enforced channel
binding as well.
"""