#2121 ipa ad trusted user lookups failed with sssd_be crash
Closed: Fixed None Opened 6 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1019882

Description of problem:

I am seeing user lookups fail right after setting up a trust with active
directory.  Initial failure occurred trying to ssh.


administrator@adlabs.com:*:1436800500:1436800500:Administrator:/:
:: [   PASS   ] :: Running 'getent passwd 'ADLABS\Administrator'' (Expected 0,
got 0)
domain users@adlabs.com:*:1436800513:
:: [   PASS   ] :: Running 'getent group 'ADLABS\Domain Users'' (Expected 0,
got 0)
:: [   PASS   ] :: Running 'echo Secret123|kinit administrator@ADLABS.COM'
(Expected 0, got 0)
Connection closed by UNKNOWN
:: [   FAIL   ] :: Running 'timeout 20s             ssh -K -l
administrator@adlabs.com cloud-qe-6.spoore10151337.test 'echo login
successful'' (Expected 0, got 255)

In /var/log/secure:

Oct 15 15:27:27 cloud-qe-6 sshd[12163]: Authorized to administrator@adlabs.com,
krb5 principal administrator@ADLABS.COM (ssh_gssapi_krb5_cmdok)
Oct 15 15:27:29 cloud-qe-6 sshd[12163]: pam_sss(sshd:account): Access denied
for user administrator@adlabs.com: 4 (System error)
Oct 15 15:27:29 cloud-qe-6 sshd[12163]: fatal: Access denied for user
administrator@adlabs.com by PAM account configuration [preauth]

Near the end of the lookup at this timeframe in
/var/log/sssd/sssd_spoore10151337.test.log:

(Tue Oct 15 15:27:29 2013) [sssd[be[spoore10151337.test]]] [sdap_access_send]
(0x0400): Performing access check for user [Administrat
or@adlabs.com]
(Tue Oct 15 15:27:29 2013) [sssd[be[spoore10151337.test]]] [sdap_access_send]
(0x0040): find_subdomain_by_name failed.
(Tue Oct 15 15:27:29 2013) [sssd[be[spoore10151337.test]]]
[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, Cannot allocate
memory) [Internal Error (System error)]

And with some help from Alexander from Dev:
<snip>
To me it looks like a new bug in sssd code. "Cannot allocate memory"
returned by the backend, crash of the domain child process in sssd.log:

(Tue Oct 15 15:27:28 2013) [sssd] [mt_svc_exit_handler] (0x0040): Child
[spoore10151337.test] terminated with signal [11]
(Tue Oct 15 15:27:28 2013) [sssd] [mt_svc_restart] (0x0400): Scheduling service
spoore10151337.test for restart 1
(Tue Oct 15 15:27:28 2013) [sssd] [get_ping_config] (0x0100): Time between
service pings for [spoore10151337.test]: [10]
(Tue Oct 15 15:27:28 2013) [sssd] [get_ping_config] (0x0100): Time between
SIGTERM and SIGKILL for [spoore10151337.test]: [60]
(Tue Oct 15 15:27:28 2013) [sssd] [start_service] (0x0100): Queueing service
spoore10151337.test for startup
(Tue Oct 15 15:27:28 2013) [sssd] [sbus_server_init_new_connection] (0x0200):
Entering.

and in messages:
Oct 15 15:27:28 cloud-qe-6 kernel: [ 1712.193799] traps: sssd_be[24270] general
protection ip:7f75c9381e51 sp:7fffcdcdae00 error:0 in
libsss_ipa.so[7f75c934f000+78000]
Oct 15 15:27:28 cloud-qe-6 abrt[12206]: Saved core dump of pid 24270
(/usr/libexec/sssd/sssd_be) to /var/tmp/abrt/ccpp-2013-10-15-15:27:28-24270
(36352000 bytes)
Oct 15 15:27:28 cloud-qe-6 abrtd: New client connected
Oct 15 15:27:28 cloud-qe-6 sssd[be[spoore10151337.test]]: Starting up
Oct 15 15:27:28 cloud-qe-6 abrt-server[12207]: Generating core_backtrace
Oct 15 15:27:28 cloud-qe-6 abrt-server[12207]: Generating backtrace
Oct 15 15:27:29 cloud-qe-6 abrt-server[12207]: New problem directory
/var/tmp/abrt/ccpp-2013-10-15-15:27:28-24270, processing
Oct 15 15:27:29 cloud-qe-6 abrt-server[12207]: Sending an email...
Oct 15 15:27:29 cloud-qe-6 abrt-server[12207]: Email was sent to:
seceng-idm-qe-list@redhat.com

Can we get access to this abrt report?
</snip>

And help from Sumit from Dev:

<snip>
I think the original issue is the core dump which was caused by an
uninitialized struct member.
</snip>

I'll upload the abrt also here for future reference as well if needed.

Version-Release number of selected component (if applicable):
sssd-1.11.1-1.el7.x86_64

How reproducible:
Unknown at this time.

Steps to Reproduce:
1. Setup AD Server
2. Setup IPA Server
3. Setup Trust to AD Server
4. kinit <aduser@addomain.dom>
5. ssh -K -l <aduser@addomain.dom> <ipahost@ipadomain.dom>


Actual results:
failed to find the user and ssh.  sssd_be crashed

Expected results:
no crash and ssh in without password prompt

Additional info:

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
owner: somebody => sbose
patch: 0 => 1
review: True => 0
selected: =>
testsupdated: => 0

milestone: NEEDS_TRIAGE => SSSD 1.11.2
resolution: => fixed
status: new => closed

Fields changed

changelog: => N/A just a bug fix

Metadata Update from @jhrozek:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.11.2

3 years ago

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/3163

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.

Login to comment on this ticket.

Metadata