sssd.git/src/confdb, branch tlog Unnamed repository; edit this file 'description' to name the repository. CONFIG: Add session_recording section 2017-04-20T08:23:23+00:00 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 2016-12-20T08:16:47+00:00 bc50e85d2c45bd45eb942f10b0e21848fc70897c Add information on "session_recording" config section, having three options: "scope", "users", and "groups". The section is intended for disabling session recording ("scope = none", default), enabling session recording for all users ("scope = all"), and enabling it for some specific users and/or groups ("scope = some", "users = <users>", "groups = <groups>"). 
Add information on "session_recording" config section, having three
options: "scope", "users", and "groups".

The section is intended for disabling session recording ("scope = none",
default), enabling session recording for all users ("scope = all"), and
enabling it for some specific users and/or groups ("scope = some",
"users = <users>", "groups = <groups>").
CONFDB: Fix handling of enable_files_domain 2017-04-10T12:44:00+00:00 Lukas Slebodnik lslebodn@redhat.com 2017-04-05T12:04:46+00:00 3509bb03ecef49264820c9e287e8b2c7e0a8a508 The option enable_files_domain worked only if sssd was compiled with --enable-files-domain. But manual page described something else. Resolves: https://pagure.io/SSSD/sssd/issue/3340 Reviewed-by: Michal Židek <mzidek@redhat.com> 
The option enable_files_domain worked only if sssd
was compiled with --enable-files-domain. But manual page described
something else.

Resolves:
https://pagure.io/SSSD/sssd/issue/3340

Reviewed-by: Michal Židek <mzidek@redhat.com>
PAM: Add application services 2017-03-30T12:09:52+00:00 Jakub Hrozek jhrozek@redhat.com 2017-03-26T16:28:41+00:00 3e789aa0bd6b7bb6e62f91458b76753498030fb5 Related to: https://pagure.io/SSSD/sssd/issue/3310 Adds a new PAM responder option 'pam_app_services'. This option can hold a list of PAM services that are allowed to contact the application non-POSIX domains. These services are NOT allowed to contact any of the POSIX domains. Reviewed-by: Sumit Bose <sbose@redhat.com> 
Related to:
https://pagure.io/SSSD/sssd/issue/3310

Adds a new PAM responder option 'pam_app_services'. This option can hold
a list of PAM services that are allowed to contact the application
non-POSIX domains. These services are NOT allowed to contact any of the
POSIX domains.

Reviewed-by: Sumit Bose <sbose@redhat.com>
CONFDB: Allow configuring [application] sections as non-POSIX domains 2017-03-30T12:09:10+00:00 Jakub Hrozek jhrozek@redhat.com 2017-03-27T07:48:46+00:00 825e8bf2f73a815c2eceb36ae805145fcbacf74d Related to: https://pagure.io/SSSD/sssd/issue/3310 Allows to add a new section: [application/$name] This section internally (on the confdb level) expands to: [domain/$name] domain_type = application The reasons to add this new section is two-fold. One, to make the configuration of application domains more explicit and two, to make it possible to share configuration between two domains, one POSIX and one non-POSIX by application domain's inherit_from option: [application/$name] inherit_from = posix_domain_name Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> 
Related to:
https://pagure.io/SSSD/sssd/issue/3310

Allows to add a new section:
    [application/$name]

This section internally (on the confdb level) expands to:
    [domain/$name]
    domain_type = application

The reasons to add this new section is two-fold. One, to make the
configuration of application domains more explicit and two, to make it
possible to share configuration between two domains, one POSIX and one
non-POSIX by application domain's inherit_from option:
    [application/$name]
    inherit_from = posix_domain_name

Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
CONFDB: Introduce SSSD domain type to distinguish POSIX and application domains 2017-03-30T12:09:02+00:00 Jakub Hrozek jhrozek@redhat.com 2017-03-22T11:53:17+00:00 6324eaf1fb321c41ca9883966118df6d45259b7e Related to: https://pagure.io/SSSD/sssd/issue/3310 Adds a new option that allows to distinguish domains that do contain POSIX users and groups and those that don't. The POSIX domains are the default. The non-POSIX domains are selected by selecting an "application" type domain. Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> 
Related to:
https://pagure.io/SSSD/sssd/issue/3310

