the attached patches change the replace-space-in-name functionality
after discussion on the list. In short:
- only space can be substituted
- for only one character, not a string
- the option is now set in the [sssd] section because it works for
For more details, please see the attached patches.
The attached patch adds support for gpo processing in offline mode. While the code for online mode uses LDAP to determine which gpo-guids are applicable (and then uses SMB to retrieve policy files), the code in offline mode simply retrieves all gpo-guids from the cache (and then retrieves locally cached per-gpo-guid policy files). Note that neither version checking nor the ad_gpo_cache_timeout option are relevant when in offline mode.
* if there are no gpo-guids in the cache, the code currently denies access; i suspect we should be allowing access instead; agree?
* i don't think offline callbacks are needed, but i'm unclear about whether online callbacks are needed; i suspect they are not needed for the access provider (b/c I don't see them being used by the ad_access_filter code); should we trigger a fresh round of gpo processing when transitioning from offline to online?
I think we shouldn't honor the default_domain_suffix for netgroup lookups
at all. The main use case for the option is to avoid entering the domain
for users from AD trusts, where you don't have netgroups on the AD
side. Moreover, netgroups don't play well eith fully qualified lookups
either way (see commit 1933ff17513da1d979dd22776a03478341ef5e6b).
Using default_domain_suffix for netgroups is actually harmful, because
hostgroups defined on an IPA server are translated into netgroups, so
honoring the suffix breaks sudo rules in the trust case.
As a side-effect, this patch should fix
the attached two patches are not strictly related to tokenGroups
processing, but it's very easy to reproduce the problem that way. The
issue is only confusing DEBUG messages, but it has already cost me
several hours in processing logs from an SSSD user, so I think a fix is
due, at least for master.
See the patches and the commit messages for more details.
ldap provider doesn't asks for EntryUSN attr when it downloads sudo
rules. It's because the attribute is missing in sudorule_map. This bug
was created when the support of 'sudoRunAs' attr was added.