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
Integrate DMZ clients (sssd) to Active Directory through proxy
by Horváth Szabolcs
Hi,
I'd like to integrate our servers sitting in DMZ to Active Directory
(domain controllers are located inside), without direct network connection
between the parties.
The security policy says we have to use some kind of intermediate party
(e.g. layer7 proxy).
A few years ago I had a project where the clients and the proxy server were
all RHEL7, and the solution was slapd as an ldap proxy and pam_ldap+nslcd
on client side (https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD).
Time has passed, we have no longer have RHEL7s, RHEL/SUSE no longer have
openldap-servers package (although slapd in back in EPEL9) and we don't
have nslcd+pam_ldap on SLES15 anymore.
It looks like everyone prefers 389 directory server project.
RedHat has an excellent article about the problem:
https://www.redhat.com/en/blog/identity-management-systems-dmz
Basically my options are:
1. local authentication (that's the starting point from which we want to
move on)
2. connect directly to AD (there are no working layer7 proxy solutions as
far as I know, so we rejected this option)
3. expose read only AD replicas in DMZ (so-called roDCs or 389-ds -> very
complex solution, I don't want go in this direction)
4. separate AD/IdM domain in DMZ (see above, it does not reduce complexity)
5. kdcproxy - https://github.com/latchset/kdcproxy
On the client side, I would stick to sssd (SLES 15 and RHEL8+, very limited
number of older versions).
The proxy side, I tested two solutions, none of them really work:
1. slapd (from EPEL9) as an LDAPS proxy between the clients and AD. sssd (I
tested 2.5.2) detects the presence of the proxy and fails:
---
id_provider = ldap
ldap_uri = ldaps://ldapproxy.test.local
ldap_search_base = OU=TESTLAB,DC=test,DC=local
ldap_schema = AD
[...]
auth_provider = ldap
---
* (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900],
ldap[0x55bb0dbd53e0]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_entry] (0x1000):
OriginalDN: [].
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [objectClass]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [namingContexts]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedControl]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedExtension]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedFeatures]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedLDAPVersion]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900],
ldap[0x55bb0dbd53e0]
* (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
* (2024-01-28 20:08:27): [be[test.local]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
* (2024-01-28 20:08:27): [be[test.local]] [sdap_op_destructor]
(0x2000): Operation 1 finished
* (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done]
(0x2000): Got rootdse
* (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done]
(0x2000): Skipping auto-detection of match rule
* (2024-01-28 20:08:27): [be[test.local]]
[sdap_get_server_opts_from_rootdse] (0x0020): ldap_rootdse_last_usn
configured but not found in rootdse!
********************** BACKTRACE DUMP ENDS HERE
*********************************
Basically we don't have so much information in rootDSE which sssd depends
on:
# ldapsearch -h 127.0.0.1 -D
"CN=_svc_ldapquery,OU=Users,OU=TESTLAB,DC=test,DC=local" -b '' -s base
'(objectclass=*)'
#
dn:
objectClass: top
objectClass: OpenLDAProotDSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
2. kdcproxy as a kerberos proxy: https://github.com/latchset/kdcproxy
The main problem is sssd can utilize krb5 for access_provider and
access_provider, but it needs separate id_provider, usually
id_provider=ldap, and it comes to my previous problem, I couldn't proxy
ldap protocol.
Do you have any suggestions for this problem that I haven't considered?
Thanks!
Szabolcs
2 months, 3 weeks
Undocumented ldap_sasl_authid feature causing sssd to succeed?
by Spike White
All,
We’re auditing for successful & healthy AD join of our 32K+ servers. Our
check is basically this:
AUTHID=$(grep ldap_sasl_authid /etc/sssd/sssd.conf | awk '{print $3}')
[[ $AUTHID != host/* ]] && AUTHID=host/$AUTHID
kinit -k $AUTHID
i.e., kinit with the same service principal that sssd uses (prepending the
"host/" prefix if not already existing).
We’ve identified about 200 “failing” servers, but upon closer inspection
only about 30 of them are really failing.
The other 170 are failing the above naïve check, but sssd is properly
working. Here’s an example:
Server ddlplhdc4036.us.company.com has
ldap_sasl_authid = ddlplhdc4034.us.company.com(a)AMER.COMPANY.COM
<.us.dell.com(a)AMER.DELL.COM>
but in /etc/krb5.keytab file ii has:
host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM
<host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM>
If you look at the sssd-ldap man page, it states:
ldap_sasl_authid (string)
Specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO
are used, this represents the Kerberos principal used for authentication to
the directory. This option can
either contain the full principal (for example host/
myhost(a)EXAMPLE.COM) or just the principal name (for example host/myhost). By
default, the value is not set and the
following principals are used:
hostname@REALM
netbiosname$@REALM
host/hostname@REALM
*$@REALM
host/*@REALM
host/*
If none of them are found, the first principal in keytab is
returned.
Default: host/hostname@REALM
If we have ldap_sasl_authid defined in /etc/sssd/sssd.conf file and it
fails, does it try those other permutations above?
I'm guessing so, based on these 170 servers that are allegedly failing, but
sssd is truly succeeding.
Spike White
2 months, 3 weeks
Weird issue with "Couldn't invalidate user" - SSSD-AD
by Kodiak Firesmith
Hello,
I've begun to see the oddest thing within our AD environment on Linux clients (Ubuntu 20, 22).
During logins I see "groups: cannot find name for group ID".
Then during various operations (eg when installing a package that has scripts that create local users, such as postgresql) I see a few of the same userIDs listed as terminal output like this:
Couldn't invalidate user jim.bob(a)domain.college.edu
Couldn't invalidate user sally.sue(a)domain.college.edu
Couldn't invalidate user joe.nobody(a)domain.college.edu
Reading through what little comes up in Google for 'Couldn't invalidate user' + sssd, I found old bugs about not being able to invalidate groups in the sss_cache. That got me far enough to have a repeatable action to force this output:
# sss_cache -UG
Couldn't invalidate user jim.bob(a)domain.college.edu
Couldn't invalidate user sally.sue(a)domain.college.edu
Couldn't invalidate user joe.nobody(a)domain.college.edu
I've tried ramping up debugging on my AD domain entry in sssd.conf to 9 but I'm not seeing anything that jumps out.
Any ideas?
Thanks!
2 months, 3 weeks
SSSD LDAP provider fails to fetch nested groups (groups member of groups)
by Finn Fysj
I'm experiencing problems on my RHEL 9 instance when looking up members of group using
getent group <GROUP NAME>. I can only get users which has direct access to a group,
and no the "user groups" part of the group.
My sssd.conf:
[domain/<DOMAIN>]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri = ldaps:/ipa.example.com
ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com
[sssd]
services = nss, pam, sudo
domains = default
[nss]
homedir_substring = /home
[pam]
[sudo]
3 months
sssd_nss writing 25 MiB to /var/lib/sss/mc every time it starts up
by D M
Hi folks! I'm chasing down some interesting behavior on our Ubuntu 20.04 VMs. We're running sssd 2.3.3.
The people who run the underlying disks for our VM hosts have been complaining about a spike in disk write latency every 10min.
After investigation, I figured out the issue.
By default, every 10 mins Debian systems run a cronjob, which kicks off a script called debian-sa1. By default, this script is basically a no-op. It doesn't write to disk.
But running this cronjob (which runs as root by default) causes sssd_nss to get started up (on Ubuntu, it's socket activated, as you probably well know).
When sssd_nss starts up, it writes the memory-mapped cache in /var/lib/sss/mc/.
For us, it writes about 25 MiB of data. (Is that a lot?)
By default, sssd_nss has a 5-minute timeout, so, if nothing else looks up any user info, sssd_nss shuts down.
So, basically, every 10 mins, sssd_nss wakes up and writes 25 MiB. Across many thousands of VMs, this adds up to a lot of writes!
Oh RHEL, seems like sssd_nss runs continuously, not socket-activated. I am thinking of just doing the same on Ubuntu. This will keep the memory-mapped cache active all the time, which is fine.
It'll prevent all those disk writes.
However, I wanted to see if you had any other suggestions. Thanks!
3 months, 1 week
SSSD LDAP provider fails to fetch nested groups (groups member of groups)
by Finn Fysj
I'm experiencing problems on my RHEL 9 instance when looking up members of group using
getent group <GROUP NAME>. I can only get users which has direct access to a group,
and no the "user groups" part of the group.
My sssd.conf:
[domain/<DOMAIN>]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri = ldaps:/ipa.example.com
ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com
[sssd]
services = nss, pam, sudo
domains = default
[nss]
homedir_substring = /home
[pam]
[sudo]
3 months, 1 week
[SSSD] Announcing SSSD 2.9.4
by Pavel Březina
# SSSD 2.9.4
The SSSD team is announcing the release of version 2.9.4 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.9.4
See the full release notes at:
https://sssd.io/release-notes/sssd-2.9.4.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
# SSSD 2.9.4 Release Notes
## Highlights
### Important fixes
* Fixes a crash when PAM passkey processing incorrectly handles
non-passkey data.
* A workaround was implemented to handle gracefully misbehaving
applications that destroy internal state of SSSD client librarires. A
particular example of such application is described in
https://github.com/TigerVNC/tigervnc/issues/1709.
* An error when rotating KCM's logs was fixed. When KCM's logs were
rotated by logrotate, KCM would still use the old file (renamed
sssd_kcm.log.1). Only after KCM was restarted (either manually or
automatically) the new log file would be used. This problem is now
solved and KCM uses the new file immediately.
* Fixed group membership handling when members are coming from
different forest domains and using ldap token groups is prohibited.
* Files provider was erroneously taking into consideration
`local_auth_policy` config option, thus breaking smartcard
authentication of local user in setups that didn't explicitly specify
this option. This is now fixed.
3 months, 2 weeks
Does sssd (on RHEL8 and RHEL9) RPM have an implied dependency on sssd-kcm RPM?
by Spike White
All,
Is there a packaging problem on the latest version of RHEL8 sssd?
On several of our RHEL8 servers during the last update cycle, sssd logins
start failing. It appears to be when upgrading to version
sssd-2.9.1-4.0.1.el8_9.x86_64.
Upon deep dive, it turns out the sssd-kcm RPM is missing.
The sssd-kcm service fails to start, complaining about missing symbols in
/usr/libexec/sssd_kcm file.
Sure enough, there is a problem with that file:
[root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm
file /usr/libexec/sssd/sssd_kcm is not owned by any package
Once the sssd-kcm RPM is installed, then this looks normal:
[root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm
sssd-kcm-2.9.1-4.0.1.el8_9.x86_64
Then sssd-kcm service will restart fine. and then sssd logins again work
fine.
Also, it appears that a yum downgrade of sssd seems to work too --
presumably because this downgrade also triggers an install of sssd-kcm RPM.
I see that the sssd RPM has no direct explicit RPM dependency on sssd-kcm.
But is there some indirect or implied dependency that was missed on this
latest packaging for sssd-2.9.1-4.0.1.el8_9.x86_64?
We've run sssd for years and never had significant sssd-kcm problems until
last month.
BTW, another clue that it was KCM is that 'kinit -k' fails with error:
# knit -k
Cannot update default cache
But if you tell it to store creds under /tmp, it works:
# export KRB5CCNAME="FILE:/tmp/krb5cc_0"
# kinit -k
Spike
3 months, 2 weeks