sssd and TLS/SSL after AD Microsoft Patch

[Arnau Bria]

Dear all,

we're preparing our sssd service to be fully compliant with the patch the
Microsfot will release soon and that will make AD reject any communication
that is not encrypted. ( *ADV190023
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023*
 ).
We run Scientific Linux 7.4.
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.14.0-43.el7.x86_64

Our current conf was using TLS like:
> id_provider = ldap
> auth_provider = ldap

[...]
> ldap_tls_cacert = /etc/sssd/root-ca
> ldap_tls_reqcert = allow
> ldap_id_use_start_tls = True

ldap_uri = ldap://ldap:3268

reqcert allow is a security risk, so I consider this conf as a none valid
one *(based on my exprience I can say that we have never used an encrypted
channel. Unfortunately I don't have access to the AD server to see the logs
and I have not sniffed the network to confirm/deny my assumption)*.

I'm now working in two solutions in order to enforce encryption: enforce
TLS or use SSL.

*SSL*
According to  https://docs.pagure.org/SSSD.sssd/users/faq.html  if I want
to use SSL I need to use ldaps:

This means that if sssd.conf has ldap_uri = ldap://<server>, it will
> attempt to encrypt the communication channel with TLS (transport layer
> security). If sssd.conf has ldap_uri = ldaps://<server>, then SSL will be
> used instead of TLS

So the conf now looks like:

ldaps_uri = ldaps://ldap:3269

then, after deleting all cache and restating service the authentication
service does not work:

# id bria
> id: bria: no such user

following the above guide I found that I had to configure openldap so it
recognizes the RootCA , so I had to create a mozilla db and add the CA in
order to make ldap  work:

# grep ^TLS /etc/openldap/ldap.conf
> TLS_CACERTDIR /etc/openldap/cacerts

# certutil -L -d /etc/openldap/cacerts
> Certificate Nickname                                         Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
> CA                                                          CT,C,c

then sssd works again.
> # id bria
> uid=14925(bria)

*TLS*

Same happens if I want to enforce TLS:

ldap_tls_cacert = /etc/sssd/root-ca
> ldap_tls_reqcert = demand
> ldap_id_use_start_tls = True

the cacert is valid cert but it still needs the openldap cacerts db to be
valid in order to talk to the ldap server.

Why is then ldap_tls_cacert = /etc/sssd/root-ca even needed? I can comment
the line and sssd works perfectly.
Is this dependency between sssd and openldap documented in some other place
than the FAQ?

As te logs, even with debug level set to 9, are not saying that much in
regards the SSL/TLS, can anyone confirm that this is how sssd has to be
configured in order to ensure encryption in the communication?

TIA,

[John Beranek]

On Thu, 26 Mar 2020 at 11:47, Arnau Bria wrote:
> Dear all,
>
> we're preparing our sssd service to be fully compliant with the patch the
> Microsfot will release soon and that will make AD reject any communication
> that is not encrypted. ( *ADV190023
> https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023*
>  ).

You want to read this thread:

https://lists.fedorahosted.org/archives/list/[e-mail].o...

ldaps is *not* required for encrypted comms.

Cheers,

John

[Arnau Bria]

Hi John,

first of all thanks for your answer.

I'm not and AD/LDAP/SSSD expert, sorry in advance for my ignorance.

this is what I understand:

those changes might require to use LDAP with TLS either with START_TLS on
> the LDAP port or using LDAPS.

I understand that we have to enforce TLS or LDAPS (which bring to my
original email, how?).
> Additionally SSSD uses SASL/GSSAPI/GSS-SPNEGO for encryption with cannot
>

for the above methods  (and according to
https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html) I must join the
computer to the domain (something I cannot do). so, back to ldap with
TSL/SSL?

I still don't understand why ldaps is not required for encrypted comms.
Could you please elaborate a little your answer?
If we stick to ldap provider , who should we configure sssd if we cannot
join the server to the domain?

also, I realize that we are running a very old sssd version (1.14) so any
new feature from version 2 is not available.

TIA,
Arnau

