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
2 weeks, 3 days
Internal credentials cache error while getting initial credentials
by Albert Szostkiewicz
Hey,
Need some help here, I am unable to log-in. when trying to use kinit on my user, I am getting an error:
kinit: Failed to store credentials: Internal credentials cache error while getting initial credentials
sssd runs. log shows:
Oct 13 20:32:59 user.mydomain.com krb5_child[4846]: Internal credentials cache error
sssd_kcm.log states:
* (2023-10-13 21:17:43): [kcm] [local_db_check_peruid_number_of_secrets] (0x0040): [CID#8708] Cannot store any more secrets for this client (basedn cn=1907400001,cn=persistent,cn=kcm) as the maximum allowed limit (66) has been reached
********************** BACKTRACE DUMP ENDS HERE *********************************
(2023-10-13 21:17:43): [kcm] [sss_sec_update] (0x0040): [CID#8708] local_db_check_number_of_secrets failed [1432158289]: The maximum number of stored secrets has been reached
(2023-10-13 21:17:43): [kcm] [sec_update] (0x0040): [CID#8708] Cannot write the secret [1432158289]: The maximum number of stored secrets has been reached
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2023-10-13 21:17:43): [kcm] [sss_sec_update] (0x0040): [CID#8708] local_db_check_number_of_secrets failed [1432158289]: The maximum number of stored secrets has been reached
* (2023-10-13 21:17:43): [kcm] [sec_update] (0x0040): [CID#8708] Cannot write the secret [1432158289]: The maximum number of stored secrets has been reached
********************** BACKTRACE DUMP ENDS HERE *********************************
(2023-10-13 21:17:43): [kcm] [kcm_ccdb_mod_done] (0x0040): [CID#8708] Failed to create ccache [1432158289]: The maximum number of stored secrets has been reached
(2023-10-13 21:17:43): [kcm] [kcm_op_set_kdc_offset_mod_done] (0x0040): [CID#8708] Cannot modify ccache [1432158289]: The maximum number of stored secrets has been reached
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2023-10-13 21:17:43): [kcm] [kcm_ccdb_mod_done] (0x0040): [CID#8708] Failed to create ccache [1432158289]: The maximum number of stored secrets has been reached
* (2023-10-13 21:17:43): [kcm] [kcm_op_set_kdc_offset_mod_done] (0x0040): [CID#8708] Cannot modify ccache [1432158289]: The maximum number of stored secrets has been reached
********************** BACKTRACE DUMP ENDS HERE *********************************
(2023-10-13 21:17:43): [kcm] [kcm_cmd_done] (0x0040): [CID#8708] op receive function failed [1432158289]: The maximum number of stored secrets has been reached
(2023-10-13 21:17:43): [kcm] [kcm_cmd_request_done] (0x0040): [CID#8708] KCM operation failed [1432158289]: The maximum number of stored secrets has been reached
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2023-10-13 21:17:43): [kcm] [kcm_cmd_done] (0x0040): [CID#8708] op receive function failed [1432158289]: The maximum number of stored secrets has been reached
* (2023-10-13 21:17:43): [kcm] [kcm_cmd_request_done] (0x0040): [CID#8708] KCM operation failed [1432158289]: The maximum number of stored secrets has been reached
********************** BACKTRACE DUMP ENDS HERE *********************************
KRB5_TRACE=/dev/stderr ipa --debug ping
ipa: DEBUG: importing plugin module ipaclient.plugins.trust
ipa: DEBUG: importing plugin module ipaclient.plugins.user
ipa: DEBUG: importing plugin module ipaclient.plugins.vault
ipa: DEBUG: trying https://workstation.mydomain.com/ipa/json
ipa: DEBUG: Created connection context.rpcclient_140066561958480
ipa: DEBUG: raw: ping(version='2.252')
ipa: DEBUG: ping(version='2.252')
ipa: DEBUG: [try 1]: Forwarding 'ping/1' to json server 'https://workstation.mydomain.com/ipa/json'
ipa: DEBUG: New HTTP connection (workstation.mydomain.com)
ipa: DEBUG: HTTP connection destroyed (workstation.mydomain.com)
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 644, in get_auth_info
response = self._sec_context.step()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/site-packages/gssapi/_utils.py", line 165, in check_last_err
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/site-packages/gssapi/_utils.py", line 131, in catch_and_return_token
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/site-packages/gssapi/sec_contexts.py", line 584, in step
return self._initiator_step(token=token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/site-packages/gssapi/sec_contexts.py", line 606, in _initiator_step
res = rsec_contexts.init_sec_context(self._target_name, self._creds,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "gssapi/raw/sec_contexts.pyx", line 188, in gssapi.raw.sec_contexts.init_sec_context
gssapi.raw.exceptions.MissingCredentialsError: Major (458752): No credentials were supplied, or the credentials were unavailable or inaccessible, Minor (2529639053): No Kerberos credentials available (default cache: KCM:)
During the handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 697, in single_request
self.get_auth_info()
File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 646, in get_auth_info
self._handle_exception(e, service=service)
File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 603, in _handle_exception
raise errors.CCacheError()
ipalib.errors.CCacheError: did not receive Kerberos credentials
ipa: DEBUG: Destroyed connection context.rpcclient_140066561958480
ipa: ERROR: did not receive Kerberos credentials
I appreciate if anyone have some ideas. Thank you!
2 months
Provider sporadically considered Offline and never restores
by dweller dweller
Hello,
I am encountering a persistent issue with sssd intermittently identifying the ipa backend as offline and failing to return online. Initially, I temporarily resolved this by restarting the service, but the problem persists without a permanent solution. I am reluctant to restart the service each time a user encounters this issue.
When sssd indicates that backend is Offline in the logs, I can successfully execute 'id' and 'kinit' commands for the affected user. The 'id' command retrieves the actual groups stored in FreeIPA, confirming that FreeIPA is operational and healthy. However, sssd seems to disagree and indicates otherwise.
I've provided a link to a comprehensive log file containing all entries from /var/log/sssd/ during the SSH login attempt for the 'test-user-ssh':
https://disk.yandex.ru/d/NgiMAHUxgh24Dw
My system configurations are as follows:
sssd version: sssd-2.6.1-alt2.x86_64
freeipa-client version: freeipa-client-4.8.9-alt4.c9f2.3.x86_64
Here is a snippet of my sssd.conf file, in its default state post ipa-client-install:
plaintext
Copy code
[domain/custom.in-realm.domain]
id_provider = ipa
ipa_server = ipa-01.my-realm.internal
ipa_domain = custom.in-realm.domain
ipa_hostname = studio-01.custom.in-realm.domain
krb5_realm = MY-REALM.INTERNAL
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
[sssd]
config_file_version = 2
services = nss, pam, ssh, sudo
user = _sssd
domains = custom.in-realm.domain
[nss]
[ssh]
[sudo]
Any insights or assistance in resolving this recurring sssd issue would be greatly appreciated.
5 months, 1 week
sssd-ldap vs AD forest
by Diego Zuccato
Hello all.
I have to interface with AD via ldap backend (can not join: it makes large
redeploys quite problematic, having to give my own pass on every machine).
Out of the many domains in the AD forest, I'm only interested in PERSONALE
and STUDENTI. I can only manage OUs, groups and machine accounts in
PERSONALE. My users come from both domains, but I'm only interested in
memberships of groups in PERSONALE (those are 'universal' groups that
contain users from both domains).
I currently use this sssd.conf file:
-8<--
[sssd]
config_file_version = 2
services = nss,pam
domains = studenti.domain.it,personale.domain.it
debug_level = 3
override_space = ^
[nss]
fallback_homedir = */home/*%d/%u
default_shell = /bin/bash
debug_level = 3
[pam]
debug_level = 3
[domain/personale.domain.it]
override_homedir = */home/PERSONALE/*%u
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_group_nesting_level = 5
ldap_uri = ldaps://personale.dir.unibo.it:3269
ldap_user_search_base = DC=personale,DC=domain,DC=it??
ldap_group_search_base = OU=REDACTED,DC=personale,DC=domain,DC=it??
ldap_default_bind_dn = CN=REDACTED,DC=personale,DC=domain,DC=it
ldap_default_authtok_type = password
ldap_default_authtok = REDACTED
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_fullname = displayName
ldap_schema = ad
ldap_referrals = False
#ldap_referrals = true
ldap_id_mapping = True
enumerate = false
# Caching settings
cache_credentials = true
entry_cache_user_timeout = 28800
entry_cache_group_timeout = 86400
ldap_id_use_start_tls = false
debug_level = 3
ldap_access_filter =
(memberOf:1.2.840.113556.1.4.1941:=CN=REDACTED,DC=personale,DC=domain,DC=it)
case_sensitive = Preserving
[domain/studenti.domain.it]
override_homedir = */home/STUDENTI/*%u
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_group_nesting_level = 5
# **MUST** use GlobalCatalog port or can't access a group in PERSONALE
ldap_uri = ldaps://studenti.domain.it:3269
ldap_user_search_base = DC=studenti,DC=domain,DC=it
# *NOPE*: see notes
#ldap_group_search_base = OU=REDACED,DC=personale,DC=domain,DC=it??
ldap_default_bind_dn = CN=REDACTED,DC=personale,DC=domain,DC=it
ldap_default_authtok_type = password
ldap_default_authtok = REDACTED
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_fullname = displayName
ldap_schema = ad
ldap_referrals = true
ldap_id_mapping = True
enumerate = false
cache_credentials = true
ldap_id_use_start_tls = false
debug_level = 3
ldap_access_filter =
(memberOf:1.2.840.113556.1.4.1941:=CN=REDACTED,DC=domain,DC=it)
case_sensitive = Preserving
-8<--
* Order for "domains" is important: if I first lookup in PERSONALE,
students are also assigned to PERSONALE.
* If I don't include STUDENTI domain in ldap_user_search_base for
PERSONALE, "getent group" won't return group members from STUDENTI.
* If I specify "ldap_group_search_base" for STUDENTI, "getent group
grpname" only returns group members that are in STUDENTI.
But while 'getent group grpname' returns all users (from both domains), 'id
username' only returns groups from username's domain.
Is there a way to make sssd only consider groups in PERSONALE also for
users in STUDENTI and return consistent results for both id and getent?
Tks.
5 months, 2 weeks
[SSSD] Announcing SSSD 2.9.3
by Pavel Březina
# SSSD 2.9.3
The SSSD team is announcing the release of version 2.9.3 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.9.3
See the full release notes at:
https://sssd.io/release-notes/sssd-2.9.3.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
* The proxy provider is now able to handle certificate mapping and
matching rules and users handled by the proxy provider can be configured
for local Smartcard authentication. Besides the mapping rule local
Smartcard authentication should be enabled with the 'local_auth_policy'
option in the backend and with 'pam_cert_auth' in the PAM responder.
### Important fixes
Passkey doesn't fail when using FreeIPA server-side authentication and
require-user-verification=false.
### New features
* When adding a new credential to KCM and the user has already reached
their limit, the oldest expired credential will be removed to free some
space. If no expired credential is found to be removed, the operation
will fail as it happened in the previous versions.
5 months, 2 weeks
[FOSDEM] [CfP] Identity and Access Management devroom at FOSDEM 2024
by Iker Pedrosa
Hi!
It is a great pleasure to announce a devroom dedicated to Identity and
Access Management at FOSDEM 2024. The last devroom at FOSDEM dedicated to
this topic was in 2018 and we would like to replicate that success.
Original FOSDEM CfP below.
I think there are enough interesting developments and uses of SSSD in
different environments that it is worth presenting at this event.
Consider submitting a talk proposal if you are planning to attend FOSDEM!
Deadline is December 1st, 2023.
Original CfP
Hi!
This is a call for proposals for the Identity and Access Management
Devroom: https://iam-devroom.github.io/fosdem-2024/
# Identity and Access Management Devroom @ FOSDEM'2024
[FOSDEM 2024](https://fosdem.org/2024/) will have a [identity and
access management
devroom](https://fosdem.org/2024/schedule/track/identity_and_access_manag....
The IAM devroom is planned to be run at **Sunday, February 4th, 2024** in
Brussels, Belgium at [ULB](http://www.ulb.ac.be/).
## Our topics this year
This is the Identity and Access Management Devroom and we invite you to submit
a talk that is relevant to operating systems' identity and access management in
the free software and open source world. We don't exclude any relevant
submission, for ideas and suggestions please check the previous edition of IAM
devroom at [FOSDEM
2018](https://archive.fosdem.org/2018/schedule/track/identity_and_access_...
Suggested topics:
- Security: algorithms and protocols for IAM/IdM; passwords and
password alternatives
- Federated and social identity; leveraging external identities in applications
- Audit, compliance, monitoring
- User experience, desktop integration
- Free software IAM/IdM offerings
- IAM/IdM deployment reports
and more. Don't be shy and show how your project helps to improve our lives.
## Submissions
Submissions require a small abstract and a short speaker description and must
be submitted [via the Pretalx system](https://fosdem.org/submit) no later than
**1st of December 2023**. Suggested duration for a timeslot to apply for is
**25 minutes** (20 min presentation + 5 mins questions). The schedule shall be
finalized by **15 December 2023**.
Note that this is a new submission system and accounts from pentabarf were not
migrated: Presenters will have to create a new account.
Instructions:
* Go to [https://fosdem.org/submit](https://fosdem.org/submit)
* Register a new account
* Create a new event with your title and abstract and some
information about you
* Be sure to set the event track to "Identity and Access Management devroom"
* Subscribe to the [iam-devroom at lists.fosdem.org
<https://lists.fosdem.org/listinfo/fosdem>](https://lists.fosdem.org/listinfo/iam-devroom)
mailing list for announcements
### Organizers
* You! - any help with organizing is highly appreciated!
* Alexander Bokovoy (ab at samba.org
<https://lists.fosdem.org/listinfo/fosdem>)
* Iker Pedrosa (ipedrosa at redhat.com
<https://lists.fosdem.org/listinfo/fosdem>)
--
Iker Pedrosa
Senior Software Engineer, Identity Management team
Red Hat <https://www.redhat.com>
Txapela (gorria) buruan eta ibili munduan
(Red) hat on his head and walk the world
Basque proverb
<https://www.redhat.com>
5 months, 2 weeks
