sssd-users October 2021

sssd-users@lists.fedorahosted.org

13 participants
13 discussions

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

kcm, gssproxy and klist
by Winberg Adam 16 Dec '21

16 Dec '21

With KCM and gssproxy we often see a long list of credentials when doing a 'klist': [user.u@lxserv2114 ~]$ klist Ticket cache: KCM:17098:66803 Default principal: user.u@AD Valid starting Expires Service principal 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: and so on... The actual gssproxy credentials at /var/lib/gssproxy/clients/ does not correspond with this output, it only contains what could be expected - a TGT and maybe some service tickets. The ever growing 'klist' list of credentials is a problem, after a while the user can no longer get any new credentials and therefore has no access to its NFS homedir (sec=krb5). I'm guessing it's the 'max_uid_ccaches' option in sssd-kcm that prevents this. What is going on here - have we configured gssproxy/kcm wrong or is this a bug? Regards Adam

3 5

SSSD entry_cache_nowait_percentage/ enum_cache_timeout not working properly?
by Robert Wagensveld 27 Oct '21

27 Oct '21

Hi all, I was hoping you could help me with this, as I am essentially clueless by this point.Even setting debug logging to 8 does not give much information as to what the problem might be. I have chosen to set the enum_cache_timeout to a high value, e.g. 26000 seconds. This because we have a very large environment in terms of AD groups (we use Kerberos over LDAP) and this takes a long time to retrieve all groups. Weird part is, although this helped on some clients, it does not actually reduce login/sudo times on others. I have set the following values in sssd.conf: entry_cache_nowait_percentage = 50 entry_cache_timeout = 60 My reason for this is that defining a value for the nowait percentage automatically update entries in the background. Not sure if I set the percentage rights though. https://linux.die.net/man/5/sssd.conf What is wise to do in this regard? My desired behavior would be that it returns entries from cache even while offline as often as possible, and updates the cache in the background. I don't want users to have to wait for SSSD to iterate through all our insane amounts of groups in the foreground. Thanks in advance!

3 4

Group cache entry of removed member in be
by Thomas HUMMEL 22 Oct '21

22 Oct '21

Hello, sssd-2.3.0 on RHEL/CentOS 8.3, I'm trying to figure out how refreshing a user cache entry could impact (or not) a group entry this user is or has been a member of in the backend I'm using sssd-2.3.0 on RHEL/CentOS 8.3 with auth_provider = ldap ldap_schema = AD access_provider = ldap id_provider = ldap authselect provides the following setup of nsswitch: passwd: sss files systemd group: sss files systemd Initial experience on *some* hosts using the same sssd config: a user <user> which has been for some time (greater than any sssd timeout) removed from group <group> in the AD backend still appeared as a member when running getent group <group> "refreshing" this user with getent passwd <user> would fix the issue I don't quite get the reasoning behind this behavior. Does the link between the 2 actions lies in the ghost/unghost mechanism ? I did not manage to reproduce it. The tests I made on another similar host raised some more questions though: a) I was able to verify the expected behavior of entry_cache_group_timeout (or entry_cache_timeout for that matter): after 1h30m getent group <group> would get the group entry from the backend. Before that result were fed by the cache and could not be consistent with the backend b) I'm having trouble understanding how sss_cache -u or -g works as, using ldbsearch -H <cache_ldb_file> I can see the dataExpireTimestamp set to 1 but after what I thought would be a refresh (getent passwd or group), I still see this value : is this because sssd RAM cache is not sync'ed ? Finally, do you confirm that the setting of ldap_purge_cache_timeout should not change how the membership of a user in a group is return ? Thanks for you help -- Thomas HUMMEL

3 3

Ubuntu 20.04 server joined to child AD domain unable to auth users from parent domain
by Joseph Agored 19 Oct '21

19 Oct '21

I have an Ubuntu 20.04 server that I have successfully joined to my domain using realm, US.EXAMPLE.COM. The way our AD is structured is that all machines are joined to the child domain for their region and all users are setup in the parent domain, EXAMPLE.COM. With full trust, etc, of course. I can successfully look up users in the US.EXAMPLE.COM domain with id or getent passwd, but cannot look up any users in the parent EXAMPLE.COM domain. I can successfully kinit to the parent domain. I have tried adding capaths to the krb5.conf as well as adding the parent domain to the sssd.conf file like this: [domain/EXAMPLE.com] inherit_from = US.EXAMPLE.com id_provider = ad debug_level = 7 krb5_validate = False The closest I seem to get is an error message saying the server isn't found in the parent domain's Kerberous DB. Client 'host/SERVER01(a)US.EXAMPLE.COM' not found in Kerberos database Surely there is a way to use the existing trust to let the machine joined to the child domain authenticate users from the parent domain? I have done this successfully in this domain before with a RedHat server using FQDN, but I am trying to get away from RedHat and move to Ubuntu and the same configuration tricks were unable to let the Ubuntu server lookup or authenticate users from the parent domain even with FQDNs.

