RFC: 1.16.4 release notes
by Jakub Hrozek
Hi,
I would like to release 1.16.4 tomorrow. Below are the release notes
that include what is now in the sssd-1-16 branch and somewhat
optimistically also what is now acked on github. Comments are welcome:
SSSD 1.16.4
===========
Highlights
----------
New Features
^^^^^^^^^^^^
* The list of PAM services which are allowed to authenticate using a
Smart Card is now configurable using a new option
``pam_p11_allowed_services``.
* A new configuration option ``ad_gpo_implicit_deny`` was added. This option
(when set to True) can be used to deny access to users even if there is
not applicable GPO. Normally users are allowed access in this situation.
(#3701)
* The LDAP authentication provider now allows to use a different method of
changing LDAP passwords using a modify operation in addition to the
default extended operation. This is meant to support old LDAP servers
that do not implement the extended operation. The password change using
the modification operation can be selected with ``ldap_pwmodify_mode =
"ldap_modify"`` (#1314)
Security issues fixed
^^^^^^^^^^^^^^^^^^^^^
* CVE-2019-3811: SSSD used to return "/" in case a user entry had no home
directory. This was deemed a security issue because this flaw could
impact services that restrict the user's filesystem access to within
their home directory. An empty home directory field would indicate
"no filesystem access", where sssd reporting it as "/" would grant full
access (though still confined by unix permissions, SELinux etc).
Notable bug fixes
^^^^^^^^^^^^^^^^^
* The IPA provider, in a setup with a trusted Active Directory domain,
did not remove cached entries that were no longer present on
the AD side (#3984)
* The Active Directory provider now fetches the user information from the
LDAP port and switches to using the Global Catalog port, if available
for the group membership. This fixes an issue where some attributes
which are not available in the Global Catalog, typically the home
directory, would be removed from the user entry. (#2474)
* The IPA SELinux provider now sets the user login context even if it is the
same as the system default. This is important in case the user has
a non-standard home directory, because then only adding the user to
the SELinux database ensures the home directory will be labeled properly.
However, this fix causes a performance hit during the first login
as the context must be written into the semanage database.
* The sudo responder did not reflect the case_sensitive domain option
(#3820)
* A memory leak when requesting netgroups repeatedly was fixed (#3870)
* An issue that caused SSSD to sometimes switch to offline mode in case
not all domains in the forest ran the Global Catalog service was
fixed (#3902)
* The SSH responder no longer fails completely if the ``p11_child`` times out
when deriving SSH keys from a certificate (#3937)
* The negative cache was not reloaded after new sub domains were discovered which
could have lead to a high SSSD load (#3683)
* The negative cache did not work properly for in case a lookup fell back to trying
a UPN instead of a name (#3978)
* If any of the SSSD responders was too busy, that responder wouldn't have
refreshed the trusted domain list (#3967)
* A potential crash due to a race condition between the fail over code refreshing
a SRV lookup and back end using its results (#3976)
* Sudo's runAsUser and runAsGroup attributes did not match properly when used in
setups with domain_resolution_order
Tickets Fixed
-------------
* `3967 <https://pagure.io/SSSD/sssd/issue/3967>`_ - NSS responder does no refresh domain list when busy
* `2926 <https://pagure.io/SSSD/sssd/issue/2926>`_ - Make list of local PAM services allowed for Smartcard authentication configurable
* `3819 <https://pagure.io/SSSD/sssd/issue/3819>`_ - sssd only sets the SELinux login context if it differs from the default
* `3820 <https://pagure.io/SSSD/sssd/issue/3820>`_ - sudo: search with lower cased name for case insensitive domains
* `3870 <https://pagure.io/SSSD/sssd/issue/3870>`_ - nss: memory leak in netgroups
* `3451 <https://pagure.io/SSSD/sssd/issue/3451>`_ - When sssd is configured with id_provider proxy and auth_provider ldap, login fails if the LDAP server is not allowing anonymous binds.
* `3875 <https://pagure.io/SSSD/sssd/issue/3875>`_ - CURLE_SSL_CACERT is deprecated in recent curl versions
* `3902 <https://pagure.io/SSSD/sssd/issue/3902>`_ - SSSD must be cleared/restarted periodically in order to retrieve AD users through IPA Trust
* `3901 <https://pagure.io/SSSD/sssd/issue/3901>`_ - sssd returns '/' for emtpy home directories
* `3919 <https://pagure.io/SSSD/sssd/issue/3919>`_ - sss_cache prints spurious error messages when invoked from shadow-utils on package install
* `3845 <https://pagure.io/SSSD/sssd/issue/3845>`_ - The config file validator says that certmap options are not allowed
* `3937 <https://pagure.io/SSSD/sssd/issue/3937>`_ - If p11_child spawned from sssd_ssh times out, sssd_ssh fails completely
* `3961 <https://pagure.io/SSSD/sssd/issue/3961>`_ - sssd config-check reports an error for a valid configuration option
* `3701 <https://pagure.io/SSSD/sssd/issue/3701>`_ - [RFE] Allow changing default behavior of SSSD from an allow-any default to a deny-any default when it can't find any GPOs to apply to a user login.
* `2474 <https://pagure.io/SSSD/sssd/issue/2474>`_ - AD: do not override existing home-dir or shell if they are not available in the global catalog
* `3958 <https://pagure.io/SSSD/sssd/issue/3958>`_ - sssd_krb5_locator_plugin introduces delay in cifs.upcall krb5 calls
* `3890 <https://pagure.io/SSSD/sssd/issue/3890>`_ - SSSD changes the memory cache file ownership away from the SSSD user when running as root
* `3942 <https://pagure.io/SSSD/sssd/issue/3942>`_ - RemovedInPytest4Warning: Fixture "passwd_ops_setup" called directly
* `3276 <https://pagure.io/SSSD/sssd/issue/3276>`_ - Revert workaround in CI for bug in python-{request,urllib3}
* `3978 <https://pagure.io/SSSD/sssd/issue/3978>`_ - UPN negative cache does not use values from 'filter_users' config option
* `3983 <https://pagure.io/SSSD/sssd/issue/3983>`_ - filter_users option is not applied to sub-domains if SSSD starts offline
* `3947 <https://pagure.io/SSSD/sssd/issue/3947>`_ - SSSD netgroups do not honor entry_cache_nowait_percentage
* `3984 <https://pagure.io/SSSD/sssd/issue/3984>`_ - IPA: Deleted user from trusted domain is not removed properly from the cache on IPA clients
* `3976 <https://pagure.io/SSSD/sssd/issue/3976>`_ - crash in dp_failover_active_server
* `3957 <https://pagure.io/SSSD/sssd/issue/3957>`_ - sudo: runAsUser/Group does not work with domain_resolution_order
* `1314 <https://pagure.io/SSSD/sssd/issue/1314>`_ - RFE Request for allowing password changes using SSSD in DS which dont follow OID's from RFC 3062
5 years, 1 month
[sssd PR#760][opened] Add use_2fa_combined option to allow pam services to be configured as password+otp entry
by driskell
URL: https://github.com/SSSD/sssd/pull/760
Author: driskell
Title: #760: Add use_2fa_combined option to allow pam services to be configured as password+otp entry
Action: opened
PR body:
"""
Hello,
This is a rough idea and does build successfully but I'm still in the process of getting some testing arranged - I was pulled away from testing unfortunately but wanted to put the idea forward for examination in advance.
I had been trying to get a service to use PAM with 2FA within a FreeIPA environment. However, I was having issues with it refusing to accept a password+otp entry as the single password entered. Having examined the logs it appeared that the 2FA token was being rejected as being incorrect. This confused me as SSHD was working fine and seemed to be configured identically. Looking at the code of the service I could see it was because it was responding to all PAM prompts with the same entered value - the password+otp combination - but was receiving two prompts. Checking SSSD I found the issue in that this behaviour is only allowed for SSHD service, and that the service name was hard-coded in.
This PR adds a new option to pam_sssd, `use_2fa_combined` which allows any service to be configured to behave like `sshd` does, without breaking any compatibility with existing usage.
Does this look like something that would be an acceptable feature to implement, assuming I finish testing and the overall idea works 👍
Thanks!
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/760/head:pr760
git checkout pr760
5 years, 1 month
PRs and tickets for backports
by Jakub Hrozek
Hi,
I was thinking about $SUBJECT and had a chat with Alexey about backports
recently as well.
Mostly I'm wondering whether it would be better to do either or both of:
- create separate PRs for backports to sssd-1-16
- create separate tickets (clones)
With PRs, it's mostly a matter of automatically running CI to avoid
things like https://pagure.io/SSSD/sssd/issue/3986 where I only ran make
and make check during the backport. Of course, we would have to fix our
PR CI first :-)
With tickets, it's mostly about upstream milestones and release notes.
Currently I file all tickets to the "newest" milestone, so currently
2.2. Otherwise, if we filed the ticket into the 'oldest milestone where
the bug is fixed', then when newest the milestone is released, we wouldn't
know exactly which tickets were fixed there. But when the stable release
goes out, we have the same problem, just in reverse. It's slightly better
this way, because the stable release fixes fewer issues, so I just generate
the release notes from the commit messages.
Of course, the downside to both is even more paperwork. With PRs, I
think it's not so bad, we could even have the PR opened and merged by
the same person, just on the grounds of CI passing. But with tickets, it
might get messy..
Thoughts? I would personally be OK with the PRs, but I'm unsure about
the tickets.
5 years, 1 month
[sssd PR#742][opened] netgroups: honor cache_refresh_percent
by pbrezina
URL: https://github.com/SSSD/sssd/pull/742
Author: pbrezina
Title: #742: netgroups: honor cache_refresh_percent
Action: opened
PR body:
"""
The value of cache refresh percent was not passed to cache_req.
Steps to reproduce:
1. Configure SSSD like so:
```ini
[nss]
entry_cache_nowait_percentage=10
memcache_timeout=0
[domain/mydomain]
entry_cache_timeout = 30
```
2. Run SSSD
3. Fetch netgroup for the first time
4. Wait 15 seconds (midpoint refresh will be triggered from 10-29 seconds interval)
5. Fetch netgroup again, see in logs that midpoint refresh was triggered
Resolves:
https://pagure.io/SSSD/sssd/issue/3947
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/742/head:pr742
git checkout pr742
5 years, 1 month
[sssd PR#776][opened] NEGCACHE: repopulate negative cache after get_domains and initialize UPN negative cache as well
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/776
Author: sumit-bose
Title: #776: NEGCACHE: repopulate negative cache after get_domains and initialize UPN negative cache as well
Action: opened
PR body:
"""
If SSSD starts offline the responders might only know about the configured
domain because the sub-domains have not been discovered yet. As a result
the permanent negative cache is only populated for the configured domain.
If later the system goes online and the sub-domains are discovered or a new
sub-domain was discovered at runtime the permanent negative cache is
currently not created for those domains.
This patch repopulates the negative cache for all known domains to the end
of the get_domains request.
Related to https://pagure.io/SSSD/sssd/issue/3983
UPNs are handled separately in the negative cache. To properly filter user
names even in the case of the fallback to a UPN lookup the negative cahe
for UPNs has to be initialized with the names from the filter_user option
as well.
If the name from the option is a short name it will be added to the
negative UPN cache for each domain with the respective domain name. If the
name from the option is fully-qualified it will be added as is to the
negative UPN cache for each domain.
Related to https://pagure.io/SSSD/sssd/issue/3978
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/776/head:pr776
git checkout pr776
5 years, 1 month
Design document: Multiple server addresses or names in kdcinfo files
by Jakub Hrozek
Hi,
I opened a pull request for the upcoming changes ot the locator plugin
which enables a sort of a failover for libkrb5 applications.
The PR is here:
https://pagure.io/SSSD/docs/pull-request/78
the full text is also copied below for your convenience.
If/when we agree on the design, tickets should be opened, because
currently we only have a RHBZ tickets which are linked to the closed
ticket https://pagure.io/SSSD/sssd/issue/941
Multiple server addresses or names in kdcinfo files
===================================================
Related ticket(s):
------------------
* TBD
Problem statement
-----------------
When a user authenticates using Kerberos, the KDCs that will actually be
used are either discovered by libkrb5 with the help of DNS SRV records,
or the KDCs are configured explicitly in ``/etc/krb5.conf.`` or provided
by a special `locator plugin`.
Because the administrator expects that the servers they defined in
``sssd.conf`` would be used for both authentication through SSSD and by
applications that use libkrb5, such the Kerberos command line tools like
``kinit``, SSSD provides a locator plugin for libkrb5 that allows SSSD to
inform libkrb5 about the servers SSSD had configured.
However, SSSD, at least in the typical use case, only writes the information
about the single server it connects to and changes the address only when
the daemon reconnects to a different server. This creates a problem in case
the server whose address is written in the kdcinfo file is unreachable
but no action towards sssd that would provoke a fail over (such as a
user login over PAM) is executed. In that case, the kdcinfo file contains
stale entries and because from libkrb5 point of view, the kdcinfo files
are authoritative and if the information present there is not useful,
libkrb5 cannot reach any KDCs from that domain.
To improve the situation, this design page proposes adding a new sssd option
that, if set, would enable sssd to write additional host names into the
kdcinfo files which would then allow the plugin to iterate over these
items and in turn allow libkrb5 to have sort of a failover for entries
configured in sssd.conf or autodiscovered by SSSD.
Use cases
---------
A typical sequence that triggers this problem is this:
* log in with a PAM service to a machine. This causes a KDC address to
be written to the kdcinfo file
* disable the KDC server, e.g. by enabling a restrictive firewall rule
* call kinit on the client where the kdcinfo file was written
Overview of the solution
------------------------
The Kerberos locator plugin reads the address(es) from per-realm text files
written by SSSD located in the ``/var/lib/sss/pubconf`` directory. At the
moment, the plugin can already read multiple entries, but currently only
numerical addresses are supported.
On a high level, implementing this RFE requires several changes:
* change the Kerberos locator plugin so that it can also consume
host names in addition to numerical addresses. These host names
would be resolved in the plugin itself and passed to libkrb5 with
the help of a callback function libkrb5 provides to the plugin
* add a new SSSD option that would limit the number of entries that
SSSD writes to the kdcinfo plugin. This is needed to avoid time
outs in case the network was truly unreachable. The default value
of the option could perhaps be different in master and sssd-1-16
where master could default to writing multiple entries, but
sssd-1-16 would default the option to 0 in order to not change
behaviour of a stable branch.
* extend the online callback which the SSSD fail over component uses
to write the current server to the kdcinfo files to also write
additional server host names in addition to the current server address
* to enable writing multiple server addresses, the request to resolve
a server for a service should be extended to resolve host names
up to the specified limit
When it comes to resolving the servers, there are several scenarios to
consider:
* The servers can be enumerated using an option. This includes
``krb5_server/krb5_backup_server`` for the krb5 provider and
``ipa_server/ipa_backup_server`` and ``ad_server/ad_backup_server``
for the IPA and AD providers.
* The servers can be completely autodiscovered. Typically this is
done by either omitting the ``*_server`` options completely or
using the ``_srv_`` identifier. As long as the list is omitted
or the ``_srv_`` record is the first one in the list, any fail
over service resolution would trigger the DNS SRV lookups and
resolve the whole list. It is useful to note that the ``_srv_``
identifier is not permitted in the backup server list explicitly,
but the AD provider does resolve a SRV query into the backup
server list. That is done in case an AD site is used, then the servers
from the AD site are added as 'primary' and the global servers
form the 'backup' list.
* A mix of the above. The most complex case from the point of
this RFE is a list that starts with a host name, but includes
the ``_srv_`` identifier later on, e.g. ``krb5_server = kdc.example.com,
_srv_``. In this case, currently calling the fail over resolution
would only resolve the host name of ``kdc.example.com``, but not
the SRV query, so unless the fail over code is extended, the
host names originating from the SRV query would not be known
after the service resolution finishes.
Implementation details
----------------------
The interface the locator plugin uses to communicate with libkrb5 is a
callback function provided by the caller (libkrb5), SSSD is supposed
to pass a struct sockaddr to the caller. The Kerberos locator plugin
is already capable of iterating over multiple addresses, but currently
really only numerical addresses are supported and the plugin converts
the string representation of the address into struct sockaddr by calling
``getaddrinfo(3)`` with the ``AI_NUMERICHOST`` parameter. We should extend
the locator plugin code by calling getaddrinfo for entries that do not
represent an address to resolve a host name and pass its address. This
can be a first self-contained step in the implementation.
The kdcinfo files are written (using ``write_krb5info_file``) either
during an online callback or in a special-case for IPA trust clients. The
special case is already doing something similar to what this page
is about by looking into a subsection representing a trusted domain
(e.g. ``[domain/ipa.test/win.trust.test]``) and resolving all the servers
in that list either by name or based on a site selection. However, this
is done during the subdomain provider operation, not during a resolver
callback and all the addresses configured in the ``sssd.conf`` file are
always resolved and written to the config file.
The ``write_krb5info_file`` receives a linked list of ``struct fo_server``
structures which contains the address, if already resolved, or at least
a host name in the ``struct server_common`` member structure. Since the
callback should already be synchronous and not do much work on its own, it
would be best if the callback was already invoked with the data provided,
There are two kinds of servers in the fail over module - primary and
backup. The backup servers are supposed to only be used temporarily
and sssd periodically tries to connect to one of the primary servers.
However, from the fail over code point of view, even adding a "backup"
server still means the server is added to the same linked list, just with
a flag denoting that the server is not primary, therfore iterating over
a single list would iterate over both the primary and backup servers.
Before changing the online callbacks, it would be useful to implement and
read the ``krb5_kdcinfo_lookahead`` option so that there is already an
upper limit when the callbacks write the extra host names.
The next step of implementation could be extending the online
callbacks that call the ``write_krb5info_file`` functions. There are
several of them, ``ad_resolve_callback``, ``ipa_resolve_callback``
and ``krb5_resolve_callback``. The callbacks receive the current
``struct fo_server`` instance. The callbacks would then keep iterating
over the linked list until either the list is exhausted or as many as
``krb5_kdcinfo_lookahead`` items are processed. The host name from the
``struct server_common`` structure would be read using ``fo_get_server_name``
and written to the array passed to ``write_krb5info_file``.
One question to consider is whether to use the ``fo_server`` instances before
the current one, i.e. those that SSSD tried before and couldn't connect to.
I think it would make sense to add them to the end of the list, at least
for the primary servers not from a SRV query, because sssd never reconnects
to a server earlier in the list as long as later server works. The SRV queries
are different in this respect in the sense that they time out and force
SSSD to resolve the whole list once a server is requested again (typically
either during authentication or once the LDAP connection expires).
Finally, the case where the fail over code needs to do additional lookups
in order to resolve at least the amount of host names requested by the
``krb5_kdcinfo_lookahead`` should be addressed. The caller that initializes
the fail over service (maybe with ``be_fo_add_service``) should provide
a hint with the value of the lookahead option. Then, if a request for
server resolution is triggered, the fail over code would resolve a server
and afterwards check if enough ``fo_server`` entries with a valid hostname
in the ``struct server_common`` structure. If not, the request would
check if any of the ``fo_server`` structures represents a SRV query and
try to resolve the query to receive more host names.
Configuration changes
---------------------
A new configuration option called ``krb5_kdcinfo_lookahead`` would be added.
This option would default to a sensible non-zero value in the master
branch, perhaps 3 so that attempting to resolve the extra host names does
not cause the libkrb5 operation to time out. If the patches are backported
to any stable branch, the option must default to 0 (disabled).
In the first iteration, we might want to just read a single number, but
in the future, the option should be extended to accept two numbers in the
``total:backup`` notation. This would mean write up to ``total`` servers,
but include up to ``backup`` servers from the backup list. This would be
useful in case none of the servers from the primary list are reachable,
because e.g. they all come from the same AD site, but servers outside the
site are reachable. This extension would only make sense if SSSD does not
resolve the host names on its own, which might be another future extension.
It might be a good idea to add a note to the ``sssd-ad`` and ``sssd-ipa``
man pages or even the shared fail over man page include file with a pointer
to how the kdcinfo files work so that the information is easy to discover
for administrators.
How To Test
-----------
Plugin test
With any of the below tests or even after writing the host names to
the kdcinfo files directly, make sure the first entry in the list is
unreachable. Then call e.g. `kinit` and check that the operation succeeds.
Backwards compatibility test
Set the ``krb5_kdcinfo_lookahead`` option to 0. Define multiple servers
and perform Kerberos authentication. Make sure that only the current server
is written to the kdcinfo files.
Write a list of servers
Set the ``krb5_resolve_callback`` to a positive value. Make sure that the
first entry in the kdcinfo files is an address and the other entries are
host names from the configuration. This test case should be extended to
make sure only so many entries as the value of the option are written,
or if there are fewer entries in the config file, all are writen.
Fail over test
Similar to the above, except make sure the first entry in the list cannot
be contacted. Then, SSSD should resolve the next entry to the address
and if applicable write the rest of the list.
Backup server test
At the minimum, we should make sure that servers from the backup list
are written to the kdcinfo files. If the option would implement the split
``total:backup`` value, then those should be tested as well.
(Optional) writing a previously tried, not working server
If it is agreed during design review that also not working servers are to
be written to the kdcinfo files (see the section about not working
servers), then a test case should make sure those
are written to the end of the list.
SRV resolution test
Leave the server list (e.g. ``krb5_server``) option empty. Make sure
a DNS SRV query for the configured realm returns valid servers and
they are written to the config file.
Combined SRV and server list
Set the ``krb5_server`` option to ``hostname, _srv_``. Set the
``krb5_kdcinfo_lookahead`` option to a value greater than 1. Make
sure that the host names from the DNS SRV query are also present
in the kdcinfo files.
IPA client test
The test cases above should be repeated for an IPA client as well in
case the IPA online callbacks are modified.
AD site test
Add an AD client to a site or set the site in the config file. Make
sure that the servers from the site are written first, followed
by the global servers up to the ``krb5_kdcinfo_lookahead`` value.
How To Debug
------------
Any new code must be decorated with DEBUG messages. To debug the locator
plugin changes, using ``KRB5_TRACE`` or even calling ``strace`` might be
useful.
Future development
------------------
First, it might be useful to extend the resolver or fail over code to resolve
the names on its own to save some potentially blocking calls in the plugin.
There is already an example of ``resolv_hostport_list_send`` that can perhaps
be reused.
Additionally, we already plan for some time to include connectivity checks
with cLDAP ping or just plain ``connect()`` to make sure that servers that
cannot be contacted at all are not tried. This is of course outside of the
scope of this work, but should be kept in mind to not implement something
incompatible.
Authors
-------
* Sumit Bose <sbose(a)redhat.com>
* Tomas Halman <thalman(a)redhat.com>
* Jakub Hrozek <jhrozek(a)redhat.com>
5 years, 1 month