On 4/9/20 9:10 AM, Sumit Bose wrote:
On Thu, Apr 09, 2020 at 02:53:42PM -0000, Todd Grayson wrote:
> Hello,
>
> I see there are more specific threads discussing the upcoming changes to Active
Directory[1] (patch tuesday update this fall) for LDAP signing[2] and LDAP enforce side
channel binding[3] that is coming?
>
> Is there an active working group in the SSSD team evaluating this change and its
impact in general? For the AD form of SSSD integration, is there an indication of what
the impact there is for these changes, for SASL based authentication configurations? Or
the impact to startTLS based configuration?
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
Maybe everyone doesn't realize that LDAP using STARTTLS on port 389
provides the same encryption and authentication as LDAPS (on 636 or any
other port). For a modern OS, they both establish the same TLS 1.2
encryption protocol. So there is no advantage of using LDAPS except that
if you look at the wire data sent during negotiation, each STARTTLS
session uses like 2 or 3 more packets to establish (typically taking on
the order of less than a millisecond). If someone disagrees with this,
please say it. I have an open mind.
CP - Christopher Paul
--
Rex Consulting -
https://www.rexconsulting.net