1 0

Timing sensitive issue on `testing pam_acct_mgmt` which is also seen on SSH logins
by Aitor Pazos 18 Oct '21

18 Oct '21

Hi all, Let me introduce the symptoms that triggered this investigation. First, versions: - OS: Ubuntu 20.04 - SSSD: 2.2.3-3ubuntu0.7 - Platform: x86_64 Some weeks after starting using a new region/provider we noticed some intermittent issue impacting SSH logins (ie: clients got `Connection closed by UNKNOWN port 65535` on `ssh ...`). When looking into it, I was able to reproduce it somewhat reliably. It happens after some time of inactivity for that user, but if I constantly issue commands (ie: `watch sssctl user-checks <user>` or `watch ssh <host> whoami` from a client) the issue wont trigger. If I stopped trying out those commands and tried again ~30 minutes later, it would fail. With these symptoms I had these possibilities in mind: some caching issue, some authentication expiring, connections pools issues... I enabled detailed logging and compared logs from a successful request and a failed one and I found what seems to be the source of the error from sssd logs perspective, but still can't make much sense of it. Log extracted from sssd_<domain>.log: ``` (Wed Oct 13 19:40:52 2021) [be[<domain>]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=ipa,dc=corp,<dc <domain>>][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)))] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_print_server] (0x2000): Searching <ip10.1.10.102:389 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)][cn=hbac,dc=ipa,dc=corp,<dc <domain>>]. (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 18 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_op_add] (0x2000): New operation 18 timeout 60 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: sh[0x55d349f96d00], connected[1], ops[0x55d349ff16e0], ldap[0x55d34a10cba0] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_timeout] (0x1000): Issuing timeout for 18 (Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_destructor] (0x1000): Abandoning operation 18 (Wed Oct 13 19:41:52 2021) [be[<domain>]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [110]: Connection timed out (Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_hbac_rule_info_done] (0x0080): Could not retrieve HBAC rules (Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_pam_access_handler_done] (0x0020): Unable to fetch HBAC rules [110]: Connection timed out (Wed Oct 13 19:41:52 2021) [be[<domain>]] [dp_req_done] (0x0400): DP Request [PAM Account #21]: Request handler finished [0]: Success ``` I tried using `ldap_enumeration_search_timeout = 180` which updated the timeout in (`[sdap_op_add] (0x2000): New operation 18 timeout 60 `) but same result (`enumerate` and `subdomain_enumerate` config options are left to their defaults, `false` and `none` respectively). I looked at the IPA servers LDAP logs and saw now related requests regarding `ipaHBACRules` so I assume the request didn't even left the server. I tried tweaking some other caching options like `cached_auth_timeout` and `pam_id_timeout` without any impact. Also tried clearing up the caches with `sss_cache -E` or `systemctl stop sssd && rm /var/lib/sss/db/* && systemctl start sssd` and nothing changed. This is the error returned by `sssctl user-checks` when it fails: ``` $ sudo sssctl user-checks <user> user: <user> action: acct service: system-auth SSSD nss user lookup result: - user name: <user> - user id: <uid> - group id: <gid> - gecos: <name> - home directory: /home/<user> - shell: /bin/bash InfoPipe operation failed. Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services' option in sssd.conf.InfoPipe User lookup with [<user>] failed. testing pam_acct_mgmt pam_acct_mgmt: System error PAM Environment: - no env - ``` Any pointer here would be very useful. Thank you! Aitor

2 3

[SSSD] Announcing SSSD 2.5.2
by Pavel Březina 14 Oct '21

14 Oct '21

