12:46 p.m.
All,
I apologize if this has been covered already. But this was just brought up
by our cybersecurity team. They plan to disable "deprecated protocols".
By that, they mean simple LDAP binding to AD's LDAP port. Because of
passing content in clear text.
They flagged our Linux AD connections (using sssd), which are using SASL
binding. The usual sssd stuff:
- adcli join,
- /etc/krb5.keytab file,
- ldap_sasl_authid = <machine account>
to AD's LDAP port and the LDAP GC port.
Flagging those connections is a mistake; these connections are encrypted.
https://www.pkisolutions.com/reminder-ldap-signing-requirements-in-march-...
But cybersecurity is asking -- are the question "are these connections
signed?". I don't know the answer to that. If not, is there a simple
parameter that will allow sssd to sign these connections. Or is "signing"
a SASL binding a characteristic of the MS-Specific SASL binding (MS-SPNG)?
BTW, we use a couple of AD integration clients for Linux. sssd can satisfy
95% of the use cases, but there's a couple of use cases that sssd can't
do. For that, we have to use the older (commercial) product. That older
commercial product does *not* have any support to run SASL binding over
LDAPS.
So why I realize that I could technically have sssd run its SASL bindings
over LDAPS -- that other client can't. So I'm not really investigating
SASL bindings over LDAPS.
Spike
2:01 p.m.
On Wed, Sep 2, 2020 at 1:46 PM Spike White <spikewhitetx(a)gmail.com> wrote:
I apologize if this has been covered already. But this was just
brought up by our cybersecurity team. They plan to disable
"deprecated protocols". By that, they mean simple LDAP binding to
AD's LDAP port. Because of passing content in clear text.
This was covered already, yes. Here’s a summary:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
For the full discussion, search the list archives for these threads:
Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
Subject: [SSSD-users] SSSD and the forthcoming Active Directory LDAPocalypse
But cybersecurity is asking -- are the question "are these
connections signed?". I don't know the answer to that.
They are signed, yes, despite the warning that is logged on the DC.
You can verify this with a packet trace. See:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Using GSS-SPNEGO instead of GSSAPI will silence the warning, but older
systems (e.g. RHEL6) don’t have GSS-SPNEGO.
2:17 p.m.
Thank you.
What cybersecurity is reporting off of is a particular event number on its
AD controllers. which is showing a connection to a LDAP port.
Is there another (better) event that it should be looking for instead?
I.e., it should be flagging a simple binding only to an LDAP port.
We have a MS consultant, but they're not sssd-knowledgeable.
Spike
On Wed, Sep 2, 2020 at 2:02 PM James Ralston <ralston(a)pobox.com> wrote:
On Wed, Sep 2, 2020 at 1:46 PM Spike White
<spikewhitetx(a)gmail.com> wrote:
> I apologize if this has been covered already. But this was just
> brought up by our cybersecurity team. They plan to disable
> "deprecated protocols". By that, they mean simple LDAP binding to
> AD's LDAP port. Because of passing content in clear text.
This was covered already, yes. Here’s a summary:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
For the full discussion, search the list archives for these threads:
Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
Subject: [SSSD-users] SSSD and the forthcoming Active Directory
LDAPocalypse
> But cybersecurity is asking -- are the question "are these
> connections signed?". I don't know the answer to that.
They are signed, yes, despite the warning that is logged on the DC.
You can verify this with a packet trace. See:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Using GSS-SPNEGO instead of GSSAPI will silence the warning, but older
systems (e.g. RHEL6) don’t have GSS-SPNEGO.
_______________________________________________
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/sssd-users@lists.fedorahoste...
2:20 p.m.
I believe it will still connect to the LDAP and GC ports, just the protocol
changes. To my knowledge going with the AD provider might help but you're
using LDAP for a reason instead I assume. Thinking about it though LDAP and
CLDAP calls will still connect to those ports.
-- lawrence
On Wed, Sep 2, 2020 at 3:17 PM Spike White <spikewhitetx(a)gmail.com> wrote:
Thank you.
What cybersecurity is reporting off of is a particular event number on its
AD controllers. which is showing a connection to a LDAP port.
Is there another (better) event that it should be looking for instead?
I.e., it should be flagging a simple binding only to an LDAP port.
We have a MS consultant, but they're not sssd-knowledgeable.
Spike
On Wed, Sep 2, 2020 at 2:02 PM James Ralston <ralston(a)pobox.com> wrote:
> On Wed, Sep 2, 2020 at 1:46 PM Spike White <spikewhitetx(a)gmail.com>
> wrote:
>
> > I apologize if this has been covered already. But this was just
> > brought up by our cybersecurity team. They plan to disable
> > "deprecated protocols". By that, they mean simple LDAP binding to
> > AD's LDAP port. Because of passing content in clear text.
>
> This was covered already, yes. Here’s a summary:
>
>
>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
> For the full discussion, search the list archives for these threads:
>
> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> Subject: [SSSD-users] SSSD and the forthcoming Active Directory
> LDAPocalypse
>
> > But cybersecurity is asking -- are the question "are these
> > connections signed?". I don't know the answer to that.
>
> They are signed, yes, despite the warning that is logged on the DC.
> You can verify this with a packet trace. See:
>
>
>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
> Using GSS-SPNEGO instead of GSSAPI will silence the warning, but older
> systems (e.g. RHEL6) don’t have GSS-SPNEGO.
> _______________________________________________
> 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/sssd-users@lists.fedorahoste...
>
_______________________________________________
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/sssd-users@lists.fedorahoste...
3:54 p.m.
On Wed, Sep 2, 2020 at 3:17 PM Spike White <spikewhitetx(a)gmail.com> wrote:
What cybersecurity is reporting off of is a particular event number
on its AD controllers. which is showing a connection to a LDAP
port.
Is there another (better) event that it should be looking for
instead? I.e., it should be flagging a simple binding only to an
LDAP port.
Unfortunately, there is not. A DC will log this event:
The following client performed a SASL
(Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
signing (integrity verification), or performed a simple bind over
a clear text (non-SSL/TLS-encrypted) LDAP connection.
…for both of these use cases:
1. An LDAP client uses GSSAPI (instead of GSS-SPNEGO), over a signed
and sealed connection. No passwords are transmitted in clear text.
2. An LDAP client performs a simple bind over clear text (without
sealing), which passes the bind password on the wire in clear text.
If the DCs are configured as per Microsoft’s recommendations to secure
LDAP traffic, use case #2 will break. But use case #1 will not.
(Others in the big long thread I referenced in my previous message
verified this.)
At least to my knowledge, no one has figured out a way to sift through
these events in the event log and determine which ones (if any) were
generated by LDAP clients performing simple binds over clear text
(which is undesirable) versus which ones were generated by LDAP
clients using GSSAPI (instead of GSS-SPNEGO) over a sealed connection.
Alas, Microsoft really should have used two different event types to
distinguish these cases.
5:12 p.m.
James,
Really appreciate this detailed answer. Our on-site MS consultant will be
back next week, we'll have a big conversation next week.
BTW, you reminded me. Our AD team has a few AD DCs configured for this
proposed "future state" configuration -- which will break the use case #2
above. I tested our Linux sssd clients against it, as well as our older
(commercial product) clients. Both ran fine.
Lawrence, we *are* using the AD provider. internally, the AD provider is
doing GSSAPI-based SASL LDAP binding by default. We have a mix of RHEL6,7
and 8 boxes.
Spike
On Wed, Sep 2, 2020 at 3:55 PM James Ralston <ralston(a)pobox.com> wrote:
On Wed, Sep 2, 2020 at 3:17 PM Spike White
<spikewhitetx(a)gmail.com> wrote:
> What cybersecurity is reporting off of is a particular event number
> on its AD controllers. which is showing a connection to a LDAP
> port.
>
> Is there another (better) event that it should be looking for
> instead? I.e., it should be flagging a simple binding only to an
> LDAP port.
Unfortunately, there is not. A DC will log this event:
The following client performed a SASL
(Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
signing (integrity verification), or performed a simple bind over
a clear text (non-SSL/TLS-encrypted) LDAP connection.
…for both of these use cases:
1. An LDAP client uses GSSAPI (instead of GSS-SPNEGO), over a signed
and sealed connection. No passwords are transmitted in clear text.
2. An LDAP client performs a simple bind over clear text (without
sealing), which passes the bind password on the wire in clear text.
If the DCs are configured as per Microsoft’s recommendations to secure
LDAP traffic, use case #2 will break. But use case #1 will not.
(Others in the big long thread I referenced in my previous message
verified this.)
At least to my knowledge, no one has figured out a way to sift through
these events in the event log and determine which ones (if any) were
generated by LDAP clients performing simple binds over clear text
(which is undesirable) versus which ones were generated by LDAP
clients using GSSAPI (instead of GSS-SPNEGO) over a sealed connection.
Alas, Microsoft really should have used two different event types to
distinguish these cases.
_______________________________________________
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/sssd-users@lists.fedorahoste...
1:45 a.m.
On Wed, Sep 02, 2020 at 05:12:45PM -0500, Spike White wrote:
James,
Really appreciate this detailed answer. Our on-site MS consultant will be
back next week, we'll have a big conversation next week.
BTW, you reminded me. Our AD team has a few AD DCs configured for this
proposed "future state" configuration -- which will break the use case #2
above. I tested our Linux sssd clients against it, as well as our older
(commercial product) clients. Both ran fine.
Lawrence, we *are* using the AD provider. internally, the AD provider is
doing GSSAPI-based SASL LDAP binding by default. We have a mix of RHEL6,7
and 8 boxes.
Hi,
James is right on spot. About the logged event when using GSSAPI my
colleague Thorsten also asked Microsoft in the Comments to
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/l...
There is also https://access.redhat.com/articles/4661861 which is
updated as soon as we have more information to share on this topic. One
of the latest updates here is about LDAPS and channel binding. Here
work on cyrus-sasl, openldap and MIT Kerberos was needed to make the
initial support all those components had work together as expected.
HTH
bye,
Sumit
Spike
On Wed, Sep 2, 2020 at 3:55 PM James Ralston <ralston(a)pobox.com> wrote:
> On Wed, Sep 2, 2020 at 3:17 PM Spike White <spikewhitetx(a)gmail.com> wrote:
>
> > What cybersecurity is reporting off of is a particular event number
> > on its AD controllers. which is showing a connection to a LDAP
> > port.
> >
> > Is there another (better) event that it should be looking for
> > instead? I.e., it should be flagging a simple binding only to an
> > LDAP port.
>
> Unfortunately, there is not. A DC will log this event:
>
> The following client performed a SASL
> (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
> signing (integrity verification), or performed a simple bind over
> a clear text (non-SSL/TLS-encrypted) LDAP connection.
>
> …for both of these use cases:
>
> 1. An LDAP client uses GSSAPI (instead of GSS-SPNEGO), over a signed
> and sealed connection. No passwords are transmitted in clear text.
>
> 2. An LDAP client performs a simple bind over clear text (without
> sealing), which passes the bind password on the wire in clear text.
>
> If the DCs are configured as per Microsoft’s recommendations to secure
> LDAP traffic, use case #2 will break. But use case #1 will not.
> (Others in the big long thread I referenced in my previous message
> verified this.)
>
> At least to my knowledge, no one has figured out a way to sift through
> these events in the event log and determine which ones (if any) were
> generated by LDAP clients performing simple binds over clear text
> (which is undesirable) versus which ones were generated by LDAP
> clients using GSSAPI (instead of GSS-SPNEGO) over a sealed connection.
>
> Alas, Microsoft really should have used two different event types to
> distinguish these cases.
> _______________________________________________
> 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/sssd-users@lists.fedorahoste...
>
_______________________________________________
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/sssd-users@lists.fedorahoste...
10:54 p.m.
All,
This is exactly what our cybersecurity team is reporting on. Log event ID
2289 showing up in the AD domain controller logs for Linux clients (using
sssd). Upon further research, Microsoft has just released a patch to fix
their mis-reporting:
https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003
July 21, 2020—KB4559003 (OS Build 17763.1369). Fix for Windows 10 and
Windows Server
Here's the exact bugfix (from the above URL):
- 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.
Spike
On Thu, Sep 3, 2020 at 1:46 AM Sumit Bose <sbose(a)redhat.com> wrote:
On Wed, Sep 02, 2020 at 05:12:45PM -0500, Spike White wrote:
>James,
>
>Really appreciate this detailed answer. Our on-site MS consultant will be
>back next week, we'll have a big conversation next week.
>
>BTW, you reminded me. Our AD team has a few AD DCs configured for this
>proposed "future state" configuration -- which will break the use case #2
>above. I tested our Linux sssd clients against it, as well as our older
>(commercial product) clients. Both ran fine.
>
>Lawrence, we *are* using the AD provider. internally, the AD provider is
>doing GSSAPI-based SASL LDAP binding by default. We have a mix of RHEL6,7
>and 8 boxes.
Hi,
James is right on spot. About the logged event when using GSSAPI my
colleague Thorsten also asked Microsoft in the Comments to
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/l...
There is also https://access.redhat.com/articles/4661861 which is
updated as soon as we have more information to share on this topic. One
of the latest updates here is about LDAPS and channel binding. Here
work on cyrus-sasl, openldap and MIT Kerberos was needed to make the
initial support all those components had work together as expected.
HTH
bye,
Sumit
>
>Spike
>
>On Wed, Sep 2, 2020 at 3:55 PM James Ralston <ralston(a)pobox.com> wrote:
>
>> On Wed, Sep 2, 2020 at 3:17 PM Spike White <spikewhitetx(a)gmail.com>
wrote:
>>
>> > What cybersecurity is reporting off of is a particular event number
>> > on its AD controllers. which is showing a connection to a LDAP
>> > port.
>> >
>> > Is there another (better) event that it should be looking for
>> > instead? I.e., it should be flagging a simple binding only to an
>> > LDAP port.
>>
>> Unfortunately, there is not. A DC will log this event:
>>
>> The following client performed a SASL
>> (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
>> signing (integrity verification), or performed a simple bind over
>> a clear text (non-SSL/TLS-encrypted) LDAP connection.
>>
>> …for both of these use cases:
>>
>> 1. An LDAP client uses GSSAPI (instead of GSS-SPNEGO), over a signed
>> and sealed connection. No passwords are transmitted in clear text.
>>
>> 2. An LDAP client performs a simple bind over clear text (without
>> sealing), which passes the bind password on the wire in clear text.
>>
>> If the DCs are configured as per Microsoft’s recommendations to secure
>> LDAP traffic, use case #2 will break. But use case #1 will not.
>> (Others in the big long thread I referenced in my previous message
>> verified this.)
>>
>> At least to my knowledge, no one has figured out a way to sift through
>> these events in the event log and determine which ones (if any) were
>> generated by LDAP clients performing simple binds over clear text
>> (which is undesirable) versus which ones were generated by LDAP
>> clients using GSSAPI (instead of GSS-SPNEGO) over a sealed connection.
>>
>> Alas, Microsoft really should have used two different event types to
>> distinguish these cases.
>> _______________________________________________
>> 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/sssd-users@lists.fedorahoste...
>>
>_______________________________________________
>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/sssd-users@lists.fedorahoste...
_______________________________________________
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/sssd-users@lists.fedorahoste...
1323
days inactive
1326
days old
sssd-users@lists.fedorahosted.org
7 comments
4 participants
participants (4)
-
James Ralston -
Lawrence Kearney -
Spike White -
Sumit Bose