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:*:1436800500:1436800500:Administrator:/:
:: [   PASS   ] :: Running 'getent passwd 'ADLABS\Administrator'' (Expected 0, got 0)
domain users:*:1436800513:
:: [   PASS   ] :: Running 'getent group 'ADLABS\Domain Users'' (Expected 0, got 0)
:: [   PASS   ] :: Running 'echo Secret123|kinit administrator' (Expected 0, got 0)
Connection closed by UNKNOWN
:: [   FAIL   ] :: Running 'timeout 20s             ssh -K -l administrator 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, krb5 principal administrator (ssh_gssapi_krb5_cmdok)
Oct 15 15:27:29 cloud-qe-6 sshd[12163]: pam_sss(sshd:account): Access denied for user administrator: 4 (System error)
Oct 15 15:27:29 cloud-qe-6 sshd[12163]: fatal: Access denied for user administrator 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]
(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

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>
5. ssh -K -l <aduser> <ipahost>


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

Expected results:
no crash and ssh in without password prompt

Additional info: