A trace on the OpenLDAP server when sssd is ran as a daemon. This is when sssd is started.
sssd-daemon-openldap-traces.txt

The trace of teh various sssd providers when sssd is started as a daemon
sssd-daemon-openldap-traces.2.txt

SSSD traces when ran under strace
sssd-strace-openldap-traces.2.txt

SSSD traces when ran under strace
sssd-strace-openldap-traces.txt

SSSD traces when ran as a daemon
sssd-daemon-openldap-traces.3.txt

I'm sorry, but it seems that adding attachements is a bit buggy. I have tried to attach 4 different files, but at the end, the same file has been attached many times :/

Is there a way to delete the duplicate attachements ?

SSSD traces when ran under strace
sssd-strace.tar

SSSD logs when ran as a daemon
sssd.tar

My bad, I was actually attaching the same files many times :/

The four attachements are :

• sssd.tar and sssd-daemon-openldap-traces.txt for a run with SSSD as a daemon (and a negociation failure)
• sssd-strace.tar and sssd-strace-openldap-traces.txt​ wor a run with SSSD under strace ( and a success with some data read from teh OpenLDAP server)

What OS are you running on the server and the client? Do you know if the server and client side OpenLDAP components are linked with NSS or OpenSSL for crypto?

I'm not sure about the timing issue, because the TLS setup should be synchronous...

Does the issue happen also with ldaps:// (or vice versa) ?

It's running on CentOS :
Linux camembert 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

AFAICT, it's using NSS, not openSSL. I suspect that it might work when linked with OpenSSL

I have not tested with ldaps, which is a deprecated protocol.

Matus, can you please help us check the logs if anything strikes you as odd? This is a well-tested case and I couldn't reproduce it myself..

cc: => mhonek

To bring a bit more light on the logs, when SSSD runs as a daemon, we don't even get the TLS CLient HELLO bit. Instead, we receive a Unbind Request :

Extended Request, StartTLS
...
ldap_read: want=8, got=8
...
30 1d
02 01 01
77 18
80 16
31 2e 33 2e 36 2e 31 2e
34 2e 31 2e 31 34 36 36
2e 32 30 30 33 37

...
Extended Response, StartTLS
52 566725a5 send_ldap_response: msgid=1 tag=120 err=0
53 ber_flush2: 14 bytes to sd 16
...
30 0c
02 01 01
78 07
0a 01 00
04 00
04 00
...
Unbind Request
66 TLS trace: SSL_accept:before/accept initialization
67 tls_read: want=11, got=7

30 05
02 01 02
42 00

The last PDU encodes for the LDAP Unbind request - 0x42 -. Quite unexpected !

Could it be that the connection is closed because one of the provider tries to talk to the server before the TLS handshake actually occurs ? (I see no trace of such a handshake in the sssd_symas logs for the 'symas' domain, something I see in the successful traces).

_comment0: To bring a bit more light on the logs, when SSSD runs as a daemon, we don't even get the TLS CLient HELLO bit. Instead, we receive a Unbind Request :

Extended Request, StartTLS

...
ldap_read: want=8, got=8
...
30 1d
02 01 01
77 18
80 16
31 2e 33 2e 36 2e 31 2e 1.3.6.1.4.1.1466.20037
34 2e 31 2e 31 34 36 36
2e 32 30 30 33 37

...
Extended Response, StartTLS
52 566725a5 send_ldap_response: msgid=1 tag=120 err=0
53 ber_flush2: 14 bytes to sd 16
...
30 0c
02 01 01
78 07
0a 01 00
04 00
04 00
...
Unbind Request
66 TLS trace: SSL_accept:before/accept initialization
67 tls_read: want=11, got=7

30 05
02 01 02
42 00 => 1449769409453104

So SSSD here fails in the sdap_connect_send request. What we do there is open the socket to the server, then connect(2) it, run ldap_init_fd(3) to get the LDAP handle, then run ldap_start_tls(3). There should be no other activity, because until the whole request that runs ldap_start_tls finishes, the internal connected flag of SSSD should not be set.

If you're able to run a custom build for a test, I can prepare one with LDAP_OPT_DEBUG_LEVEL enabled, maybe this could help to shed some more light?

I'm a bit stumped, because this is such a basic use-case. Could you also attach or send me the sssd.conf so I can setup exactly the same client config? If you don't want to attach the config file, feel free to alternatively send it to my fedoraproject nick @redhat.com.

Also, when you say you straced the deamon, how did you do that, did you run the deamon on the foreground or used the command option in the domain section?

Also, the server version is the stock centos one or some other?

The sssd.conf I'm using
sssd.conf

The self-signed CA certificate
cacert.pem

I have attached the sssd.conf file I'm using, and the CA certificate I also use on the server (self-signed). There is no critical information in both of them, I'm running a test here.

I can of course run a debug version of sssd.

Regarding strace, I just launched "strace /usr/sbin/sssd -f -i &> /tmp/traces ".

No idea about where the CentoS comes from, I'll ask and tell you later.

Hello, can you try these builds?

https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-6.7-ldap-debug/

They add extra debugging that is enabled if you export SSSD_DEBUG_LDAP_SEARCH variable with the same values as libldap takes, for example SSSD_DEBUG_LDAP_SEARCH=255

btw the variable can be exported either on the command line:
SSSD_DEBUG_LDAP_SEARCH=255 sssd -i or via the sysconfig file

Hi, please let me know if those packages help you get some more debugging data..

Sorry for the delay... The end of the year is not the right timing for such investigation ;-)

I'll have a look this afternoon, all the alcohol is now out of my brain (mostly)

btw I've been also pointed to https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables by my colleague, maybe enabling those options would also shed some light?

Fields changed

owner: somebody => jhrozek

Hi, any luck with those test packages?

Please reopen with the new debug logs..

resolution: => worksforme
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3937

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.