SSSD is designed to have support for multiple cryptography libraries.
Originally we build in support for both Mozilla NSS and libcrypto.
However, over the last several releases, libcrypto support has fallen by
the wayside and there is now a notable feature disparity between
versions of SSSD built against Mozilla NSS and versions built against
The basic functionality still works (we have support for caching
credentials using a SHA512 algorithm provided by either library), but
some of the more advanced features do not.
1. Support for obfuscated passwords in the sssd.conf requires Mozilla
2. Support for centrally-managed SSH public keys requires a BASE64
encode/decode routine and in 1.8.2 wil add a SHA1 hash routine. There is
no equivalent available in libcrypto at this time.
Going forward, the core upstream for SSSD (all of whom run on Fedora and
RHEL systems which have been consolidated on Mozilla NSS for some time)
is planning to formally drop support for libcrypto. However, we're
certainly willing to continue supporting it if someone else is willing
to own the maintenance on it. Thus, I am CCing the maintainers of SSSD
in non-Fedora/RHEL distributions that I know of. If anyone here is
relying on libcrypto support and is willing to take over its
maintenance, please speak up.
(*) I consider this a misfeature imposed upon us by incompetent
auditors, but it's still a checkbox on someone's list.
Wondering about whether this feature exists or is planned to exist? It is for use in a shared administration environment. We have central administration and local administrators. It would allow a central configuration for sssd with local changes. Puppet could manage the central main file and include a user managed portion. We handle sudoers in a similar way. I guess the main use of this might be to allow local admins to control who can login to a server. sssd.conf could include something like this:
access_provider = simple
simple_allow_groups = central_admins
and the included locally managed file could have
simple_allow_users = user01, user03, user42
I know we can do this in other ways with puppet, but this would be simpler and it seems to me an include feature might have other uses.
>From [PATCH 0/0] A shared memory cache to perform better:
0/4: Actual memory cache implementation
These is the bulk of the work, these patches are still a bit rough at
the edges, grep for FIXMEs and TODOs and you'll see some plumbing (for
example configure options in sssd to set expiration time and cache sizes
are missing and are still harcoded).
Simo Sorce * Red Hat, Inc * New York
Should we make it a default option?
It seems like in most cases it helps a lot.
--- Comment #41 from Bojan Smojver <bojan(a)rexursive.com> 2012-03-18 00:50:01 EDT ---
(In reply to comment #38)
> One thing you might try is setting 'ldap_referrals = false'.
Bingo! 1.6 secs with cache blown away, 0.16 secs with cache. Only about two
orders of magnitude faster. :-)
Thank you. Much appreciated!
Previously, we were saving both the lower-cased alias names as well as
the original capitalization. This was done in order to allow switching
case-sensitive/insensitive modes safely, but it had the negative effect
of producing duplicate alias entries (differing only by case) on maps
like 'services' which have an 'aliases' field.
Jakub and I discussed it and we agreed that switching case-sensitivity
should always warrant a cache-purge, as it's a fundamental change to the