sssd.git/src/config, branch master

secrets: allow to configure certificate check

2017-03-30T17:08:00+00:00

Some users may want to use TLS with unverified peer (for example if
they use self-signed certificate) or if unverified hostname (if
certificate hostname does not match with the real hostname). On the
other side it may be useful to point to a directory containing custom
certificate authorities.

This patch add three new options to secrets responder:
verify_peer => peer's certificate must be valid
verify_host => hostnames must match
capath => path to directory containing CA certs
cacert => ca certificate
cert => client certificate
key => client private key

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

Reviewed-by: Simo Sorce 
Reviewed-by: Jakub Hrozek

PAM: Add application services

2017-03-30T12:09:52+00:00

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

CONFDB: Allow configuring [application] sections as non-POSIX domains

2017-03-30T12:09:10+00:00

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 
Reviewed-by: Pavel Březina

CONFDB: Introduce SSSD domain type to distinguish POSIX and application domains

2017-03-30T12:09:02+00:00

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 
Reviewed-by: Pavel Březina

Add domain_resolution_order config option

2017-03-29T12:00:17+00:00

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 

Reviewed-by: Sumit Bose 
Reviewed-by: Pavel Březina

SSSDConfig: Python 3.6 invalid escape sequence deprecation fix

2017-03-27T21:30:54+00:00

https://docs.python.org/3/whatsnew/3.6.html#deprecated-python-behavior

Merges: https://pagure.io/SSSD/sssd/pull-request/3346

Reviewed-by: Lukáš Slebodník

KCM: Idle-terminate the responder if the secrets back end is used

2017-03-27T07:59:13+00:00

Existing with memory database would be fatal as we keep the ccaches in
memory then, but if the ccaches are stored in sssd-secrets, we can just
exit on idle.

Reviewed-by: Michal Židek 
Reviewed-by: Simo Sorce

KCM: Make the secrets ccache back end configurable, make secrets the default

2017-03-27T07:58:55+00:00

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 
Reviewed-by: Simo Sorce

KCM: Initial responder build and packaging

2017-03-27T07:56:19+00:00

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 
Reviewed-by: Simo Sorce

CACHE_REQ: Check the caches first

2017-03-14T11:35:01+00:00

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 

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

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Pavel Březina