On Thu, 26 Mar 2020 at 13:07, John Beranek  wrote:
> On Thu, 26 Mar 2020 at 11:47, Arnau Bria wrote:
> > Dear all,
> >
> > we're preparing our sssd service to be fully compliant with the patch the
> > Microsfot will release soon and that will make AD reject any communication
> > that is not encrypted. ( *ADV190023
> > https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023*
> >  ).
>
> You want to read this thread:
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
>
> ldaps is *not* required for encrypted comms.
>
> Cheers,
>
> John
>
> --
> John Beranek                         To generalise is to be an idiot.
> http://redux.org.uk/                                 -- William Blake
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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].o...

[John Beranek]

On Thu, 26 Mar 2020 at 13:00, Arnau Bria wrote:
> Hi John,
>
> first of all thanks for your answer.
>
> I'm not and AD/LDAP/SSSD expert, sorry in advance for my ignorance.

I'm certainly no expert, I was just pointing you in the direction of a
recent thread on this topic.
> this is what I understand:
> > those changes might require to use LDAP with TLS either with START_TLS on the LDAP port or using LDAPS.
>
> I understand that we have to enforce TLS or LDAPS (which bring to my original email, how?).
> > Additionally SSSD uses SASL/GSSAPI/GSS-SPNEGO for encryption with cannot
>
> for the above methods  (and according to https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html) I must join the computer to the domain (something I cannot do). so, back to ldap with TSL/SSL?

It certainly looks that way, so if your machines can't be
domain-joined then you do need to config LDAPS or LDAP+STARTLS.
> I still don't understand why ldaps is not required for encrypted comms. Could you please elaborate a little your answer?
> If we stick to ldap provider , who should we configure sssd if we cannot join the server to the domain?

GSSAPI is used to encrypt traffic over an LDAP session which is
otherwise not transport-encrypted, as I understand it.

Cheers,

John

[Arnau Bria]

Hi all,

something I've found is that the openldap behaivour I've described really
depend on the openldap version. With versions older that 2.4.44-15 (in SL)
openldap only knows about Mozilla DB whereas in newer version it fallsback
to OpenSSL and openldap then reads the certificates from the PKI store.
IOW, with newer openldap there's no need to create the Mozilla DB.

