This patch adds two new functions into public
API of sysdb_sudo:
* sysdb_search_sudo_rules
* sysdb_set_sudo_rule_attr

Resolves:
https://fedorahosted.org/sssd/ticket/2081

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

The function sysdb_search_custom cannot return EOK
and together set output argument count to zero.
This case is already handled in function sysdb_search_entry
which is used inside sysdb_search_custom.

Such useless test can just cause read of unitialized variable
in case of other errors returned from sysdb_search_custom.

Error: UNINIT (CWE-457): [#def1]
sssd-1.13.4/src/db/sysdb_sudo.c:678:
    var_decl: Declaring variable "count" without initializer.
sssd-1.13.4/src/db/sysdb_sudo.c:698:
    uninit_use: Using uninitialized value "count".
 #  696|                                 SUDORULE_SUBDIR, attrs,
 #  697|                                 &count, &msgs);
 #  698|->     if (ret == ENOENT || count == 0) {
 #  699|           DEBUG(SSSDBG_TRACE_FUNC, "No rules matched\n");
 #  700|           ret = EOK;

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

Resolves https://fedorahosted.org/sssd/ticket/2158

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

This allows configuration with id_provider = proxy
and sudo_provider = ipa when someone needs to fetch
rules for local users.

https://fedorahosted.org/sssd/ticket/2972

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

The Global Catalog of AD contains some information about all users and
groups in an AD forest. Users from different domain in the forest can
have the same name. The most obvious example is the Administrator user
which is present in all domains. Although SSSD uses a domain specific
search base for looking up users in the GC the search might still return
multiple results if there is a user with the same name in one of the
child (or grand-child ...) domains because of the hierarchic nature of
the LDAP tree. Limiting the search depth would not help because users
can be created in deeply nested OUs.

Currently SSSD expects in this case that the user object is store in
CN=Users or below. This works for all default users like Administrator
but in general users can be created anywhere in the directory tree. If a
user is created outside of CN=Users and there is a user with the same
name in a child domain the initgroups command to look up the
group-memberships of the user fails because it is not clear which of the
two results should be used (initgroups for the child domain user works
fine).

This patch adds an additional scheme to select the right result based on
the domain component attribute name 'dc'. This attribute indicates an
additional component in the domain name and hence a child domain. So as
long as the result contains a dc component following out search base it
cannot be the object we are looking for. This scheme includes the old
CN=Users based one but since it is more expensive I kept the old scheme
which so far worked all the time and only use the new one if the old one
fails.

Resolves https://fedorahosted.org/sssd/ticket/2961

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

If the user is not found by cert lookup when the user is already
cached, two things may happen:
1) cert was removed from the user object
2) user was removed

Instead of issuing another cert lookup we will just remove cert
attribute from the cache not touching the expiration timestamp so
the user may be updated later when needed.

Resolves:
https://fedorahosted.org/sssd/ticket/2934

Reviewed-by: Sumit Bose <sbose@redhat.com>

Required for:
    https://fedorahosted.org/sssd/ticket/2522

Reviewed-by: Sumit Bose <sbose@redhat.com>

Reviewed-by: Sumit Bose <sbose@redhat.com>

Reviewed-by: Sumit Bose <sbose@redhat.com>

Reviewed-by: Sumit Bose <sbose@redhat.com>