All,
Still working with our AD team, trying to implement Microsoft's AD edict to only allow LDAP SASL bindings with a security strength factor of 2 or greater.
https://bugzilla.redhat.com/show_bug.cgi?id=1793709
So I realize (now) that sssd's default GSSAPI SASL binding does not do signing. Whereas, the GSS-SPNEGO authentication mechanism does. Both authentication mechanisms claim a SSF of 256. So both are accepted by AD DCs enforcing MS' stricter policy. (We have verified this by hard-coding sssd clients to AD DCs thus configured).
Even with the new hotfix that Microsoft released in July, the AD DCs still report event 2889 (insecure LDAP binding or unsigned LDAP binding) for GSSAPI SASL bindings. They do not report event 2889 for GSS-SPNEGO SASL bindings.
I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego.
So while we can satisfy MS' stricter requirement of SASL bindings with SSF
= 2, the AD admins will still see events 2889 in their DC logs. Certainly
for our older clients.
I don't fully understand this claim of SSF == 256 for GSSAPI.
SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality.
https://ldapwiki.com/wiki/Security%20Strength%20Factor
I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing?
Otherwise, if you can get integrity checking without signing and our GSSAPI bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted?
Just trying to gauge if it's worth the work effort to convert all our new'ish sssd client to gss-spnego, or leave them at (default) gssapi.
Spike
PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.
On Mon, Oct 12, 2020 at 11:25 AM Spike White spikewhitetx@gmail.com wrote:
I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego.
Correct.
sssd relies on the Cyrus SASL library to perform the authentication, and the RHEL6 version of Cyrus SASL only supports GSSAPI, not GSS-SPNEGO. So supporting GSS-SPNEGO on RHEL6 requires backporting code to Cyrus SASL.
Since RHEL6 has been in maintenance phase 2 support (security fixes and critical bugfixes only) for years, and since RHEL6 exits maintenance phase 2 support on 2020-11-30 (effectively making RHEL6 EOL for anyone without an ELS license), there is essentially zero chance Red Hat will backport GSS-SPNEGO support to the RHEL6 Cyrus SASL.
So while we can satisfy MS' stricter requirement of SASL bindings with SSF >= 2, the AD admins will still see events 2889 in their DC logs. Certainly for our older clients.
I don't fully understand this claim of SSF == 256 for GSSAPI.
SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality.
https://ldapwiki.com/wiki/Security%20Strength%20Factor
I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing?
I think the issue is that encrypting the communication (providing confidentiality, or “sealing” in GSSAPI parlance) is not the same thing as performing LDAP signing:
https://ldapwiki.com/wiki/LDAP%20Signing
I suspect only GSS-SPNEGO performs LDAP signing, even though GSSAPI provides both integrity checking and confidentiality.
Otherwise, if you can get integrity checking without signing and our GSSAPI bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted?
Perhaps there is a concern that replay attacks (using the encrypted payload) might be possible without LDAP signing, even if you cannot decrypt the encrypted payload?
PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.
Absolutely, yes. Even if there is some risk to using GSSAPI instead of GSS-SPNEGO (e.g., if GSSAPI is potentially vulnerable to replay attacks), that is negligible compared to the risk of clients performing LDAP binds using passwords that are sent in clear text on the wire (i.e., using LDAP instead of LDAPS).
By reporting both types of events using the same event ID, Microsoft has made it all but impossible to detect the latter types of events, based on all of the noise that the former types of events generate.
James,
Really appreciate the explanation and helpful URL. Totally agree with your statements below:
Absolutely, yes. Even if there is some risk to using GSSAPI instead of GSS-SPNEGO (e.g., if GSSAPI is potentially vulnerable to replay attacks), that is negligible compared to the risk of clients performing LDAP binds using passwords that are sent in clear text on the wire (i.e., using LDAP instead of LDAPS).
By reporting both types of events using the same event ID, Microsoft has made it all but impossible to detect the latter types of events, based on all of the noise that the former types of events generate.
I just wasn't phrasing it as clearly as you; thanks for the clear language.
Spike
On Mon, Oct 12, 2020 at 12:34 PM James Ralston ralston@pobox.com wrote:
On Mon, Oct 12, 2020 at 11:25 AM Spike White spikewhitetx@gmail.com wrote:
I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego.
Correct.
sssd relies on the Cyrus SASL library to perform the authentication, and the RHEL6 version of Cyrus SASL only supports GSSAPI, not GSS-SPNEGO. So supporting GSS-SPNEGO on RHEL6 requires backporting code to Cyrus SASL.
Since RHEL6 has been in maintenance phase 2 support (security fixes and critical bugfixes only) for years, and since RHEL6 exits maintenance phase 2 support on 2020-11-30 (effectively making RHEL6 EOL for anyone without an ELS license), there is essentially zero chance Red Hat will backport GSS-SPNEGO support to the RHEL6 Cyrus SASL.
So while we can satisfy MS' stricter requirement of SASL bindings with SSF >= 2, the AD admins will still see events 2889 in their DC logs. Certainly for our older clients.
I don't fully understand this claim of SSF == 256 for GSSAPI.
SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality.
https://ldapwiki.com/wiki/Security%20Strength%20Factor
I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing?
I think the issue is that encrypting the communication (providing confidentiality, or “sealing” in GSSAPI parlance) is not the same thing as performing LDAP signing:
https://ldapwiki.com/wiki/LDAP%20SigningI suspect only GSS-SPNEGO performs LDAP signing, even though GSSAPI provides both integrity checking and confidentiality.
Otherwise, if you can get integrity checking without signing and our GSSAPI bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted?
Perhaps there is a concern that replay attacks (using the encrypted payload) might be possible without LDAP signing, even if you cannot decrypt the encrypted payload?
PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.
Absolutely, yes. Even if there is some risk to using GSSAPI instead of GSS-SPNEGO (e.g., if GSSAPI is potentially vulnerable to replay attacks), that is negligible compared to the risk of clients performing LDAP binds using passwords that are sent in clear text on the wire (i.e., using LDAP instead of LDAPS).
By reporting both types of events using the same event ID, Microsoft has made it all but impossible to detect the latter types of events, based on all of the noise that the former types of events generate. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
On Mon, Oct 12, 2020 at 10:25:30AM -0500, Spike White wrote:
All,
Still working with our AD team, trying to implement Microsoft's AD edict to only allow LDAP SASL bindings with a security strength factor of 2 or greater.
https://bugzilla.redhat.com/show_bug.cgi?id=1793709
So I realize (now) that sssd's default GSSAPI SASL binding does not do signing. Whereas, the GSS-SPNEGO authentication mechanism does. Both authentication mechanisms claim a SSF of 256. So both are accepted by AD DCs enforcing MS' stricter policy. (We have verified this by hard-coding sssd clients to AD DCs thus configured).
Even with the new hotfix that Microsoft released in July, the AD DCs still report event 2889 (insecure LDAP binding or unsigned LDAP binding) for GSSAPI SASL bindings. They do not report event 2889 for GSS-SPNEGO SASL bindings.
Hi,
thanks for letting us know that there are still 2889 messages even with the latest hotfix. Just to be on the safe side, you are talking about https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003 where it is said "Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method."
I still think this is a false-positive message and should be fix on the Microsoft side. My reasoning is that if you enforce/require signing on the server side by setting 'LDAPServerIntegrity' to '2' the server must reject unsigned connections. Since it does not reject a GSSAPI connecting it must be valid and in agreement with the server-side security settings.
Since the 2889 message and the acceptance of the connection contradicts each other this means that either the message is a false-positive (which I believe) or an unsigned connection is accepted although the server is configured not to do so (which would be really bad since the client can claim anything and it is up to the server to properly check if all requirements are met).
bye, Sumit
I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego.
So while we can satisfy MS' stricter requirement of SASL bindings with SSF
= 2, the AD admins will still see events 2889 in their DC logs. Certainly
for our older clients.
I don't fully understand this claim of SSF == 256 for GSSAPI.
SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality.
https://ldapwiki.com/wiki/Security%20Strength%20Factor
I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing?
Otherwise, if you can get integrity checking without signing and our GSSAPI bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted?
Just trying to gauge if it's worth the work effort to convert all our new'ish sssd client to gss-spnego, or leave them at (default) gssapi.
Spike
PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
Yes, correct. So that MS hotfix:
- Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method.
is for W2019.
But with the equiv hotfix for W2016 and W2012, event 2889 triggers (in the AD DC logs) for GSSAPI-based SASL bindings. (It does not trigger for GSS-SPNEGO-based SASL bindings).
However, GSSAPI bindings are accepted when MS' ssf >= 2 recommendation is enforced. So yes, the true behavior and the reporting do not agree with each other.
Spike
On Tue, Oct 13, 2020 at 2:16 AM Sumit Bose sbose@redhat.com wrote:
On Mon, Oct 12, 2020 at 10:25:30AM -0500, Spike White wrote:
All,
Still working with our AD team, trying to implement Microsoft's AD edict
to
only allow LDAP SASL bindings with a security strength factor of 2 or greater.
https://bugzilla.redhat.com/show_bug.cgi?id=1793709
So I realize (now) that sssd's default GSSAPI SASL binding does not do signing. Whereas, the GSS-SPNEGO authentication mechanism does. Both authentication mechanisms claim a SSF of 256. So both are accepted by AD DCs enforcing MS' stricter policy. (We have verified this by hard-coding sssd clients to AD DCs thus configured).
Even with the new hotfix that Microsoft released in July, the AD DCs still report event 2889 (insecure LDAP binding or unsigned LDAP binding) for GSSAPI SASL bindings. They do not report event 2889 for GSS-SPNEGO SASL bindings.
Hi,
thanks for letting us know that there are still 2889 messages even with the latest hotfix. Just to be on the safe side, you are talking about
https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003 where it is said "Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method."
I still think this is a false-positive message and should be fix on the Microsoft side. My reasoning is that if you enforce/require signing on the server side by setting 'LDAPServerIntegrity' to '2' the server must reject unsigned connections. Since it does not reject a GSSAPI connecting it must be valid and in agreement with the server-side security settings.
Since the 2889 message and the acceptance of the connection contradicts each other this means that either the message is a false-positive (which I believe) or an unsigned connection is accepted although the server is configured not to do so (which would be really bad since the client can claim anything and it is up to the server to properly check if all requirements are met).
bye, Sumit
I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego.
So while we can satisfy MS' stricter requirement of SASL bindings with SSF
= 2, the AD admins will still see events 2889 in their DC logs.
Certainly
for our older clients.
I don't fully understand this claim of SSF == 256 for GSSAPI.
SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality.
https://ldapwiki.com/wiki/Security%20Strength%20Factor
I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing?
Otherwise, if you can get integrity checking without signing and our
GSSAPI
bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted?
Just trying to gauge if it's worth the work effort to convert all our new'ish sssd client to gss-spnego, or leave them at (default) gssapi.
Spike
PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
On Tue, Oct 13, 2020 at 5:04 PM Spike White spikewhitetx@gmail.com wrote:
Yes, correct. So that MS hotfix:
Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method.
is for W2019.
Isn't it[1] for windows 10? At first I thought it was for the server, and "blindly" downloaded it. I only realized it was for windows 10 when I tried to install it. So what are they changing on the client-side to get rid of the log on the server?
1. https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003
On Tue, Oct 13, 2020 at 05:19:31PM -0300, Andreas Hasenack wrote:
On Tue, Oct 13, 2020 at 5:04 PM Spike White spikewhitetx@gmail.com wrote:
Yes, correct. So that MS hotfix:
Addresses an issue that incorrectly reports Lightweight Directory Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method.
is for W2019.
Isn't it[1] for windows 10? At first I thought it was for the server, and "blindly" downloaded it. I only realized it was for windows 10 when I tried to install it. So what are they changing on the client-side to get rid of the log on the server?
Hi,
in the small print is says "Applies to: Windows 10, version 1809, all editions, Windows Server version 1809, Windows Server 2019, all editions".
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
Here's more details on the "event 2889" hotfix -- bindings being mis-reported as insecure bindings. For W2016. This is from our AD team:
On Windows 2016 fix, it was released in August update - https://support.microsoft.com/en-us/help/4571694 https://nam06.safelinks.protection.outlook.com/?url=https://support.microsoft.com/en-us/help/4571694&data=02%7c01%7cLuis.Barahona%40microsoft.com%7c544f7d346ef94af8317b08d86c6a48a1%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c637378551041053221&sdata=WN1tc7NYaVWkXFLsAN4HvwHsARvUiQURLCzYhGrT0rI%3D&reserved=0
This update has been replaced by the following updates:
2020-09 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4577015)
2020-10 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4580346)
In testing today, our AD team reports this:
ok, we are getting a 2889 on 2012 but not on 2016 so we will report that back
I want to see if 2016 is correctly detecting so we can have them do the same on 2012.
(Our AD DCs are a mix of W2016 and W2012).
Spike
On Wed, Oct 14, 2020 at 1:06 AM Sumit Bose sbose@redhat.com wrote:
On Tue, Oct 13, 2020 at 05:19:31PM -0300, Andreas Hasenack wrote:
On Tue, Oct 13, 2020 at 5:04 PM Spike White spikewhitetx@gmail.com
wrote:
Yes, correct. So that MS hotfix:
Addresses an issue that incorrectly reports Lightweight Directory
Access Protocol (LDAP) sessions as unsecure sessions in Event ID 2889. This occurs when the LDAP session is authenticated and sealed with a Simple Authentication and Security Layer (SASL) method.
is for W2019.
Isn't it[1] for windows 10? At first I thought it was for the server, and "blindly" downloaded it. I only realized it was for windows 10 when I tried to install it. So what are they changing on the client-side to get rid of the log on the server?
Hi,
in the small print is says "Applies to: Windows 10, version 1809, all editions, Windows Server version 1809, Windows Server 2019, all editions".
bye, Sumit
https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Andreas Hasenack -
James Ralston -
Spike White -
Sumit Bose