# SSSD 2.6.0 The SSSD team is proud to announce the release of version 2.6.0 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.6.0 See the full release notes at: https://sssd.io/release-notes/sssd-2.6.0.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users ## Highlights ### General information * Support of legacy json format for ccaches was dropped * Support of long time deprecated `secrets` responder was dropped. * Support of long time deprecated `local` provider was dropped. * This release drops support of `--with-unicode-lib` configure option. `libunistring` will be used unconditionally for Unicode processing. * This release removes pcre1 support. pcre2 is used unconditionally. * p11_child does not stop at the first empty slot when searching for tokens * A flaw was found in SSSD, where the sssctl command was vulnerable to shell command injection via the logs-fetch and cache-expire subcommands. This flaw allows an attacker to trick the root user into running a specially crafted sssctl command, such as via sudo, to gain root access. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. This patch fixes a flaw by replacing `system()` with `execvp()`. ### New features * Basic support of user's 'subuid and subgid ranges' for IPA provider and corresponding plugin for shadow-utils were introduced. Limitations: - single subid interval pair (subuid+subgid) per user - idviews aren't supported - only forward lookup (user -> subid ranges) Take a note, this is MVP of experimental feature. Significant changes might be required later, after initial feedback. Corresponding support in shadow-utils was merged upstream, but since there is no upstream release available yet, SSSD feature isn't built by default. Build can be enabled with `--with-subid` configure option. Plugin's install path can be configured with `--with-subid-lib-path=` (`${libdir}` by default) ### Important fixes * KCM now replace the old credential with new one when storing an updated credential that is however already present in the ccache to avoid unnecessary growth of the ccache. * Improve mpg search filter to be more reliable with id-overrides and the new auto_private_groups options. * Even if the forest root is disabled for lookups all required internal data is initialized to be able to refresh the list of trusted domains in the forest from a DC of the forest root. * ccache files are created with the right ownership during offline Smartcard authentication * AD ping is now sent over `ldap` if `cldap` support is not available during build. This helps to build SSSD on distributions without `cldap` support in `libldap`. * CVE-2021-3621 ### Configuration changes * New IPA provider's option `ipa_subid_ranges_search_base` allows configuration of search base for user's subid ranges. Default: `cn=subids,%basedn`

1 1

[SSSD] Announcing SSSD 2.6.0
by Pavel Březina 14 Oct '21

14 Oct '21

1 0

feasible to use sssd in mostly offline mode?
by James Ralston 12 Oct '21

12 Oct '21

For our on-site Linux machines, we use the sssd-ad provider to both map users/groups from Active Directory, and to authenticate users via Kerberos. It works fantastically well, to the point where we have absolutely no desire to go back to maintaining local users/groups in /etc/passwd and /etc/group (respectively). We are contemplating offering remote Linux laptops to our users. But our InfoSec team is adamant that our AD DCs must not be reachable from the Internet at large. So unless the owner of the laptop logs in to the laptop locally and then connects to our VPN, the laptop will have no access to Active Directory, and therefore sssd will be in offline mode. We are wondering whether it would be feasible to set the various sssd caches to have long values (e.g. 180 days) so that as long as the user fires up the laptop and connects to the VPN once every 180 days, they will still be able to login (using their cached password) and getpwnam/getpwuid/getgrnam/getgrgid will still work for their uids/gids (because sssd will return the values it cached from the last time it was able to reach the AD DCs). It’s not clear to us how we would implement this. We could adjust various timeouts; e.g., from: entry_cache_timeout = 5400 cache_credentials = FALSE To: entry_cache_timeout = 7776000 cache_credentials = TRUE …but I don’t think this is going to do what we want. We only want sssd to keep entries in the cache for 90 days when it is offline. If sssd comes back online (because the user connected to the VPN and thus AD is reachable again), we want AD to refresh any cached entries that are older than 90 minutes. So, what we really want is an option for sssd that essentially says, “You are frequently going to be operating in offline mode, so only kick things out of the cache when you are in online mode, because otherwise there’s a good chance that the user won’t be able to login to fire up the VPN so that you can switch to online mode.” Has anyone attempted running sssd in a mostly-offline environment like this? If so, how well does it work, and what settings are you using? Thanks!

2 1

https://bugzilla.redhat.com/show_bug.cgi?id=1984591 not understanding the nature of the sssd bug introduced recently…
by Spike White 11 Oct '21

11 Oct '21

