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.o...
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.o... _______________________________________________ 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.o...