Adds a new option that allows to distinguish domains that do contain
POSIX users and groups and those that don't. The POSIX domains are the
default. The non-POSIX domains are selected by selecting an
"application" type domain.

Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Add domain_resolution_order config option 2017-03-29T12:00:17+00:00 Fabiano Fidêncio fidencio@redhat.com 2017-03-26T01:00:14+00:00 16385568547351b5d2c562f3081f35f3341f695b This is the local equivalent of option of ipaDomainResolutionOrder and has precedence over the ones set on IPA side making the precedence order to be like: Local > View > Globally. As done for the IPA side configurations, the domains which were not explicitly set up will be apennded to the final of the domain_resolution_order list in the very same order they're presented in the "domains" option of [sssd] section in the config file. There's no guarantee of order for the subdomains though. It's also important to mention that no expansion magic is performed on our side. It means that if 'example.com' is set it does *not* stand for all its subdomains DNS wise (like 'foo.example.com', 'bar.example.com', etc). Related: https://pagure.io/SSSD/sssd/issue/3001 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> 
This is the local equivalent of option of ipaDomainResolutionOrder and
has precedence over the ones set on IPA side making the precedence order
to be like: Local > View > Globally.

As done for the IPA side configurations, the domains which were not
explicitly set up will be apennded to the final of the
domain_resolution_order list in the very same order they're presented in
the "domains" option of [sssd] section in the config file. There's no
guarantee of order for the subdomains though.

It's also important to mention that no expansion magic is performed on
our side. It means that if 'example.com' is set it does *not* stand for
all its subdomains DNS wise (like 'foo.example.com', 'bar.example.com',
etc).

Related:
https://pagure.io/SSSD/sssd/issue/3001

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>

Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
KCM: Make the secrets ccache back end configurable, make secrets the default 2017-03-27T07:58:55+00:00 Jakub Hrozek jhrozek@redhat.com 2017-03-14T10:17:05+00:00 35c9dfe9ba78d3a635cd1af0fb6349ba44344623 Adds a new option 'ccache_storage' that allows to select either the memory back end or the secrets back end. The secrets back end is the default one and this option is even undocumented. Reviewed-by: Michal Židek <mzidek@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> 
Adds a new option 'ccache_storage' that allows to select either the
memory back end or the secrets back end. The secrets back end is the
default one and this option is even undocumented.

Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
KCM: Initial responder build and packaging 2017-03-27T07:56:19+00:00 Jakub Hrozek jhrozek@redhat.com 2016-08-01T10:52:07+00:00 b9c563c29243291f40489bb0dcbf3946fca72d58 Adds the initial build of the Kerberos Cache Manager responder (KCM). This is a deamon that is capable of holding and storing Kerberos ccaches. When KCM is used, the kerberos libraries (invoked through e.g. kinit) are referred to as a 'client' and the KCM deamon is referred to as 'server'. At the moment, only the Heimdal implementation of Kerberos implements the KCM server: https://www.h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html This patch adds a KCM server to SSSD. In MIT, only the 'client-side' support was added: http://k5wiki.kerberos.org/wiki/Projects/KCM_client This page also describes the protocol between the client and the server. The client is capable of talking to the server over either UNIX sockets (Linux, most Unixes) or Mach RPC (macOS). Our server only implements the UNIX sockets way and should be socket-activated by systemd, although can in theory be also ran explicitly. The KCM server only builds if the configuration option "--with-kcm" is enabled. It is packaged in a new subpackage sssd-kcm in order to allow distributions to enable the KCM credential caches by installing this subpackage only, without the rest of the SSSD. The sssd-kcm subpackage also includes a krb5.conf.d snippet that allows the admin to just uncomment the KCM defaults and instructs them to start the socket. The server can be configured in sssd.conf in the "[kcm]" section. By default, the server only listens on the same socket path the Heimdal server uses, which is "/var/run/.heim_org.h5l.kcm-socket". This is, however, configurable. The file src/responder/kcm/kcm.h is more or less directly imported from the MIT Kerberos tree, with an additional sentinel code and some comments. Not all KCM operations are implemented, only those that also the MIT client implements. That said, this KCM server should also be usable with a Heimdal client, although no special testing was with this hybrid. The patch also adds several error codes that will be used in later patches. Related to: https://pagure.io/SSSD/sssd/issue/2887 Reviewed-by: Michal Židek <mzidek@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> 
Adds the initial build of the Kerberos Cache Manager responder (KCM).

