SSSD and the forthcoming Active Directory LDAPocalypse

[Todd Grayson]

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?

Are there already updates to SSSD planned/coming/released that are addressing these
changes?


[1] The article describing the delay in rollout of these upcoming AD LDAP support changes
due to CVE-2017-8563, impacting startTLS, as well as SASL based authentication.
https://redmondmag.com/articles/2020/02/04/microsoft-delaying-ldap-config...

[2] Manual LDAP Signing config article for legacy 2008 AD AD 
https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signin...

[3] Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over
SSL/TLS more secure
https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenfor...

More Infrormation:

Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
KB: https://support.microsoft.com/help/4520412
FAQ:
https://support.microsoft.com/en-us/help/4546509/frequently-asked-questio...

[Sumit Bose]

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
- 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.

HTH

bye,
Sumit

>  
>  Are there already updates to SSSD planned/coming/released that are addressing these
> changes?
>  
>  
>  [1] The article describing the delay in rollout of these upcoming AD LDAP support changes
> due to CVE-2017-8563, impacting startTLS, as well as SASL based authentication.
>
> https://redmondmag.com/articles/2020/02/04/microsoft-delaying-ldap-config...
>  
>  [2] Manual LDAP Signing config article for legacy 2008 AD AD 
>
> https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signin...
>  
>  [3] Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over
> SSL/TLS more secure
>
> https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenfor...
>  
>  More Infrormation:
>  
>  Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
>  KB: https://support.microsoft.com/help/4520412
>  FAQ:
> https://support.microsoft.com/en-us/help/4546509/frequently-asked-questio...
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Christopher Paul]

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

[Sumit Bose]

On Thu, Apr 09, 2020 at 09:21:15AM -0700, Christopher Paul wrote:
>  
>  
>  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. 
Hi,

in general you are right and SSSD's 'ldap' provider is using StartTLS.
However so far I haven't seen any document from Microsoft if StartTLS
can be used if LDAP signing is enforced since the initial connection is
unencrypted.

bye,
Sumit

>  
>  CP - Christopher Paul
>  --
>  Rex Consulting - https://www.rexconsulting.net
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Mote, Todd]

I would also mention that adcli, which does have a patch to add spnego in recent commits,
is not widely distributed yet, so still uses gssapi, and will trigger the event log.  Of
course spnego is available on RHEL 7 and 8, but not on 6.  So any 6 clients you have will
trigger the event log regardless.  Ldaps is harder to deploy to use due to the certificate
requiremrnt.  Sssd with an updated adcli using spnego will be fully compliant and not
trigger event log entries.  Hopefully MS lines up anything they may do with the expiration
of RHEL 6, which is also this fall.

Todd

-----Original Message-----
From: Sumit Bose <sbose(a)redhat.com&gt; 
Sent: Thursday, April 9, 2020 11:51 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: SSSD and the forthcoming Active Directory LDAPocalypse

On Thu, Apr 09, 2020 at 09:21:15AM -0700, Christopher Paul wrote:
>  
>  
>  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.
>  
Hi,

in general you are right and SSSD's 'ldap' provider is using StartTLS.
However so far I haven't seen any document from Microsoft if StartTLS can be used if
LDAP signing is enforced since the initial connection is unencrypted.

bye,
Sumit

>  
>  CP - Christopher Paul
>  --
>  Rex Consulting - 
>  https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>  rexconsulting.net%2F&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Ccb
>  8d4f661aa2434b5f7008d7dca64172%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%
>  7C0%7C637220478935500916&amp;sdata=n20mAo7E1TCYhVMpwX6CtWkjCUNvf8YZwjq
>  bY8168IA%3D&amp;reserved=0 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: 
>  https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
>  .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=02%
>  7C01%7Cmoter%40austin.utexas.edu%7Ccb8d4f661aa2434b5f7008d7dca64172%7C
>  31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637220478935500916&amp;sdat
>  a=uhDRSfLjZ1jUActH3NMt%2FFZTZ6pmr4fdjN4hklfDw6Q%3D&amp;reserved=0
>  List Guidelines: 
>  https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
>  raproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=02%7C01%7Cmote
>  r%40austin.utexas.edu%7Ccb8d4f661aa2434b5f7008d7dca64172%7C31d7e2a5bdd
>  8414e9e97bea998ebdfe1%7C1%7C0%7C637220478935500916&amp;sdata=ibochh3u0
>  pckDAJL3IeqfoKHRGKhY2mydmuiaerUV9A%3D&amp;reserved=0
>  List Archives: 
>  https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>  s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
>  .org&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Ccb8d4f661aa2434b5f
>  7008d7dca64172%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6372204789
>  35500916&amp;sdata=al30kwaN4KxXDwavWHYbCtQjw9Jd421Q7%2B8GDrWdoIA%3D&am
>  p;reserved=0
>  
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
List Guidelines:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
List Archives:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> > This message is from an external sender. Learn more about why
> this <<
> > matters at https://links.utexas.edu/rtyclf.                        <<
>

[Todd Grayson]

Good to see on SASL, we are seeing some issues, I'll verify whats going wrong there
and comment further.

With LDAP, simple binds over LDAP (389) will no longer be supported 

https://support.microsoft.com/en-us/help/4546509/frequently-asked-questio...
>> What issues do you foresee with enforcing LDAP signing?
>>> LDAP Simple Binds over non-TLS connections will not work if LDAP signing is
required.