On my dual-stack network where some machines actually don't have IPv4
connectivity I am finding that whatever is writing IP addresses into
/var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses
and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I
remove that file. It ends up being recreated at some subsequent point
again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
I work in an enterprise environment which has both Linux and Windows systems and an Active Directory for identity.
For good reasons we need to move from Linux based file servers to a NAS. The problem is that all our Linux systems use the SSD ID mapping algorithm to calculate UID and GIDs (and it works great!). We've not found a commercial NAS vendor who supports this algorithm so we can't just drop their products in place.
Do you know of any who do please?
Surely there must be some as many NASs run on Linux and BSD and use open source software heavily.
My colleague asked this in a GitHub issue  but I thought that it might be best to ask here.
Thanks in advance!
In a small business solution, I'd like to setup a road warrior solution like so:
Step #1: User logs in to their ubuntu laptop. SSSD is configured to authenticate the user against LDAP but is not yet connected to the VPN. Works with cached credentials. Password cache is set to 10 days.
Step #2: User starts VPN client and they then have access to company resources such as LDAP. Works.
Step #3: SSSD updates the cached password as soon as LDAP is available. Cache timeout shall reset to the full 10 days once the user (and their laptop) is on the VPN.
With this setup, it should be enforced that the user needs to login to the VPN at least every 10 days.
I've got a problem with step #3: How can I force SSSD to renew the cached password of the user as soon as the LDAP server becomes available? (As mentioned, the VPN connection is activated *after* the user logs in.)
Thanks for every hint or stories war stories on how to treat workstations with temporary connection to the auth backend.
Client OS: Ubuntu 20.04 (soon 22.04)
I haven't started using sssd yet, but am excited to do so.
I have a bunch of Debian clients that I'd like to use/test against an AD
I'm assuming other folks have done such configurations. I'm afraid I don't
know exactly which packages I'll need to install to have sss(d) perform the
nsswitch'ing. I've read that sssd has a local cache in case the connection
to the LDAP directory fails.
Can anyone point me in the right direction regarding what packages I'll
need or perhaps a HOWTO document on the internet? I've seen a few
Redhat/Fedora docs - which I can translate/interpret for Debian as needed,
but was wondering if there was a somewhat condensed version for simply
setting up a (Debian) client.
Thanks for any pointers and for helping out a newcomer.
# SSSD 2.7.0
The SSSD team is proud to announce the release of version 2.7.0 of the
System Security Services Daemon. The tarball can be downloaded from:
See the full release notes at:
RPM packages will be made available for Fedora shortly.
## New pgp key
So far we have been signing each release with our personal keys.
Starting from this release (including) we have switched to the new
project key that is used to sign our release tarball.
- Key ID: C13CD07FFB2DB1408E457A3CD3D21B2910CF6759
- URL: https://github.com/SSSD/sssd/blob/2.7.0/contrib/pubkey.asc
- Keyserver: keys.openpgp.org
## Changes release process
We have switched to a more aggressive release process since the release
of 2.0, where we were trying to publish new features even on every .z
release. From now on, we want to switch the process again to prioritize
stabilization of each released version. Therefore .z releases will
rather focus more on publishing bug fixes and will receive none or only
very few carefully selected new features.
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
### New features
* Added a new krb5 plugin `idp` and a new binary `oidc_child` which
performs **OAuth2** authentication against FreeIPA. This, however, can
not be tested yet because this feature is still under development on
the FreeIPA server side. Nevertheless, we have decided to include this
in the release in order to enable the functionality on the clients
immediately when the FreeIPA project delivers this feature without the
need to update the clients.
### General information
* Better default for IPA/AD re_expression. Tunning for group names
containing '@' is no longer needed.
* A warning is added in the logs if an LDAP operation needs more than
80% of the configured timeout.
* A new debug level is added to show statistical and performance data.
Currently the duration of a backend request and of single LDAP
operations are recorded if debug_level is set to 9 or the bit 0x20000 is
* Added support for anonymous PKINIT to get FAST credentials
* We have many warnings and errors from static analyzers
### Important fixes
* SSSD now correctly falls back to UPN search if the user was not found
even with `cache_first = true`.
### Packaging changes
* Added new configure option `--with-oidc-child` and
`--without-oidc-child` to control build of `oidc_child` (enabled by
* Added new package `sssd-idp` that contains the `oidc_child` and krb5
`idp` plugin, this package is required by `sssd-ipa`.
Having some RHEL 8 machines as vdi on a VMware Horizon desktop pool, we see that when reconnecting to a machine, system-auth and its pam-stack is executed (at least I think so).
Is there a way to make pam_sss actually fetch a new TGT when doing so, just like entering a password when the screensaver does?