All (but particularly Sumit since he wrote the comments on https://bugzilla.redhat.com/show_bug.cgi?id=1984591), There are at least two problems created by this recently-introduced sssd bug. One problem is solvable by the suggested work-around, the other is not. The work-around suggested is: [domain/name.of.joined.domain] ad_enabled_domains = dom1.example.com, dom2.example.com, dom3.example.com In order to query only the desired AD domains. What is the bug? the sssd-ad man page says "The AD provider can be used to get user information and authenticate users from trusted domains. Currently only trusted domains in the same forest are recognized.". What is happening is that untrusted AD domains are being discovered. A very specific type of untrusted domains. When the joined domain has no trust with that other domain, but that other domain trusts the original domain – that is a one-way trust (the wrong way). To the joined domain, this is an untrusted domain and should not be discovered. This is actually very common in corporate environments. You may have a main AD domain, call it CORP.COMPANY.COM. Then for testing and new production evaluation, you might have a test AD domain called LAB-TEST.COMPANY.COM. CORP.COMPANY.COM is tightly controlled, with full audits and corporate security. LAB-TEST.COMPANY.COM is a test AD domain – it’s the wild, wild west! So LAB-TEST.COMPANY.COM trusts the main AD domain (in order that users can log into this test domain with their CORP accounts). But CORP.COMPANY.COM does not trust LAB-TEST.COMPANY.COM – nor should it!! (That’s the wild, wild west, doing so would compromise corporate security.) Thus, a server joined to domain CORP.COMPANY.COM should discover CORP.COMPANY.COM and any domains trusted by CORP.COMPANY.COM. It should *NOT* discover LAB-TEST.COMPANY.COM, as CORP.COMPANY.COM does not trust this domain. A server joined to LAB-TEST.COMPANY.COM should discover LAB-TEST.COMPANY.COM and all domains trusted by LAB-TEST.COMPANY.COM. Including CORP.COMPANY.COM, as LAB-TEST.COMPANY.COM trusts CORP.COMPANY.COM. The bug is that a server joined to CORP.COMPANY.COM discovers LAB-TEST.COMPANY.COM, which it shouldn’t. What problems does this cause? Two problems. 1. Many of these untrusted discovered “lab” domains are accessible only to specific network locations. That is, they’re firewalled off to a particular lab. So sssd attempts to query these inaccessible AD domains and takes a long time to time out. This problem can be worked around by the suggested work-around in the Bugzilla: [domain/corp.company.com] ad_enabled_domains = corp.company.com So then, while LAB-TEST.COMPANY.COM is still erroneously discovered, it is no longer searched. Sssd is again fast. 2. Bogus messages in /var/log/sssd_nss.log file. Even with no debug level set in the [nss] stanza, these error messages appear multiple times a second. It quickly fills up the /var/log filesystem. [root@auspdfdlobv01 sssd]# cat sssd_nss.log |grep "The Data Provider returned an error" (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] From debug level 9, it is clear that this is arising from a query of these erroneously-discovered untrusted domains. Here’s an example of one instance of above with debug level 9 turned on. So emeaicmd.geodll.company.com is one of these erroneously-discovered untrusted lab domains, that happens to be firewalled off from this particular AD client: (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #9: Looking up [oracle(a)company.com] in cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #9: Object [oracle(a)company.com] was not found in cache (2021-10-07 9:50:02): [nss] [cache_req_search_ncache_add_to_domain] (0x0400): CR #9: Adding [oracle(a)company.com] to negative cache (2021-10-07 9:50:02): [nss] [is_user_local_by_name] (0x0400): User oracle(a)company.com is a local user (2021-10-07 9:50:02): [nss] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/company.com/oracle@company.com] to negative cache (2021-10-07 9:50:02): [nss] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain EMEAICMD.geodll.company.com type POSIX is valid (2021-10-07 9:50:02): [nss] [cache_req_set_domain] (0x0400): CR #9: Using domain [EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [cache_req_prepare_domain_data] (0x0400): CR #9: Preparing input data for domain [EMEAICMD.geodll.company.com] rules (2021-10-07 9:50:02): [nss] [cache_req_search_send] (0x0400): CR #9: Looking up oracle(a)emeaicmd.geodll.company.com (2021-10-07 9:50:02): [nss] [cache_req_search_ncache] (0x0400): CR #9: Checking negative cache for [oracle(a)emeaicmd.geodll.company.com] (2021-10-07 9:50:02): [nss] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/ EMEAICMD.geodll.company.com/oracle@emeaicmd.geodll.company.com] (2021-10-07 9:50:02): [nss] [cache_req_search_ncache] (0x0400): CR #9: [ oracle(a)emeaicmd.geodll.company.com] is not present in negative cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #9: Looking up [oracle(a)emeaicmd.geodll.company.com] in cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #9: Object [oracle(a)emeaicmd.geodll.company.com] was not found in cache (2021-10-07 9:50:02): [nss] [cache_req_search_dp] (0x0400): CR #9: Looking up [oracle(a)emeaicmd.geodll.company.com] in data provider (2021-10-07 9:50:02): [nss] [sss_dp_issue_request] (0x0400): Issuing request for [0x564d6be36a70:3:oracle@emeaicmd.geodll.company.com@ EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [sss_dp_get_account_msg] (0x0400): Creating request for [EMEAICMD.geodll.company.com ][0x3][BE_REQ_INITGROUPS][name=oracle@emeaicmd.geodll.company.com:-] (2021-10-07 9:50:02): [nss] [sbus_add_timeout] (0x2000): 0x564d6ccd6670 (2021-10-07 9:50:02): [nss] [sss_dp_internal_get_send] (0x0400): Entering request [0x564d6be36a70:3:oracle@emeaicmd.geodll.company.com@ EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #12: Looking up [oracle(a)company.com] in cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #12: Object [oracle(a)company.com] was not found in cache (2021-10-07 9:50:02): [nss] [cache_req_search_ncache_add_to_domain] (0x0400): CR #12: Adding [oracle(a)company.com] to negative cache (2021-10-07 9:50:02): [nss] [is_user_local_by_name] (0x0400): User oracle(a)company.com is a local user (2021-10-07 9:50:02): [nss] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/company.com/oracle@company.com] to negative cache (2021-10-07 9:50:02): [nss] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain EMEAICMD.geodll.company.com type POSIX is valid (2021-10-07 9:50:02): [nss] [cache_req_set_domain] (0x0400): CR #12: Using domain [EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [cache_req_prepare_domain_data] (0x0400): CR #12: Preparing input data for domain [EMEAICMD.geodll.company.com] rules (2021-10-07 9:50:02): [nss] [cache_req_search_send] (0x0400): CR #12: Looking up oracle(a)emeaicmd.geodll.company.com (2021-10-07 9:50:02): [nss] [cache_req_search_ncache] (0x0400): CR #12: Checking negative cache for [oracle(a)emeaicmd.geodll.company.com] (2021-10-07 9:50:02): [nss] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/ EMEAICMD.geodll.company.com/oracle@emeaicmd.geodll.company.com] (2021-10-07 9:50:02): [nss] [cache_req_search_ncache] (0x0400): CR #12: [ oracle(a)emeaicmd.geodll.company.com] is not present in negative cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #12: Looking up [oracle(a)emeaicmd.geodll.company.com] in cache (2021-10-07 9:50:02): [nss] [cache_req_search_cache] (0x0400): CR #12: Object [oracle(a)emeaicmd.geodll.company.com] was not found in cache (2021-10-07 9:50:02): [nss] [cache_req_search_dp] (0x0400): CR #12: Looking up [oracle(a)emeaicmd.geodll.company.com] in data provider (2021-10-07 9:50:02): [nss] [sss_dp_issue_request] (0x0400): Issuing request for [0x564d6be36a70:3:oracle@emeaicmd.geodll.company.com@ EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [sss_dp_issue_request] (0x0400): Identical request in progress: [0x564d6be36a70:3:oracle@emeaicmd.geodll.company.com@ EMEAICMD.geodll.company.com] (2021-10-07 9:50:02): [nss] [sss_dp_req_destructor] (0x0400): Deleting request: [0x564d6be36a70:3:oracle@company.com@company.com] (2021-10-07 9:50:02): [nss] [sbus_remove_timeout] (0x2000): 0x564d6ccd6670 (2021-10-07 9:50:02): [nss] [sbus_dispatch] (0x4000): dbus conn: 0x564d6ccc9300 (2021-10-07 9:50:02): [nss] [sbus_dispatch] (0x4000): Dispatching. (2021-10-07 9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.DBus.Error.Failed] The suggested work-around does not resolve problem #2. BTW, here is a listing of the domains discovered on that sssd client: [root@auspdfdlobv01 ~]# sssctl domain-list amer.company.com company.com japn.company.com emea.company.com apac.company.com EMEAICMD.geodll.company.com geodll.company.com EMEAICM.GEODLL.COMPANY.COM alienware.com corp.svcs perotsystems.net companyservices.dmz Beer.Town production.online.company.com jp-poclab.companypoc.com emea-poclab.companypoc.com oldev.preol.company.com olqa.preol.company.com ap-poclab.companypoc.com [root@auspdfdlobv01 ~]# This sssd client is joined to amer.company.com, so the only trusted domains are the first 5. The parent domain and the 4 regional domains. All those other domains below that are untrusted domains. More specifically, they trust company.com, but company.com does not trust them. (one way trust – the wrong way.) Some look like the real wild wild west (Beer.Town ?). Spike

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users October 2021