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/acmorastg01.company.com@AMER.COMPANY.COM
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 <sbose@redhat.com> 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/amerhost1@AMER.COMPANY.COM  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/amerhost1@AMER.COMPANY.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@AMER.COMPANY.COM' is a service principal and AD does not
allow service principals for authentication. So I assume that you either
added 'host/amerhost1@AMER.COMPANY.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

>
> 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 <spikewhitetx@gmail.com> 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 <jhrozek@redhat.com> 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 -- sssd-users@lists.fedorahosted.org
> >> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> >> 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/sssd-users@lists.fedorahosted.org
> >>
> >

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> 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/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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/sssd-users@lists.fedorahosted.org