Bug 1738375
Summary: | realm permit group@DOMAIN' causing background process sssd_be to segfault | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | toasty <wrydberg> |
Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | sssd-qe <sssd-qe> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.0 | CC: | atikhono, dchen, dpal, grajaiya, hbarcomb, jhrozek, lslebodn, mzidek, pbrezina, sbose, tscherf |
Target Milestone: | rc | Keywords: | GSSTriaged |
Target Release: | 8.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-10-22 11:29:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
toasty
2019-08-07 02:42:48 UTC
As I already asked in the support case we need the following information to proceed: - core file - log files there is a sosreport in the case but unfortunately it was generated with the default (silent) debug_level. We keep a document upstream https://docs.pagure.org/SSSD.sssd/users/reporting_bugs.html that might be of some help. Hi, the core dump looks similiar to the one from https://bugzilla.redhat.com/show_bug.cgi?id=1734040. I guess it is not strictly 'realm permit' which triggers the issue but the restart triggered by 'realm permit' to re-read the changes permission list. Can you ask the customer if there is a segfault after just calling 'systemctl restart sssd' as well? Additionally I wonder if the customer can try to add ldap_search_base = dc=_localtion_,dc=company,dc=com to each [domain/...] section in their sssd.conf where _location_ is replaced by the first domain component. bye, Sumit Hello sumit, case is closed by automation. We have asked information from customer, waiting for him to revert. Waiting for information from customer. According to https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/SSIWKCOCI4OIT2DMYEHCGCXQXRJDVKUC/ (the same thread as in bug description) The symptom is gone after the following line is put in each [domain/XXX.COMPANY.COM] if we explicitly add: ldap_sasl_authid = host/<HOST>@<HOST's REALM> Customer has provided any information on case. Case is also closed. Hi, jfyi I send the following comment to the mailing list: Hi, it would be good to see some before and after debug logs. If ldap_sasl_authid is not set SSSD tries to determine it from the keytab with a priority as given in the sssd-ldap man page: hostname@REALM netbiosname$@REALM host/hostname@REALM *$@REALM host/*@REALM host/* For a domain other than AMER.COMPANY.COM all patters with '@REALM' would not match since the realm in the keytab will be AMER.COMPANY.COM. The last entry would match 'host/amerhost1.COM' but maybe there is another matching entry before in the keytab which matches first? The logs would show which principal was selected with ldap_sasl_authid set. What is a but puzzling is that by default 'host/amerhost1.COM' is a service principal and AD does not allow service principals for authentication. So I assume that you either added 'host/amerhost1.COM' to the userPrincipalName attribute of the host object or configured AD to allow service principals for authentication. The second thing which is puzzling, if the wrong principal was chosen for authentication, authentication will just fail and the backend should switch into offline mode. And finally, according to the case you've opened the crash happened in the process which handles the AMER.COMPANY.COM domain in not in one of the others which might have chosen a wrong principal. So, if you can attach to the case the logs with 'debug_level=9' in all [domain/...] sections of sssd.conf once with ldap_sasl_authid set and once without if might help to understand why SSSD fails without ldap_sasl_authid set. bye, Sumit Thanks sumit conveyed and asked customer to provide sssd debug_level=9 logs. Will revert once hear from Customer. |