Description of problem:
I installed F20 from a live image, and then immediately used yum to upgrade to F21.
I manually installed krb5-workstation, sssd-dbus, sssd-tools and adcli
Then I tried to add a corporate account through the GUI.
The domain has moved into the list shown by "realm list", the two users I tried to add are listed as permitted logins, but the GUI tells me it cannot find the users. Very likely because of the crash in the LDAP module. :-)
Version-Release number of selected component:
cmdline: /usr/libexec/sssd/ldap_child --debug-microseconds=0 --debug-timestamps=1 --debug-fd=17 --debug-level=0x0010
runlevel: N 5
Thread no. 1 (4 frames)
#2 vasprintf at /usr/include/bits/stdio2.h:210
#3 sss_log_ext at src/util/sss_log.c:80
#4 sss_log at src/util/sss_log.c:65
#5 ldap_child_get_tgt_sync at src/providers/ldap/ldap_child.c:321
Created attachment 922840 [details]
Created attachment 922841 [details]
Created attachment 922842 [details]
Created attachment 922843 [details]
Created attachment 922844 [details]
Created attachment 922845 [details]
Created attachment 922846 [details]
Created attachment 922847 [details]
Created attachment 922848 [details]
Created attachment 922849 [details]
Could you also attach coredump? It should be stored in directory /var/tmp/abrt/ccpp-2014-07-31-09:23:01-2995.
Did crash occur just once? Is it always reproducible?
btw the crash seems to be happening in the debug message that warns about a wrong keytab -- so the first step should be to fix the keytab..
We should still fix the crash, though.
Created attachment 924390 [details]
I tried again yesterday. This time it worked.
At the time of the crash it failed for 2 different users, but I didn't reboot and retry then.
Thank you very much for coredump. It seems to be bur in glibc, because there are strande data in va_list. On the other hand, I am not very familiar with handling va_list in glibc. I just read documentation  on page 54-55.
sssd crashed while debug message was printed.
(gdb) l 320,326
320 sss_krb5_get_error_message(context, krberr));
322 "Failed to initialize credentials using keytab [%s]: %s. "
323 "Unable to create GSSAPI-encrypted LDAP connection.",
325 sss_krb5_get_error_message(context, krberr));
From va_list, I found strings which should be printed.
(gdb) x/xg ap.reg_save_area+16*0
(gdb) x/s 0x00007f0ad81628c0
0x7f0ad81628c0: "Client 'SCH-LF-02899$@SCHIBSTED.NO' not found in Kerberos database"
error message from function sss_krb5_get_error_message
(gdb) x/xg ap.reg_save_area+16*1
(gdb) x/s 0x00007f0ad769a5a0
expanded macro KEYTAB_CLEAN_NAME
(gdb) x/xg ap.reg_save_area+16*2
(gdb) x/s 0x6e6920646e756f66
0x6e6920646e756f66: <error: Cannot access memory at address 0x6e6920646e756f66>
sssd crashed due to pointer with malformed data. A I already mentioned it could be bug in glibc or somehow related to upgrade of glibc.
(gdb) x/xg ap.reg_save_area+16*3
Do you have an idea why there was error:
"Client 'SCH-LF-02899$@SCHIBSTED.NO' not found in Kerberos database"
that would be my pc. I can understand that the PC object didn't exist when creating the first user.
In our domain a user can register a limited number of devices without involving a domain admin, so registering the PC should have worked. And it seemingly did when I tried again a week later.
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 21 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
I think it would be fair to not rely on "Fedora End Of Life"
and close this ticket as INSUFFICIENT_DATA because we do not know how to reproduce it and it's not clear from coredump what should be fixed.