Yes, as you say -- our adcli invocation must add host/<fqdn>@<REALM> to the userPrincipalName.
Here's the attributes associated with a random server AD joined via adcli/sssd: dn: CN=ACMORASTG01,OU=Servers,OU=UNIX,DC=amer,DC=company,DC=com cn: ACMORASTG01 distinguishedName: CN=ACMORASTG01,OU=Servers,OU=UNIX,DC=amer,DC=company,DC=com name: ACMORASTG01 sAMAccountName: ACMORASTG01$ dNSHostName: acmorastg01.company.com userPrincipalName: host/[email protected] servicePrincipalName: RestrictedKrbHost/acmorastg01.company.com servicePrincipalName: RestrictedKrbHost/ACMORASTG01 servicePrincipalName: host/acmorastg01.company.com servicePrincipalName: host/ACMORASTG01 I'll try to get the logs before and after, share them via dropbox. Spike On Mon, Sep 23, 2019 at 6:41 AM Sumit Bose <[email protected]> wrote: > On Mon, Sep 16, 2019 at 05:47:04PM -0500, Spike White wrote: > > All, > > > > This was a case where 'realm permit' of a user was causing a back-end > sssd > > process (sssd_be) to core dump. (sigsegv). I reported this to this > group > > a few months ago. We're working this case with the Linux OS vendor. > Turns > > out, if we explicitly add: > > > > ldap_sasl_authid = host/<HOST>@<HOST's REALM> > > > > to each [domain/XXX.COMPANY.COM] stanza in /etc/sssd/sssd.conf file, it > no > > longer core dumps. > > > > That is, we have these child AD domains defined in sssd.conf > > > > [domain/AMER.COMPANY.COM] > > > > [domain/EMEA.COMPANY.COM] > > > > [domain/APAC.COMPANY.COM] > > > > However, our host is registered in only one child domain. Say AMER for a > > server amerhost1 in North America. So we'd set: > > > > ldap_sasl_authid = host/[email protected] in each domain > stanza > > above. > > 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/[email protected]' 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/[email protected]' is a service principal and AD does not > allow service principals for authentication. So I assume that you either > added 'host/[email protected]' 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 > > > > > Why does this prevent sssd_be from core dumping? Not a clue! But sssd > > performs flawlessly once this is added. > > > > Spike > > > > > > On Thu, Aug 8, 2019 at 9:09 AM Spike White <[email protected]> > wrote: > > > > > Here is the bugzilla link to the ticket: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1738375 > > > > > > So it appears a BZ has been created. > > > > > > Spike > > > > > > On Tue, Jul 16, 2019 at 3:32 PM Jakub Hrozek <[email protected]> > wrote: > > > > > >> On Tue, Jul 16, 2019 at 12:32:29PM -0500, Spike White wrote: > > >> > The following case has been opened with RHEL support on this. It > was > > >> > opened this morning: > > >> > > > >> > (SEV 4) Case #02427449 ('realm permit group@DOMAIN' causing > background > > >> > process sssd_be to segfault.) > > >> > > >> Thank you, comment added. I hope a BZ would be created soon. > > >> _______________________________________________ > > >> sssd-users mailing list -- [email protected] > > >> To unsubscribe send an email to > [email protected] > > >> Fedora Code of Conduct: > > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > >> List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > >> List Archives: > > >> > https://lists.fedorahosted.org/archives/list/[email protected] > > >> > > > > > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