This is a deamon that is capable of holding and storing Kerberos
ccaches. When KCM is used, the kerberos libraries (invoked through e.g.
kinit) are referred to as a 'client' and the KCM deamon is referred to
as 'server'.

At the moment, only the Heimdal implementation of Kerberos implements the
KCM server:
    https://www.h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html
This patch adds a KCM server to SSSD.

In MIT, only the 'client-side' support was added:
    http://k5wiki.kerberos.org/wiki/Projects/KCM_client
This page also describes the protocol between the client and the server.

The client is capable of talking to the server over either UNIX sockets
(Linux, most Unixes) or Mach RPC (macOS). Our server only implements the
UNIX sockets way and should be socket-activated by systemd, although can
in theory be also ran explicitly.

The KCM server only builds if the configuration option "--with-kcm" is
enabled. It is packaged in a new subpackage sssd-kcm in order to allow
distributions to enable the KCM credential caches by installing this
subpackage only, without the rest of the SSSD. The sssd-kcm subpackage
also includes a krb5.conf.d snippet that allows the admin to just uncomment
the KCM defaults and instructs them to start the socket.

The server can be configured in sssd.conf in the "[kcm]" section.
By default, the server only listens on the same socket path the Heimdal
server uses, which is "/var/run/.heim_org.h5l.kcm-socket". This is,
however, configurable.

The file src/responder/kcm/kcm.h is more or less directly imported from
the MIT Kerberos tree, with an additional sentinel code and some
comments. Not all KCM operations are implemented, only those that also
the MIT client implements. That said, this KCM server should also be
usable with a Heimdal client, although no special testing was with this
hybrid.

The patch also adds several error codes that will be used in later
patches.

Related to:
    https://pagure.io/SSSD/sssd/issue/2887

Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
CACHE_REQ: Check the caches first 2017-03-14T11:35:01+00:00 Fabiano Fidêncio fidencio@redhat.com 2017-02-22T07:07:45+00:00 8bb6680637ead03e24a38d15ec5265d11a920a1d This patch introduces a new configurable option to define whether the responder should query all domains' caches before querying the Data Providers. This new option is called cache_first and, by default, it's disabled, meaning that, for each provider, the responder may contact the cache and the data provider in the same iteration. Co-Author: Pavel Březina <pbrezina@redhat.com> Related: https://pagure.io/SSSD/sssd/issue/3001 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> 
This patch introduces a new configurable option to define whether the
responder should query all domains' caches before querying the Data
Providers.

This new option is called cache_first and, by default, it's disabled,
meaning that, for each provider, the responder may contact the cache and
the data provider in the same iteration.

Co-Author: Pavel Březina <pbrezina@redhat.com>

Related:
https://pagure.io/SSSD/sssd/issue/3001

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>

Reviewed-by: Pavel Březina <pbrezina@redhat.com>
CONFDB: If no configuration file is provided, create a fallback configuration 2017-02-28T09:37:09+00:00 Jakub Hrozek jhrozek@redhat.com 2017-02-23T11:22:49+00:00 a4837791f62283079e7be4b17efb769be8b2dfd1 This functionality is only enabled in case SSSD is configured with with --enable-files-domain. If not, the behaviour is as it used to -- SSSD returns an error, instructing the admin to create a configuration file. If the option is enabled, a very minimal confdb that only enables the NSS responder is created. The confdb later adds the implicit files domain. Resolves: https://pagure.io/SSSD/sssd/issue/2229 Reviewed-by: Pavel Březina <pbrezina@redhat.com> 
This functionality is only enabled in case SSSD is configured with with
--enable-files-domain. If not, the behaviour is as it used to -- SSSD
returns an error, instructing the admin to create a configuration file.

If the option is enabled, a very minimal confdb that only enables the
NSS responder is created. The confdb later adds the implicit files
domain.

Resolves:
https://pagure.io/SSSD/sssd/issue/2229

Reviewed-by: Pavel Březina <pbrezina@redhat.com>