Starting SSSD without root
by Tero Saarni
Hi,
I'm trying to run SSSD inside docker container without root user. The
container is executed in OpenShift cluster which does not allow running as root
inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have
most critical parts executed as root and have it drop privileges for other
parts but this now completely blocks using SSSD in the above environment.
--
Tero
1 week, 3 days
sssd performance on large domains
by zfnoctis@gmail.com
Hi,
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
2 years, 2 months
kcm, gssproxy and klist
by Winberg Adam
With KCM and gssproxy we often see a long list of credentials when doing a 'klist':
[user.u@lxserv2114 ~]$ klist
Ticket cache: KCM:17098:66803
Default principal: user.u@AD
Valid starting Expires Service principal
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
and so on...
The actual gssproxy credentials at /var/lib/gssproxy/clients/ does not correspond with this output, it only contains what could be expected - a TGT and maybe some service tickets.
The ever growing 'klist' list of credentials is a problem, after a while the user can no longer get any new credentials and therefore has no access to its NFS homedir (sec=krb5). I'm guessing it's the 'max_uid_ccaches' option in sssd-kcm that prevents this.
What is going on here - have we configured gssproxy/kcm wrong or is this a bug?
Regards
Adam
2 years, 4 months
SSSD entry_cache_nowait_percentage/ enum_cache_timeout not working properly?
by Robert Wagensveld
Hi all, I was hoping you could help me with this, as I am essentially clueless by this point.Even setting debug logging to 8 does not give much information as to what the problem might be.
I have chosen to set the enum_cache_timeout to a high value, e.g. 26000 seconds. This because we have a very large environment in terms of AD groups (we use Kerberos over LDAP) and this takes a long time to retrieve all groups. Weird part is, although this helped on some clients, it does not actually reduce login/sudo times on others. I have set the following values in sssd.conf:
entry_cache_nowait_percentage = 50
entry_cache_timeout = 60
My reason for this is that defining a value for the nowait percentage automatically update entries in the background. Not sure if I set the percentage rights though. https://linux.die.net/man/5/sssd.conf
What is wise to do in this regard? My desired behavior would be that it returns entries from cache even while offline as often as possible, and updates the cache in the background. I don't want users to have to wait for SSSD to iterate through all our insane amounts of groups in the foreground.
Thanks in advance!
2 years, 5 months
Group cache entry of removed member in be
by Thomas HUMMEL
Hello,
sssd-2.3.0 on RHEL/CentOS 8.3, I'm trying to figure out how refreshing a
user cache entry could impact (or not) a group entry this user is or has
been a member of in the backend
I'm using sssd-2.3.0 on RHEL/CentOS 8.3 with
auth_provider = ldap
ldap_schema = AD
access_provider = ldap
id_provider = ldap
authselect provides the following setup of nsswitch:
passwd: sss files systemd
group: sss files systemd
Initial experience on *some* hosts using the same sssd config:
a user <user> which has been for some time (greater than any sssd
timeout) removed from group <group> in the AD backend still appeared as
a member when running getent group <group>
"refreshing" this user with getent passwd <user> would fix the issue
I don't quite get the reasoning behind this behavior.
Does the link between the 2 actions lies in the ghost/unghost mechanism ?
I did not manage to reproduce it. The tests I made on another similar
host raised some more questions though:
a) I was able to verify the expected behavior of
entry_cache_group_timeout (or entry_cache_timeout for that matter):
after 1h30m getent group <group> would get the group entry from the
backend. Before that result were fed by the cache and could not be
consistent with the backend
b) I'm having trouble understanding how sss_cache -u or -g works as,
using ldbsearch -H <cache_ldb_file> I can see the dataExpireTimestamp
set to 1 but after what I thought would be a refresh (getent passwd or
group), I still see this value : is this because sssd RAM cache is not
sync'ed ?
Finally, do you confirm that the setting of ldap_purge_cache_timeout
should not change how the membership of a user in a group is return ?
Thanks for you help
--
Thomas HUMMEL
2 years, 6 months
Ubuntu 20.04 server joined to child AD domain unable to auth users from parent domain
by Joseph Agored
I have an Ubuntu 20.04 server that I have successfully joined to my domain using realm, US.EXAMPLE.COM.
The way our AD is structured is that all machines are joined to the child domain for their region and all users are setup in the parent domain, EXAMPLE.COM. With full trust, etc, of course.
I can successfully look up users in the US.EXAMPLE.COM domain with id or getent passwd, but cannot look up any users in the parent EXAMPLE.COM domain.
I can successfully kinit to the parent domain.
I have tried adding capaths to the krb5.conf as well as adding the parent domain to the sssd.conf file like this:
[domain/EXAMPLE.com]
inherit_from = US.EXAMPLE.com
id_provider = ad
debug_level = 7
krb5_validate = False
The closest I seem to get is an error message saying the server isn't found in the parent domain's Kerberous DB.
Client 'host/SERVER01(a)US.EXAMPLE.COM' not found in Kerberos database
Surely there is a way to use the existing trust to let the machine joined to the child domain authenticate users from the parent domain? I have done this successfully in this domain before with a RedHat server using FQDN, but I am trying to get away from RedHat and move to Ubuntu and the same configuration tricks were unable to let the Ubuntu server lookup or authenticate users from the parent domain even with FQDNs.
2 years, 6 months
Timing sensitive issue on `testing pam_acct_mgmt` which is also seen on SSH logins
by Aitor Pazos
Hi all,
Let me introduce the symptoms that triggered this investigation.
First, versions:
- OS: Ubuntu 20.04
- SSSD: 2.2.3-3ubuntu0.7
- Platform: x86_64
Some weeks after starting using a new region/provider we noticed some intermittent issue impacting SSH logins (ie: clients got `Connection closed by UNKNOWN port 65535` on `ssh ...`). When looking into it, I was able to reproduce it somewhat reliably. It happens after some time of inactivity for that user, but if I constantly issue commands (ie: `watch sssctl user-checks <user>` or `watch ssh <host> whoami` from a client) the issue wont trigger. If I stopped trying out those commands and tried again ~30 minutes later, it would fail.
With these symptoms I had these possibilities in mind: some caching issue, some authentication expiring, connections pools issues...
I enabled detailed logging and compared logs from a successful request and a failed one and I found what seems to be the source of the error from sssd logs perspective, but still can't make much sense of it.
Log extracted from sssd_<domain>.log:
```
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=ipa,dc=corp,<dc <domain>>][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)))]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_print_server] (0x2000): Searching <ip10.1.10.102:389
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)][cn=hbac,dc=ipa,dc=corp,<dc <domain>>].
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 18
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_op_add] (0x2000): New operation 18 timeout 60
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: sh[0x55d349f96d00], connected[1], ops[0x55d349ff16e0], ldap[0x55d34a10cba0]
(Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_timeout] (0x1000): Issuing timeout for 18
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_destructor] (0x1000): Abandoning operation 18
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [110]: Connection timed out
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_hbac_rule_info_done] (0x0080): Could not retrieve HBAC rules
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_pam_access_handler_done] (0x0020): Unable to fetch HBAC rules [110]: Connection timed out
(Wed Oct 13 19:41:52 2021) [be[<domain>]] [dp_req_done] (0x0400): DP Request [PAM Account #21]: Request handler finished [0]: Success
```
I tried using `ldap_enumeration_search_timeout = 180` which updated the timeout in (`[sdap_op_add] (0x2000): New operation 18 timeout 60 `) but same result (`enumerate` and `subdomain_enumerate` config options are left to their defaults, `false` and `none` respectively).
I looked at the IPA servers LDAP logs and saw now related requests regarding `ipaHBACRules` so I assume the request didn't even left the server.
I tried tweaking some other caching options like `cached_auth_timeout` and `pam_id_timeout` without any impact. Also tried clearing up the caches with `sss_cache -E` or `systemctl stop sssd && rm /var/lib/sss/db/* && systemctl start sssd` and nothing changed.
This is the error returned by `sssctl user-checks` when it fails:
```
$ sudo sssctl user-checks <user>
user: <user>
action: acct
service: system-auth
SSSD nss user lookup result:
- user name: <user>
- user id: <uid>
- group id: <gid>
- gecos: <name>
- home directory: /home/<user>
- shell: /bin/bash
InfoPipe operation failed. Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services' option in sssd.conf.InfoPipe User lookup with [<user>] failed.
testing pam_acct_mgmt
pam_acct_mgmt: System error
PAM Environment:
- no env -
```
Any pointer here would be very useful.
Thank you!
Aitor
2 years, 6 months
[SSSD] Announcing SSSD 2.5.2
by Pavel Březina
# SSSD 2.6.0
The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.6.0
See the full release notes at:
https://sssd.io/release-notes/sssd-2.6.0.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### General information
* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option.
`libunistring` will be used unconditionally for Unicode processing.
* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to
shell command injection via the logs-fetch and cache-expire subcommands.
This flaw allows an attacker to trick the root user into running a
specially crafted sssctl command, such as via sudo, to gain root access.
The highest threat from this vulnerability is to confidentiality,
integrity, as well as system availability. This patch fixes a flaw by
replacing `system()` with `execvp()`.
### New features
* Basic support of user's 'subuid and subgid ranges' for IPA provider
and corresponding plugin for shadow-utils were introduced. Limitations:
- single subid interval pair (subuid+subgid) per user - idviews aren't
supported - only forward lookup (user -> subid ranges) Take a note, this
is MVP of experimental feature. Significant changes might be required
later, after initial feedback. Corresponding support in shadow-utils was
merged upstream, but since there is no upstream release available yet,
SSSD feature isn't built by default. Build can be enabled with
`--with-subid` configure option. Plugin's install path can be configured
with `--with-subid-lib-path=` (`${libdir}` by default)
### Important fixes
* KCM now replace the old credential with new one when storing an
updated credential that is however already present in the ccache to
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal
data is initialized to be able to refresh the list of trusted domains in
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available
during build. This helps to build SSSD on distributions without `cldap`
support in `libldap`.
* CVE-2021-3621
### Configuration changes
* New IPA provider's option `ipa_subid_ranges_search_base` allows
configuration of search base for user's subid ranges. Default:
`cn=subids,%basedn`
2 years, 6 months
[SSSD] Announcing SSSD 2.6.0
by Pavel Březina
# SSSD 2.6.0
The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.6.0
See the full release notes at:
https://sssd.io/release-notes/sssd-2.6.0.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### General information
* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option.
`libunistring` will be used unconditionally for Unicode processing.
* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to
shell command injection via the logs-fetch and cache-expire subcommands.
This flaw allows an attacker to trick the root user into running a
specially crafted sssctl command, such as via sudo, to gain root access.
The highest threat from this vulnerability is to confidentiality,
integrity, as well as system availability. This patch fixes a flaw by
replacing `system()` with `execvp()`.
### New features
* Basic support of user's 'subuid and subgid ranges' for IPA provider
and corresponding plugin for shadow-utils were introduced. Limitations:
- single subid interval pair (subuid+subgid) per user - idviews aren't
supported - only forward lookup (user -> subid ranges) Take a note, this
is MVP of experimental feature. Significant changes might be required
later, after initial feedback. Corresponding support in shadow-utils was
merged upstream, but since there is no upstream release available yet,
SSSD feature isn't built by default. Build can be enabled with
`--with-subid` configure option. Plugin's install path can be configured
with `--with-subid-lib-path=` (`${libdir}` by default)
### Important fixes
* KCM now replace the old credential with new one when storing an
updated credential that is however already present in the ccache to
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal
data is initialized to be able to refresh the list of trusted domains in
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available
during build. This helps to build SSSD on distributions without `cldap`
support in `libldap`.
* CVE-2021-3621
### Configuration changes
* New IPA provider's option `ipa_subid_ranges_search_base` allows
configuration of search base for user's subid ranges. Default:
`cn=subids,%basedn`
2 years, 6 months
feasible to use sssd in mostly offline mode?
by James Ralston
For our on-site Linux machines, we use the sssd-ad provider to both
map users/groups from Active Directory, and to authenticate users via
Kerberos. It works fantastically well, to the point where we have
absolutely no desire to go back to maintaining local users/groups in
/etc/passwd and /etc/group (respectively).
We are contemplating offering remote Linux laptops to our users. But
our InfoSec team is adamant that our AD DCs must not be reachable from
the Internet at large. So unless the owner of the laptop logs in to
the laptop locally and then connects to our VPN, the laptop will have
no access to Active Directory, and therefore sssd will be in offline
mode.
We are wondering whether it would be feasible to set the various sssd
caches to have long values (e.g. 180 days) so that as long as the user
fires up the laptop and connects to the VPN once every 180 days, they
will still be able to login (using their cached password) and
getpwnam/getpwuid/getgrnam/getgrgid will still work for their
uids/gids (because sssd will return the values it cached from the last
time it was able to reach the AD DCs).
It’s not clear to us how we would implement this. We could adjust
various timeouts; e.g., from:
entry_cache_timeout = 5400
cache_credentials = FALSE
To:
entry_cache_timeout = 7776000
cache_credentials = TRUE
…but I don’t think this is going to do what we want. We only want
sssd to keep entries in the cache for 90 days when it is offline. If
sssd comes back online (because the user connected to the VPN and thus
AD is reachable again), we want AD to refresh any cached entries that
are older than 90 minutes.
So, what we really want is an option for sssd that essentially says,
“You are frequently going to be operating in offline mode, so only
kick things out of the cache when you are in online mode, because
otherwise there’s a good chance that the user won’t be able to login
to fire up the VPN so that you can switch to online mode.”
Has anyone attempted running sssd in a mostly-offline environment like
this? If so, how well does it work, and what settings are you using?
Thanks!
2 years, 6 months