CACHE_REQ: Use the domain-locator request to only search domains where the entry was found Uses the internal cache_req interface around the getAccountDomain to only search the domain returned by the cache_req_locate_domain_recv() request. If that request returns that no domain matched, all domains (belonging to the currently processed main domain) are skipped by setting the per-type negative cache. if a domain is reported as containing an object, all domains except that one are marked with the negative cache entries. Resolves: https://pagure.io/SSSD/sssd/issue/3468 Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Sumit Bose <sbose@redhat.com>

CACHE_REQ: Copy the cr_domain list for each request Let's copy the cr_domain list for each request as this list may be free'd due to a refresh domains request. Resolves: https://pagure.io/SSSD/sssd/issue/3551 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com>

RESPONDER: Use fqnames as output when needed As some regressions have been caused by not handling properly naming conflicts when using shortnames, last explicitly use fully qualified names as output in the following situations: - domain resolution order is set; - a trusted domain has been using `use_fully_qualified_name = false` In both cases we want to ensure that even handling shortnames as input, the output will always be fully qualified. As part of this patch, our tests ended up being modified to reflect the changes done. In other words, the tests related to shortnames now return expect as return a fully qualified name for trusted domains. Resolves: https://pagure.io/SSSD/sssd/issue/3403 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

CACHE_REQ: Allow configurationless shortname lookups Configurationless shortnames lookups must be allowed when a domains' resolution order is present and the (head) domain is not enforcing the usage of fully-qualified-names. With this patch SSSD does not require any kind of changes from client side for taking advantage of shortname lookups. Related: https://pagure.io/SSSD/sssd/issue/3001 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com>

RESPONDER: Fallback to global domain resolution order in case the view doesn't have this option set The current code has been ignoring the domain resolution order set globally on IPA in case there's a view but this doesn't have any domain resolution order set. It happens because we haven't been checking whether the view attribute didn't exist and then we ended up populating the list cache_req domains' list assuming that no order has been set instead of falling back to the next preferred method. Related: https://pagure.io/SSSD/sssd/issue/3001 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com>

CACHE_REQ: Make use of domainResolutionOrder domainResolutionOrder has been introduced in the previous commits and allows the admin to set up a specific order which the domains will be resolved during a lookup and with this patch we can take advantage of this. In order to have it working a new structure has been added (struct domain_resolution_order) to the responder context and will be used by the cache_req to perform the lookups based on this list. As the ipaDomainResolutionOrder may be set globally on IPA or per View, SSSD does respect the following precedence order: View > Globally. The way the list is built is quite simple, basically having the domains present on ipaDomainResolutionOrder as the first domains (in that specific order) and then appending the remaining domains to this list. The final result is a completely flat list with all the domains respecting the specified order (it's important to remember that the domains not specified won't follow any specific order, they're just "random" based on the domains list present in the responder context. Related: https://pagure.io/SSSD/sssd/issue/3001 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com>