ldap_result returns -1 when called from sssd
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap (Fedora) |
Fix Released
|
Critical
|
|||
openldap (Ubuntu) |
Fix Released
|
Critical
|
Unassigned |
Bug Description
sssd fails to obtain ldap results and marks the ldap server as "offline" when used with libldap-2.4-2 2.4.28-1.1ubuntu2, as ldap_result always returns -1. Reverting to libldap-2.4-2 2.4.25-1.1ubuntu4 fixes the problem.
This seems to be an upstream bug, also seen in Fedora: https:/
From the sssd log (w/ logging using gettimeofday():)
(Thu Feb 9 14:59:28:249698 2012) [sssd[be[
(Thu Feb 9 14:59:28:250239 2012) [sssd[be[
(Thu Feb 9 14:59:28:250282 2012) [sssd[be[
(Thu Feb 9 14:59:28:250317 2012) [sssd[be[
tcpdump at the same time, 192.168.1.2 client, 192.168.1.1 server, STARTTLS in use:
14:59:28.068940 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [S], seq 592009926, win 14600, options [mss 1460,sackOK,TS val 5276654 ecr 0,nop,wscale 7], length 0
14:59:28.070612 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [S.], seq 3103016433, ack 592009927, win 14480, options [mss 1460,sackOK,TS val 109205234 ecr 5276654,nop,wscale 6], length 0
14:59:28.070686 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [.], ack 1, win 115, options [nop,nop,TS val 5276655 ecr 109205234], length 0
14:59:28.071294 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 1:32, ack 1, win 115, options [nop,nop,TS val 5276655 ecr 109205234], length 31
14:59:28.072793 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [.], ack 32, win 227, options [nop,nop,TS val 109205234 ecr 5276655], length 0
14:59:28.072841 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 1:15, ack 32, win 227, options [nop,nop,TS val 109205234 ecr 5276655], length 14
14:59:28.072862 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [.], ack 15, win 115, options [nop,nop,TS val 5276655 ecr 109205234], length 0
14:59:28.079040 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 32:149, ack 15, win 115, options [nop,nop,TS val 5276657 ecr 109205234], length 117
14:59:28.097160 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 15:101, ack 149, win 227, options [nop,nop,TS val 109205240 ecr 5276657], length 86
14:59:28.098343 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [.], seq 101:1549, ack 149, win 227, options [nop,nop,TS val 109205240 ecr 5276657], length 1448
14:59:28.098525 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [.], ack 1549, win 137, options [nop,nop,TS val 5276662 ecr 109205240], length 0
14:59:28.099813 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [.], seq 1549:2997, ack 149, win 227, options [nop,nop,TS val 109205240 ecr 5276657], length 1448
14:59:28.099839 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 2997:3458, ack 149, win 227, options [nop,nop,TS val 109205240 ecr 5276657], length 461
14:59:28.099843 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 3458:3467, ack 149, win 227, options [nop,nop,TS val 109205240 ecr 5276657], length 9
14:59:28.099995 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [.], ack 3458, win 182, options [nop,nop,TS val 5276662 ecr 109205240], length 0
14:59:28.104322 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 149:672, ack 3467, win 182, options [nop,nop,TS val 5276663 ecr 109205240], length 523
14:59:28.104361 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 672:678, ack 3467, win 182, options [nop,nop,TS val 5276663 ecr 109205240], length 6
14:59:28.106046 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 678:811, ack 3467, win 182, options [nop,nop,TS val 5276664 ecr 109205240], length 133
14:59:28.107332 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [.], ack 811, win 260, options [nop,nop,TS val 109205243 ecr 5276663], length 0
14:59:28.240882 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 3467:3473, ack 811, win 260, options [nop,nop,TS val 109205276 ecr 5276663], length 6
14:59:28.240926 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 3473:3654, ack 811, win 260, options [nop,nop,TS val 109205276 ecr 5276663], length 181
14:59:28.241193 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [.], ack 3654, win 205, options [nop,nop,TS val 5276698 ecr 109205276], length 0
14:59:28.249698 calling ldap_search_ext (objectclass=*)
14:59:28.250206 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 811:1200, ack 3654, win 205, options [nop,nop,TS val 5276700 ecr 109205276], length 389
14:59:28.250239 ldap_search_ext called, msgid = 2
14:59:28.250282 ldap_result called
14:59:28.250317 ldap_result returns -1
14:59:28.250535 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 1200:1381, ack 3654, win 205, options [nop,nop,TS val 5276700 ecr 109205276], length 181
14:59:28.250886 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 1381:1498, ack 3654, win 205, options [nop,nop,TS val 5276700 ecr 109205276], length 117
14:59:28.251052 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [P.], seq 1498:1727, ack 3654, win 205, options [nop,nop,TS val 5276700 ecr 109205276], length 229
14:59:28.251075 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [F.], seq 1727, ack 3654, win 205, options [nop,nop,TS val 5276700 ecr 109205276], length 0
14:59:28.251295 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [.], ack 1381, win 294, options [nop,nop,TS val 109205279 ecr 5276700], length 0
14:59:28.253382 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [P.], seq 3654:3723, ack 1498, win 294, options [nop,nop,TS val 109205279 ecr 5276700], length 69
14:59:28.253430 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [R], seq 592011424, win 0, length 0
14:59:28.253477 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [F.], seq 3723, ack 1498, win 294, options [nop,nop,TS val 109205279 ecr 5276700], length 0
14:59:28.253488 IP 192.168.1.2.53857 > 192.168.1.1.389: Flags [R], seq 592011424, win 0, length 0
14:59:28.253918 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [R], seq 3103020087, win 0, length 0
14:59:28.253938 IP 192.168.1.1.389 > 192.168.1.2.53857: Flags [R], seq 3103020087, win 0, length 0
Changed in openldap (Ubuntu): | |
importance: | Undecided → Critical |
status: | New → Confirmed |
Changed in openldap (Fedora): | |
importance: | Unknown → Critical |
status: | Unknown → Fix Released |
Description of problem: 2.4.28- 1.fc17.
sssd ID searches break with openldap-
How reproducible:
Always
Steps to Reproduce:
1. Set up sssd on a Rawhide box
2. Run getent passwd <userid>, eg. "getent passwd kdreyer"
Actual results:
(user is not found)
Expected results: *:500:100: Ken Dreyer: /home/kdreyer: /bin/bash
kdreyer:
Additional info:
My LDAP server is CentOS 5, openldap- servers- 2.3.43- 12.el5_ 7.10
(regular openldap-clients commands in 2.4.28-1.fc17, for example ldapwhoami, or ldapsearch, work fine against this server. It is only sssd that breaks here.)
In the sssd_KTDREYER.log:
(Tue Jan 3 12:12:11 2012) [sssd[be[ KTDREYER] ]] [simple_bind_send] (0x0100): Executing simple bind as: (null) KTDREYER] ]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 KTDREYER] ]] [sdap_process_ result] (0x2000): Trace: sh[0xb8eee4c0], connected[1], ops[0xb8f76e10], ldap[0xb8ee1ca0] KTDREYER] ]] [sdap_process_ result] (0x0100): ldap_result gave -1, something bad happend! KTDREYER] ]] [sdap_handle_ release] (0x2000): Trace: sh[0xb8eee4c0], connected[1], ops[0xb8f76e10], ldap[0xb8ee1ca0], destructor_lock[0], release_memory[0] KTDREYER] ]] [remove_ connection_ callback] (0x4000): Successfully removed connection callback. KTDREYER] ]] [fo_set_ port_status] (0x0100): Marking port 636 of server 'salt.ktdreyer.com' as 'not working'
(Tue Jan 3 12:12:11 2012) [sssd[be[
(Tue Jan 3 12:12:11 2012) [sssd[be[
(Tue Jan 3 12:12:11 2012) [sssd[be[
(Tue Jan 3 12:12:11 2012) [sssd[be[
(Tue Jan 3 12:12:11 2012) [sssd[be[
(Tue Jan 3 12:12:11 2012) [sssd[be[
My sssd config is working fine on EL5, EL6, and F15. Thanks to sgallagh in #sssd, I found out that when I dowgrade openldap to 2.4.26-5.fc17, sssd works again. koji.fedoraproj ect.org/ koji/buildinfo? buildID= 267220
http://