this series of patches should solve
https://fedorahosted.org/sssd/ticket/1749 . The solution is a bit
different than the one outline in
but after a couple of iterations I prefer this solution because it adds
only a minimal amount of new code and automatically covers features like
mid-point refresh, because the same code path is used. If we agree on
this approach I'll update the design page accordingly.
The outline is in the commit message of the 5th patch, I'll copy it here
for easier reference:
With this patch the NSS and PAM responders can handle user principal
names besides the fully qualified user names.
User principal names are build from a user name and a domain suffix
separated by an '@' sign. But the domain suffix does not necessarily has
to be the same as the configured domain name in sssd.conf of the
dynamically discovered DNS domain name of a domain. The typical use case
is an Active Directory forest with lots of different domains. To not
force the users to remember the name of the individual domain they
belong to the AD administrator can set a common domain suffix for all
users from all domains in the forest. This is typically the domain name
used for emails to make it even more easy to the users to remember it.
Since SSSD splits name and domain part at the '@' sign and the common
domain suffix might not be resolvable by DNS or the given user is not a
member of that domain (e.g. in the case where the forest root is used as
common domain suffix) SSSD might fail to look up the user.
With this patch the NSS and PAM responder will do an extra lookup for a
UPN if the domain part of the given name is not known or the user was
not found and the login name contained the '@' sign.
The first patch contains the needs changes for the LDAP provider,
patches 2, 3 and 4 some related cleanup and improvements. The main
functionality is in the 5th patch.
The attached patch adds support for gpo version checking and for conditional downloading of policy files. In order to get that to work, this patch also replaces the deprecated smb functions (e.g. smbc_open, smbc_read, etc) I had been using (not knowing they were deprecated) with the newer smb functions, such as "smbc_getFunctionOpen(smbc_ctx)(smbc_ctx, smb_uri, O_RDONLY, 0755);".
Before this patch, the policy files were being unconditionally downloaded every time. After this patch, the backend sends the cached_gpt_version (from a previous transaction, if any) to the gpo_child. The gpo_child downloads the per-GPO GPT.INI file, from which it extracts the sysvol_gpt_version. Only if the sysvol_gpt_version is greater than the cached_gpt_version (or if there is no cached_gpt_version) does the gpo_child download the policy files. The gpo_child returns the sysvol_gpt_version to the backend, which stores it in the cache.
Note that, while a GPO has both a SYSVOL-stored Group Policy Template (gpt) version, as well as an LDAP-stored Group Policy Container (gpc) version (which should be equal), it is best practice to use the gpt version for version checking b/c SYSVOL replication is typically much faster than AD replication. In other words, the gpt version is quickly up-to-date on all DCs for a given domain, while the gpc version may be stale for some time after a change is made.
In order to keep the gpo_child as simple as possible, the gpo_child does not interact with the sysdb cache at all (only the backend does). However, the gpo_child does need to parse the GPT.INI file in order to determine whether to download the policy files. As such, the gpo_child includes GPT.INI file parsing functionality (which is per-GPO, and not CSE-specific).
Note that this patch does not add support for offline mode, which will be implemented in a subsequent patch.
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
* InteractiveLogonRight Allows a user to log on locally at the computers keyboard.
* RemoteInteractiveLogonRight Allow logon through RDP/Terminal Services
* NetworkLogonRight Determines which users are allowed to connect over the network to the computer.
* BatchLogonRight Allows a user to log on by using a batch-queue facility.
* ServiceLogonRight Allows a security principal to log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind, I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares, then I think the case for supporting NetworkLogonRight is less compelling. In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
this patch replaces strerror with sss_strerror on some places.
I think it would be OK to use always sss_strerror, but to keep
the patch relatively small I left strerror on places where
we directly print value of errno or return value of some third
party functions that do not (and never will) return our specific
Patch is attached. It may look big (111 files changed), but
there are only few insertions and deletions in each.
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?
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.
With regard to adding support for gpo processing in offline mode, if we have gpo-guids and policy files cached from previous transactions, then we can simply retrieve all the gpo-guids from the cache, construct the policy file names, retrieve the policy files from the local GPO_CACHE directory, and perform the access checks.
However, I have some questions:
1. If we don't have any gpo-guids or policy files cached from previous transactions, should gpo processing deny access by default (assuming that gpo_mode is enforcing)?
2. If we detect that we are off-line, at what points do we need to attempt to recover and perform offline processing (as opposed to simply returning an error). Certainly, we should perform offline processing if the initial ldap connect response (i.e. sdap_id_op_connect_recv) returns a dp_error of DP_ERR_OFFLINE. However, if one of the several ldap search responses (i.e. sdap_get_generic_recv) return a dp_error of DP_ERR_OFFLINE, should we still attempt to recover? Should we attempt to recover if the smb connect or smb read fails (in the gpo_child)?
3. If the initial ldap connection succeeds, but we go offline at a later point (and if the right thing to do is to attempt to recover at that point, per question 2), am I correct in assuming that we should discard any data received from the server up to then (if any), and behave as if we were offline since the connection started?
Here are three patches which make sssd.spec.in work on distros without
libini_config-devel >= 1.1.0, which basically means all currently released
This is also done to make CI mock builds work again.