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: