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.