Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
(In reply to Amiel from comment #0)
>
> Version-Release number of selected component (if applicable):
> sssd-1.16.5-10.el7_9.11
...
> When the same command is executed on sssd-1.16.5-10.el7_9.10 the apac and
> amr domain are not removed. We haven't change any configuration after the
> upgrade.
Sumit, is this side effect of bz 1984591?
Hi,
this sounds similar to an issue I'm currently working on. Would it be possible to attach SSSD debug logs to this ticket? If yes, please set 'debug_level = 9' in the [domain/...] section of sssd.conf, restart SSSD, lookup a user from a non-existing domain like 'getent passwd bla.bla' and attach the resulting log file to the ticket.
@alexey, yes but it only triggers an issue in another part of the code (assuming it is the issue I'm thinking of).
bye,
Sumit
Created attachment 1846548[details]
Test build with a potential fix
Hi,
please find attached a tar ball with test build with a potential fix. Please let me know if it fixes the issue for you and if not send lofs if possible.
bye,
Sumit
Created attachment 1846595[details]
sssd log requested
Hi Sumit,
See the attached file. Note: There are domains that you can ignore. I name them ignoreme.domain and ignoremeagain.domain.
In my test, I tried a dummy domain domain.test and a domain that is missing from sssctl domain-list - apac.global.domain.
(In reply to Amiel from comment #6)
> Created attachment 1846595[details]
> sssd log requested
>
> Hi Sumit,
>
> See the attached file. Note: There are domains that you can ignore. I name
> them ignoreme.domain and ignoremeagain.domain.
>
> In my test, I tried a dummy domain domain.test and a domain that is missing
> from sssctl domain-list - apac.global.domain.
Hi,
the logs looks very much like the issue which should be fixed by the test build attached to this ticket. Please let me know if it works for you.
bye,
Sumit
(In reply to Amiel from comment #8)
> Hi Sumit,
>
> It works! It now can detect the other region in the forest! Can we push this
> as a fix?
>
> Cheers! :)
Hi,
thank you for the fast feedback. I create pull-request with the fix at https://github.com/SSSD/sssd/pull/5927 to get the fix included upstream.
bye,
Sumit
Hi,
besides having an unexpected value the the 'trustAttribute' LDAP attribute in the trusted domain object of the forest root if might be possible to reproduce this issues when joining to a grand-child domain and then trying to lookup a user or a group from another domain in the forest which is neither the forest root not the parent of the joined domain. So at least 4 domains are needed:
forest-root
|
|----another-domain
|
|----child-domain
|
|----grandchild-domain
bye,
Sumit
Thank You Sumit for the fix. Usually, in our end the issue is when we add the server into a child-domain and tried to lookup user from another-domain and groups from another-domain/forest-root.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:0627
Description of problem: Running sssctl domain-list other domains in the AD Forest are not listed. Version-Release number of selected component (if applicable): sssd-1.16.5-10.el7_9.11 How reproducible: Steps to Reproduce: 1. Execute sssctl domain-list 2. Execute cache-remove -pos 3. Execute sssctl domain-list Actual results: eame.global.domain global.domain Expected results: eame.global.domain global.domain apac.global.domain amr.global.domain Additional info: When the same command is executed on sssd-1.16.5-10.el7_9.10 the apac and amr domain are not removed. We haven't change any configuration after the upgrade. I change the actual to 'domain' to '.domain' instead. SSSD Configuration in /etc/sssd/sssd.conf: [pam] pam_id_timeout = 9 [sssd] domains = eame.global.domain config_file_version = 2 services = nss, pam [domain/eame.global.domain] ad_server = euw-idc020.eame.global.domain, euw-idc021.eame.global.domain ad_domain = eame.global.domain krb5_realm = EAME.GLOBAL.DOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple dns_resolver_timeout = 60 ldap_deref_threshold = 0 krb5_auth_timeout = 9 simple_allow_groups = system_linux-admins Kerberos Configuration in /etc/krb5.conf: # Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_ccache_name = KEYRING:persistent:%{uid} default_realm = eame.global.domain [realms] GLOBAL.DOMAIN = { kdc = euw-IDC010.global.domain master_kdc = euw-IDC010.global.domain admin_server = euw-IDC010.global.domain } EAME.GLOBAL.DOMAIN = { kdc = euw-IDC020.eame.global.domain master_kdc = euw-IDC020.eame.global.domain admin_server = euw-IDC020.eame.global.domain default_domain = eame.global.domain } AMR.GLOBAL.DOMAIN = { kdc = euw-IDC030.amr.global.domain master_kdc = euw-IDC030.amr.global.domain admin_server = euw-IDC030.amr.global.domain default_domain = amr.global.domain } APAC.GLOBAL.DOMAIN = { kdc = euw-IDC040.apac.global.domain master_kdc = euw-IDC040.apac.global.domain admin_server = euw-IDC040.apac.global.domain default_domain = apac.global.domain } [domain_realm] .eame.global.domain = EAME.GLOBAL.DOMAIN eame.global.domain = EAME.GLOBAL.DOMAIN .apac.global.domain = APAC.GLOBAL.DOMAIN apac.global.domain = APAC.GLOBAL.DOMAIN .amr.global.domain = AMR.GLOBAL.DOMAIN amr.global.domain = AMR.GLOBAL.DOMAIN .global.domain = GLOBAL.DOMAIN global.domain = GLOBAL.DOMAIN