currently if libwbclient is enabled (and it is enabled be default) 'make
install' might overwrite the already installed Samba version of the
To make this more robust but keep the library enabled by default I would
suggest to add a _sssd suffix to all installed files to avoid
collisions. If an admin want to use the SSSD version instead of the
Samba version the libraries must be replaced manually. Distributions can
you their scheme to handle different implementations of the same binary
during building the packages, e.g. for Fedora and RHEL this would be
All renaming is done in the second patch. The first patch just fixes an
issue during make test when disabling libwbclient and should be applied
even if the second is NACKed.
I have prepared patches for https://fedorahosted.org/sssd/ticket/2343
Patches actually do not work due to same bug which is causing
So my patches are effectively blocked by #2407, for testing purposes
following command may be used (which reverts patches introducing the bug):
git revert 983983dd1629ab33eab340a40d9ee83965a339c6
The attached patches add configuring support (patch 1) and processing support (patch 2) for the gpo_map_* set of options. These options are used to map Linux PAM service names to GPO Logon Rights, which in turn map to specific key/value pairs (one for allow, one for deny) in the GptTmpl.inf file. I'm including my write-up (below) from the Design Page (https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration)
GPO policy settings can be used to centrally configure several sets of Windows Logon Rights, with each set classified by its logon method (e.g. interactive, remote interactive) and consisting of a whitelist [and blacklist] of users and groups that are allowed [or denied] access to the computer using the set's logon method. In order to integrate Windows Logon Rights into a Linux environment, we allow pam service names to be mapped to a specific Logon Right. We provide default mappings for all of the commonly used pam service names, but we also allow the admin to add/remove mappings as needed (to support custom pam service names, for example). The latter is done by using a new set of config options of the form "gpo_map_<logon_right>" (i.e. gpo_map_interactive, gpo_map_network, etc), each of which consists of a comma-separated list of entries beginning either with a '+' (for adding to default set) or a '-' (for removing from default set). For example, since the RemoteInteractive logon right maps to a single pam service name ("sshd") by default, an admin could map their own pam service name ("my_pam_service") and remove the "sshd" mapping with the following sssd.conf line:
"gpo_map_remote_interactive = +my_pam_service, -sshd"
For this project, the following options can be used to configure the corresponding Logon Right (default values are also given):
* ad_gpo_map_interactive (default: login, su, su-l, gdm-fingerprint, gdm-password, gdm-smartcard, kdm)
* ad_gpo_map_remote_interactive (default: sshd)
* ad_gpo_map_network (default: ftp, samba)
* ad_gpo_map_batch (default: crond)
* ad_gpo_map_service (default: <not set>)
* ad_gpo_map_permit (default: sudo, sudo-i)
* ad_gpo_map_deny (default: <not set>)
* ad_gpo_default_right (default: deny)
The first five options are used to associate specific pam service names with each logon right. The ad_gpo_map_permit [and ad_gpo_map_deny] is used to specify pam service names for which GPO-based access is always [or never] granted. Unlike the other options, the ad_gpo_map_default_right does not specify pam service names. Rather, it allows the admin to specify a default logon right (or the special permit/deny values)for pam service names that are not explicitly mapped to any of the logon rights. Note that, in many cases, we do not expect the admin will need to specify any of these config options, b/c the defaults have been chosen carefully to cover the most commonly used pam service names (with deny as the default for unmapped service names).
The semantics of each whitelist and blacklist are as follows:
* whitelist ("allow"): When this policy setting is not defined, any user can logon to the computer. When it is defined, only the users and groups specified in the whitelist are allowed to logon to the computer. In other words, by defining this setting, the semantics go from "everyone allowed access to this computer" to "no one allowed access to this computer, except principals on the whitelist".
* blacklist ("deny"): When this policy setting is not defined, it has no effect. When it is defined, the users and groups specified in the blacklist are blocked from performing logons. For a particular Logon Right (e.g. Interactive), if a user/group is specified in both the whitelist and the blacklist, then the blacklist takes precedence.
In summary, if a user is trying to login to a computer (e.g. pam_service_name = "login"), we first find which Logon Right the "login" service maps to (i.e. Interactive, by default), and then process only the corresponding policy settings found in GptTmpl.inf (which contains policy settings for the "Security Settings" extension, of which Logon Rights are a part). In the case of Interactive Logon Right, those policy settings are named SeInteractiveLogonRight and SeDenyInteractiveLogonRight in the GptTmpl.inf file.
On Thu, Aug 21, 2014 at 03:02:54PM +0100, Ian Lee wrote:
> Yea, that's a nice target to use, I'd not noticed it before. Does this
> now make systemd-user-sessions.service a redundant dependency?
> The patch attached includes both, you can modify as you see fit.
Thank you again for your contribution. One person hit by the bug had
verified that the patch fixes the shutdown problem.
Pushed to master:
attached patch fixes regression introduced by commit:
NSS: Don't use printf(3) on user provided strings.
Fortunatelly, it was not backported into 1-11 branch.
sh$ git tag --contains c86904baad32fbf9e66bf1cdc667aa5e683b48ba
How to reproduce:
a) you need to have 2 AD domains with trust.
b) group from subdomain should contain mixed members (from all 2 domains)
c) have emty sssd cache.
d) getent group subdomain_group_fqname
In my case:
* without this patch:
sh# getent group group2_dom2(a)sssdad_tree.com
* with this patch:
sh# getent group group2_dom2(a)sssdad_tree.com
You can also test with unit test.
a) apply attached patch
b) revert changes in file src/responder/nss/nsssrv_cmd.c
sh$ git checkout HEAD~ src/responder/nss/nsssrv_cmd.c
c) run test
-- nss-srv-tests will fail and will contain error
[ RUN ] test_nss_getgrnam_mix_subdom
0x2 != 0x3
../sssd/src/tests/cmocka/test_nss_srv.c:1429: error: Failure!
[ FAILED ] test_nss_getgrnam_mix_subdom