# ldapsearch -d1   -x  -H ldaps://ldapserver:3269 -b dc=domain,dc=com
>                                                 [101/4798]
>
> ldap_url_parse_ext(ldaps://ldapserver:3269)
> ldap_create
> ldap_url_parse_ext(ldaps://ldapserver:3269/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldapserver:3269
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 1.2.3.4:3269
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> attempting to connect:
> connect success
> TLSMC: MozNSS compatibility interception begins.
> tlsmc_intercept_initialization: INFO: entry options follow:
> tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap/cacerts'
> tlsmc_intercept_initialization: INFO: certfile = `(null)'
> tlsmc_intercept_initialization: INFO: keyfile = `(null)'
> tlsmc_convert: INFO: trying to open NSS DB with CACertDir =
> `/etc/openldap/cacerts'.
> tlsmc_open_nssdb: INFO: trying to initialize moznss using security dir
> `/etc/openldap` prefix `cacerts`.
> tlsmc_open_nssdb: WARN: could not initialize MozNSS context - error -8015.
> tlsmc_convert: INFO: cannot open the NSS DB, expecting PEM configuration
> is present.
> tlsmc_intercept_initialization: INFO: altered options follow:
> tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap'
> tlsmc_intercept_initialization: INFO: certfile = `(null)'
> tlsmc_intercept_initialization: INFO: keyfile = `(null)'
> tlsmc_intercept_initialization: INFO: successfully intercepted TLS
> initialization. Continuing with OpenSSL only.
> TLSMC: MozNSS compatibility interception ends.
> TLS trace: SSL_connect:before/connect initialization
> TLS trace: SSL_connect:SSLv2/v3 write client hello A
> TLS trace: SSL_connect:SSLv3 read server hello A
> TLS certificate verification: depth: 2, err: 0, subject:
> /DC=com/DC=domain/CN=[....]
> TLS certificate verification: depth: 1, err: 0, subject:
> /DC=com/DC=domain/CN=[...]
> TLS certificate verification: depth: 0, err: 0, subject:
> /CN=ldapserver/emailAddress=[...]
> ing CA 01
> TLS trace: SSL_connect:SSLv3 read server certificate A
> TLS trace: SSL_connect:SSLv3 read server done A
> TLS trace: SSL_connect:SSLv3 write client key exchange A
> TLS trace: SSL_connect:SSLv3 write change cipher spec A
> TLS trace: SSL_connect:SSLv3 write finished A
> TLS trace: SSL_connect:SSLv3 flush data
> TLS trace: SSL_connect:SSLv3 read finished A
> ldap_open_defconn: successful

HTH,
Arnau

On Thu, 26 Mar 2020 at 15:34, John Beranek  wrote:
> On Thu, 26 Mar 2020 at 13:00, Arnau Bria wrote:
> > Hi John,
> >
> > first of all thanks for your answer.
> >
> > I'm not and AD/LDAP/SSSD expert, sorry in advance for my ignorance.
>
> I'm certainly no expert, I was just pointing you in the direction of a
> recent thread on this topic.
> > this is what I understand:
> > > those changes might require to use LDAP with TLS either with START_TLS
>
> on the LDAP port or using LDAPS.
> > I understand that we have to enforce TLS or LDAPS (which bring to my
>
> original email, how?).
> > > Additionally SSSD uses SASL/GSSAPI/GSS-SPNEGO for encryption with cannot
> >
> > for the above methods  (and according to
>
> https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html) I must join
> the computer to the domain (something I cannot do). so, back to ldap with
> TSL/SSL?
>
> It certainly looks that way, so if your machines can't be
> domain-joined then you do need to config LDAPS or LDAP+STARTLS.
> > I still don't understand why ldaps is not required for encrypted comms.
>
> Could you please elaborate a little your answer?
> > If we stick to ldap provider , who should we configure sssd if we cannot
>
> join the server to the domain?
>
> GSSAPI is used to encrypt traffic over an LDAP session which is
> otherwise not transport-encrypted, as I understand it.
>
> Cheers,
>
> John
>
> --
> John Beranek                         To generalise is to be an idiot.
> http://redux.org.uk/                                 -- William Blake
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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].o...

[Lukas Slebodnik]

On (27/03/20 16:12), Arnau Bria wrote:
> Hi all,
>
> something I've found is that the openldap behaivour I've described really
> depend on the openldap version. With versions older that 2.4.44-15 (in SL)
> openldap only knows about Mozilla DB whereas in newer version it fallsback
> to OpenSSL and openldap then reads the certificates from the PKI store.
> IOW, with newer openldap there's no need to create the Mozilla DB.

Yes, it depends which crypto was used in openldap.

centos7 and old version of fedora was compiled with NSS
later version moved to openssl but some distribution has some compatibility
with NSS (convert NSS on the fly to format which works with openssl)
Tha compatibility was remove in fedora29 and thus newer version
support just openssl.

LS

[Arnau Bria]

Hi Lukas,
thanks for the explanation.

After some more testing I found that sssd version 1.16 works with SSL even
if the version of openldap are not compiled with SSL support. SSSD suddenly
requires  ldap_tls_cacert to find the CA, even when you use SSL (ldaps in
the uri). Does it make any sense?

- I expected sssd to use SSL or not depending on the openldap version
   and not sssd itself.
   - Also, if I specify ldpas, why any TLS parameter is relevant?

We can upgrade sssd in SL7, only few RH6/SL6 will special upgrade
processes...

Thanks,
Arnau

On Fri, 27 Mar 2020 at 16:32, Lukas Slebodnik  wrote:
> On (27/03/20 16:12), Arnau Bria wrote:
> > Hi all,
> >
> > something I've found is that the openldap behaivour I've described really
> > depend on the openldap version. With versions older that 2.4.44-15 (in SL)
> > openldap only knows about Mozilla DB whereas in newer version it fallsback
> > to OpenSSL and openldap then reads the certificates from the PKI store.
> > IOW, with newer openldap there's no need to create the Mozilla DB.
>
> Yes, it depends which crypto was used in openldap.
>
> centos7 and old version of fedora was compiled with NSS
> later version moved to openssl but some distribution has some compatibility
> with NSS (convert NSS on the fly to format which works with openssl)
> Tha compatibility was remove in fedora29 and thus newer version
> support just openssl.
>
> LS
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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].o...