Using sssd, for a long time, I have come across with a problem recently,
which I would like to solve with your help.
I provide centralized authentication and authorization service for a huge
heterogeneous network. And in my case it would be "nice and easy" if sssd
used only shells(5). I believe this mechanism is sufficient for
identification of an allowed shell.
I take a liberty to offer you this tiny patch, which will let use wildcard
(*) in param allowed_shells in sssd.conf
What do you think about it?
please see attached patches.
I have briefly discussed with Jakub how to handle saving users with uid
0 whether to resurrect sysdb_add_fake_user or modify existing fuctions
for storing users. I decided to add wrapper function around existing
ones to minimize changes in code which calls them.
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.
I have been working on sssd being able to flush hosts from it's cache.
Here is an initial patch to add the options to the cli of sss_cache.
I have noticed that there are some methods already in src/db/sysdb_ssh.c
like sysdb_update_ssh_known_host_expire: Does that seem like the right
function to call to expire a host?
Advice is appreciated.
William Brown <william(a)firstyear.id.au>
attached patch is the first of many to solve
"The return codes of various sysdb operations differ. Some search
operations would return ENOENT if they don't find a matching object some
would return EOK but an empty result list."
I think it would be best if in case that no results were found both
ENOENT value and 'properly' empty list were returned.
Thank for opinions or/and review.