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
Kerberos authentication only works with aes256-cts-hmac-sha1-96 for Windows 10 joined to RHEL IDM
by Deepak Ramanath
I have a Windows 10 server joined to a RedHat IDM (RHEL 8.9) realm using Kerberos. When a user tries to authenticate on a Windows 10 server, the following error is shown
"We cannot sign you in with this credential because your domain isn't available"
On the IDM, looking at the `/var/log/krb5kdc.log`, I see the following...
Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.124.55: NEEDED_PREAUTH: win.user(a)server.local for krbtgt/server.local(a)server.local, Additional pre-authentication required
Nov 30 23:08:17 idm.server.local krb5kdc[11774](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.124.55: ISSUE: authtime 1701385697, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, win.user(a)server.local for krbtgt/server.local(a)server.local
Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): TGS_REQ (5 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.124.55: ISSUE: authtime 1701385697, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, win.user(a)server.local for host/win-server.server.local(a)server.local
In the `/etc/crypto-policies/back-ends/krb5.config`, `libdefaults` has been set to
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac
Interestingly, if all encryption types are removed except aes256-cts-hmac-sha1-96 from the permitted_enctypes, the authentication on Windows 10 is successful.
Any idea why only setting to aes256-cts-hmac-sha1-96 works while a list of supported methods including aes256-cts-hmac-sha1-96 does not?
4 months, 3 weeks
