sssd-pac.service fails to start after Debian 12 upgrade (fatal error setting up backend connector)
by Adam Cecile
Hello,
I am not sure to understand what is going on but all my servers being upgraded
from Debian 11 to Debian 12 with MS Active Directory integration using SSSD
starts reporting systemctl issues with sssd-pac service/socket failing to
start.
When being started manually with "/usr/libexec/sssd/sssd_pac --logger=stderr
--socket-activated --debug-level=8":
[pac] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
(2023-06-14 15:21:20): [pac] [server_setup] (0x3f7c0): Starting with debug
level = 0x37f0
(2023-06-14 15:21:20): [pac] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(2023-06-14 15:21:20): [pac] [schedule_responder_idle_timer] (0x2000): Re-
scheduling the idle timeout [responder_idle_timeout] for the responder
[0x55892f921550]
(2023-06-14 15:21:20): [pac] [setup_responder_idle_timer] (0x2000): Setting up
the idle timeout [responder_idle_timeout] for the responder [0x55892f921550]
(2023-06-14 15:21:20): [pac] [confdb_init_domain_provider_and_enum] (0x0400):
No enumeration for [ad.domain.com]!
(2023-06-14 15:21:20): [pac] [confdb_init_domain_provider_and_enum] (0x0400):
Please note that when enumeration is disabled `getent passwd` does not return
all users by design. See sssd.conf man page for more detailed information
(2023-06-14 15:21:20): [pac] [confdb_init_domain_pwd_expire] (0x1000):
pwd_expiration_warning is 21
(2023-06-14 15:21:20): [pac] [confdb_init_domain_pwd_expire] (0x0100): Setting
domain password expiration warning to 21 days
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell /bin/sh
in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/bin/bash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/usr/bin/bash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/bin/rbash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/usr/bin/rbash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/bin/dash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/usr/bin/dash in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/usr/bin/screen in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_get_etc_shells] (0x0400): Found shell
/usr/bin/sh in /etc/shells
(2023-06-14 15:21:20): [pac] [sss_names_init_from_args] (0x0100): Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>.+)@(?P<domain>[^@]+$))|(^(?P<name>[^@\\]+)$))].
(2023-06-14 15:21:20): [pac] [sss_fqnames_init] (0x0100): Using fq format
[%1$s@%2$s].
(2023-06-14 15:21:20): [pac] [sbus_dbus_request_name] (0x0020): Unable to
request name on the system bus [3]
(2023-06-14 15:21:20): [pac] [sss_dp_init] (0x0010): Failed to connect to
backend server.
(2023-06-14 15:21:20): [pac] [sss_process_init] (0x0010): fatal error setting
up backend connector
(2023-06-14 15:21:20): [pac] [sss_responder_ctx_destructor] (0x0400): Responder
is being shut down
(2023-06-14 15:21:20): [pac] [pac_process_init] (0x0010): sss_process_init()
failed
Such error does not occurs on Debian 11.
Sadly Internet is not really helping on this one so I have no idea of what to
look for. Everything seems to be working correctly despite the failing service.
Any idea ?
Best regards, Adam.
3 months, 1 week
best practice, using machine-account keytab for service SPNs
by Stefan Bauer
Dear Users,
i really love SSSD and also the auto-renewal of the host-keytab file.
On many hosts we add the SPNs
HTTP/
SQL/...
directly to the machine-account in Active-Directory. This is all fine and
works.
However i have a bad feeling about letting services read the keytab file as
it gives access to the machine-account.
Opinions?
How do you handle service keytabs and it's rotation?
Thank you.
Stefan
4 months
Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell
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?
Cheers,
b.
4 months, 2 weeks
after some time groups enumeration doesn't work anymore
by Eric Doutreleau
Hi
i m using sssd-2.8.2 on rocky 8 and 9 system.
When i start a clean installation ( i erase the sssd cache ) the group
enumeration work nice.
but after some time the same command
getent group
give mr only local group and not AD group.
when i look at the sssd_nss log i see the following message
* (2023-07-13 10:08:37): [nss] [cache_req_set_plugin] (0x2000):
[CID#3614] CR #3770: Setting "Enumerate groups" plugin
* (2023-07-13 10:08:37): [nss] [cache_req_send] (0x0400):
[CID#3614] CR #3770: REQ_TRACE: New request [CID #3614] 'Enumerate groups'
* (2023-07-13 10:08:37): [nss] [cache_req_select_domains] (0x0400):
[CID#3614] CR #3770: Performing a multi-domain search
* (2023-07-13 10:08:37): [nss] [cache_req_search_domains] (0x0400):
[CID#3614] CR #3770: Search will bypass the cache and check the data
provider
* (2023-07-13 10:08:37): [nss]
[cache_req_validate_domain_enumeration] (0x0400): [CID#3614] CR #3770:
Domain ibfj-evry.fr supports enumeration
* (2023-07-13 10:08:37): [nss] [cache_req_validate_domain_type]
(0x2000): [CID#3614] Request type POSIX-only for domain ibfj-evry.fr
type POSIX is valid
* (2023-07-13 10:08:37): [nss] [cache_req_set_domain] (0x0400):
[CID#3614] CR #3770: Using domain [ibfj-evry.fr]
* (2023-07-13 10:08:37): [nss] [cache_req_search_send] (0x0400):
[CID#3614] CR #3770: Looking up Groups enumeration
* (2023-07-13 10:08:37): [nss] [cache_req_search_ncache] (0x2000):
[CID#3614] CR #3770: This request type does not support negative cache
* (2023-07-13 10:08:37): [nss] [cache_req_search_dp] (0x0400):
[CID#3614] CR #3770: Looking up [Groups enumeration] in data provider
* (2023-07-13 10:08:37): [nss] [sss_dp_get_account_send] (0x0400):
[CID#3614] Creating request for [ibfj-evry.fr][0x2][BE_REQ_GROUP][*:-]
* (2023-07-13 10:08:37): [nss] [sbus_dispatch] (0x4000): Dispatching.
* (2023-07-13 10:08:37): [nss] [sss_domain_get_state] (0x1000):
[CID#3614] Domain ibfj-evry.fr is Active
* (2023-07-13 10:08:37): [nss] [cache_req_search_cache] (0x0400):
[CID#3614] CR #3770: Looking up [Groups enumeration] in cache
* (2023-07-13 10:08:37): [nss] [sysdb_enumgrent_filter] (0x1000):
[CID#3614] Searching timestamp cache with [(objectCategory=group)]
* (2023-07-13 10:08:37): [nss] [sysdb_cache_search_groups]
(0x2000): [CID#3614] Search groups with filter:
(&(objectCategory=group)(objectCategory=group))
* (2023-07-13 10:08:37): [nss] [sysdb_enumgrent_filter_with_views]
(0x0040): [CID#3614] sysdb_enumgrent failed.
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2023-07-13 10:08:37): [nss] [cache_req_search_cache] (0x0020):
[CID#3614] CR #3770: Unable to lookup [Groups enumeration] in cache [5]:
Erreur d'entrée/sortie
(2023-07-13 10:09:12): [nss] [sysdb_enumgrent_filter_with_views]
(0x0040): [CID#3619] sysdb_enumgrent failed.
* ... skipping repetitive backtrace ...
(2023-07-13 10:09:12): [nss] [cache_req_search_cache] (0x0020):
[CID#3619] CR #3775: Unable to lookup [Groups enumeration] in cache [5]:
Erreur d'entrée/sortie
Seems there a some kind of corrupted cache in sssd
Have someone already see this problem?
4 months, 4 weeks
Is there a way to restrict nss group membership searches for local users to only /etc/group?
by Spike White
All,
Successful sssd consumer here.
Have an app team running Hadoop. They're getting these performance errors
in their app.
This is from their app logs.
ddlflhdm201.us.company.com
WARN June 15, 2023 10:08 AM Groups Potential performance problem:
getGroups(user=hbase) took 58022 milliseconds
ddlflhdm304.us.company.com
WARN June 15, 2023 8:38 AM Groups Potential performance problem:
getGroups(user=mapred) took 39962 milliseconds
ddlplhdm505.us.company.com
WARN June 16, 2023 5:37 AM Groups Potential performance problem:
getGroups(user=hdfs) took 62437 milliseconds.
ddlplhdm305.us.company.com
WARN June 15, 2023 9:36 PM Groups Potential performance problem:
getGroups(user=hdfs) took 58017 milliseconds
ddlplhdm505.us.company.com
WARN June 10, 2023 8:01 AM Groups Potential performance problem:
getGroups(user=yarn) took 58017 milliseconds.
Interestingly, all these users are local users created by the Hadoop
package installation. (hbase, mapred, hdfs, yarn are all local users).
These local users are members only of local groups. So theoretically the
search for group memberships should be lightning quick as the groups are
found only in /etc/group.
But since my /etc/nsswitch.conf looks like this:
passwd: files systemd sss
group: files systemd sss
netgroup: files sss
automount: files sss
services: files
shadow: files sss
hosts: files dns myhostname
It not only searches local files for group membership, it searches AD as
well. And doesn't find it, as there is no such AD user or uid.
Eventually timing out.
In /var/log/messages we see this around the same time frame as
Jun 15 10:08:09 ddlflhdm201 sssd[be[amer.company.com]]: GSSAPI Error: An
invalid name was supplied (Success)
Is there a way to restrict these particular local app accounts from having
their group memberships looked up in AD?
I.e., my [nss] section looks like this today:
[nss]
#debug_level = 9
filter_groups = root
filter_users = root
#override_homedir = /home/%u
Can I do this?
[nss]
filter_users = root, hbase, mapred, hdfs, yarn
And would I want to set filter_users_in_groups = false?
Spike White
5 months