Yes, as you say -- our adcli invocation must add host/<fqdn>@<REALM> to the
Here's the attributes associated with a random server AD joined via
I'll try to get the logs before and after, share them via dropbox.
On Mon, Sep 23, 2019 at 6:41 AM Sumit Bose <sbose(a)redhat.com> wrote:
On Mon, Sep 16, 2019 at 05:47:04PM -0500, Spike White wrote:
> This was a case where 'realm permit' of a user was causing a back-end
> process (sssd_be) to core dump. (sigsegv). I reported this to this
> a few months ago. We're working this case with the Linux OS vendor.
> 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
> longer core dumps.
> That is, we have these child AD domains defined in sssd.conf
> 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(a)AMER.COMPANY.COM in each domain
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:
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
last entry would match 'host/amerhost1(a)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(a)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(a)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
> Why does this prevent sssd_be from core dumping? Not a clue! But sssd
> performs flawlessly once this is added.
> On Thu, Aug 8, 2019 at 9:09 AM Spike White <spikewhitetx(a)gmail.com>
> > 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(a)redhat.com>
> >> 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
> >> > opened this morning:
> >> >
> >> > (SEV 4) Case #02427449 ('realm permit group@DOMAIN' causing
> >> > process sssd_be to segfault.)
> >> Thank you, comment added. I hope a BZ would be created soon.
> >> _______________________________________________
> >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> >> To unsubscribe send an email to
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:
> >> List Archives:
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines