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.
attached are three patches related to
The first one simply adds the Windows Server 2012 R2 functional level.
The second falls back to the oldest supported Windows Server in case we
can't convert the the functional level but there is one in the rootDSE.
And finally the last patch relaxes the requirement for tokenGroups.
According to MSFT documentation, tokenGroups is available since Windows
2000, but the oldest release we have around is 2003, so I only
downgraded the requirement to 2003.
The problem is described in the ticket and commit message. Locking the
ccache is one way to solve the problem. Another way would be to
randomize the ccache name so both processes touches different file.
However, randomizing the name has two problems:
1) if I understand it correctly, it is still a cache so in theory it may
be reused after SSSD is restarted, therefore we need to have a
deterministic name anyway (for example appending $provider to ccache
name but that would require changes in the protocol and sdap code).
2) the ccache name is stored in KRB5CCACHE (or something like that)
environment variable so actually only one ccache may be used. Possible
solution would be to create two files and than keep only one of them.
I think locking the file is a better solution. Besides initial condition
where we perform first periodic tasks (sudo full refresh, subdomain
refresh, possibly enumeration) there should be no collisions where the
process would wait to obtain the lock.
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.