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.
On 6/14/23 09:35, Adam Cecile wrote:
(2023-06-14 15:21:20): [pac] [sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This seems to be where things break. Can you confirm DBus on this system is running properly? Check:
# systemctl status dbus.service # dbus-monitor
Can we see your sssd.conf?
On 6/14/23 15:42, Striker Leggette wrote:
On 6/14/23 09:35, Adam Cecile wrote:
(2023-06-14 15:21:20): [pac] [sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This seems to be where things break. Can you confirm DBus on this system is running properly? Check:
# systemctl status dbus.service # dbus-monitor
Can we see your sssd.conf?
Sure ! Here you go:
server:~# systemctl status dbus.service ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static) Active: active (running) since Wed 2023-06-14 15:20:32 CEST; 23min ago TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) Main PID: 757 (dbus-daemon) Tasks: 1 (limit: 4604) Memory: 2.2M CPU: 274ms CGroup: /system.slice/dbus.service └─757 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Jun 14 15:20:31 server systemd[1]: Starting dbus.service - D-Bus System Message Bus... Jun 14 15:20:32 server systemd[1]: Started dbus.service - D-Bus System Message Bus.
server:~# dbus-monitor Failed to open connection to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
sssd.conf:
[sssd] domains = ad.domain.com config_file_version = 2 services =
[domain/ad.domain.com] ad_domain = ad.domain.com ad_server = adsrv01.ad.domain.com, adsrv02.ad.domain.com, adsrv03.ad.domain.com krb5_realm = AD.DOMAIN.COM realmd_tags = cache_credentials = true krb5_validate = false id_provider = ad krb5_store_password_if_offline = true override_shell = /bin/bash default_shell = /bin/bash override_homedir = /home/%u fallback_homedir = /home/%u ldap_id_mapping = true use_fully_qualified_names = false access_provider = simple simple_allow_groups = itadmin ad_gpo_map_remote_interactive = ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities chpass_provider = ad pwd_expiration_warning = 21
Am Wed, Jun 14, 2023 at 03:45:53PM +0200 schrieb Adam Cecile:
On 6/14/23 15:42, Striker Leggette wrote:
On 6/14/23 09:35, Adam Cecile wrote:
(2023-06-14 15:21:20): [pac] [sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This seems to be where things break. Can you confirm DBus on this system is running properly? Check:
# systemctl status dbus.service # dbus-monitor
Hi,
SSSD is not using the system DBus service but implements it's own.
Can you check if the other SSSD processes, especially the backend process sssd_be, are running when you are trying to start the PAC responder? Please note the we currently recommend to start the PAC responder together with the other SSSD components by adding 'pac' to the 'service' line in sssd.conf. It looks like the line is empty in your sssd.conf, is there a reason for this, typically I would expect at least 'nss' and 'pam' in this line, see man sssd.conf for details.
bye, Sumit
Can we see your sssd.conf?
Sure ! Here you go:
server:~# systemctl status dbus.service ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static) Active: active (running) since Wed 2023-06-14 15:20:32 CEST; 23min ago TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) Main PID: 757 (dbus-daemon) Tasks: 1 (limit: 4604) Memory: 2.2M CPU: 274ms CGroup: /system.slice/dbus.service └─757 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Jun 14 15:20:31 server systemd[1]: Starting dbus.service - D-Bus System Message Bus... Jun 14 15:20:32 server systemd[1]: Started dbus.service - D-Bus System Message Bus.
server:~# dbus-monitor Failed to open connection to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
sssd.conf:
[sssd] domains = ad.domain.com config_file_version = 2 services =
[domain/ad.domain.com] ad_domain = ad.domain.com ad_server = adsrv01.ad.domain.com, adsrv02.ad.domain.com, adsrv03.ad.domain.com krb5_realm = AD.DOMAIN.COM realmd_tags = cache_credentials = true krb5_validate = false id_provider = ad krb5_store_password_if_offline = true override_shell = /bin/bash default_shell = /bin/bash override_homedir = /home/%u fallback_homedir = /home/%u ldap_id_mapping = true use_fully_qualified_names = false access_provider = simple simple_allow_groups = itadmin ad_gpo_map_remote_interactive = ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities chpass_provider = ad pwd_expiration_warning = 21
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 6/15/23 10:47, Sumit Bose wrote:
Am Wed, Jun 14, 2023 at 03:45:53PM +0200 schrieb Adam Cecile:
On 6/14/23 15:42, Striker Leggette wrote:
On 6/14/23 09:35, Adam Cecile wrote:
(2023-06-14 15:21:20): [pac] [sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This seems to be where things break. Can you confirm DBus on this system is running properly? Check:
# systemctl status dbus.service # dbus-monitor
Hi,
SSSD is not using the system DBus service but implements it's own.
Can you check if the other SSSD processes, especially the backend process sssd_be, are running when you are trying to start the PAC responder? Please note the we currently recommend to start the PAC responder together with the other SSSD components by adding 'pac' to the 'service' line in sssd.conf. It looks like the line is empty in your sssd.conf, is there a reason for this, typically I would expect at least 'nss' and 'pam' in this line, see man sssd.conf for details.
bye, Sumit
Hello,
Thanks a lot for your help, sssd_be is indeed running:
server# ps aux | grep sss root 793 0.0 0.2 27416 11864 ? Ss Jun14 0:00 /usr/sbin/sssd -i --logger=files root 973 0.0 0.6 117424 26508 ? S Jun14 0:05 /usr/libexec/sssd/sssd_be --domain ad.domain.com --uid 0 --gid 0 --logger=files root 1127 0.0 0.3 71508 15500 ? S Jun14 0:00 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files root 1157 0.0 1.2 63724 48912 ? Ss Jun14 0:03 /usr/libexec/sssd/sssd_nss --logger=files --socket-activated root 247030 0.1 0.3 28788 14100 ? Ss 11:06 0:00 /usr/libexec/sssd/sssd_ssh --logger=files --socket-activated root 247037 0.2 0.3 31520 15244 ? Ss 11:06 0:00 /usr/libexec/sssd/sssd_pam --logger=files --socket-activated
No particular reasons for having "service" setting being empty, it seems it always worked without so I probably never configured it.
Regards, Adam.
Hello, I have a similar problem after upgrading to Debian 12. On all upgraded machines sssd-pac.service fails. My understanding is, that services listed in the services line are not socket activated. Therefore I completely removed this line in Debian 11. Since Debian preconfigured the socket services I would then still have failed services when I would add them to services=. This is my sssd.conf (domain names removed):
[sssd] domains = xxxx config_file_version = 2
[domain/xxxx] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = XXXX realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%u@%d ad_domain = xxxx use_fully_qualified_names = True ldap_id_mapping = True access_provider = ad ldap_user_ssh_public_key = altSecurityIdentities ad_gpo_access_control = disabled
[pam]
[pac]
[ssh]
[sudo]
[nss] default_shell = /bin/bash shell_fallback = /bin/bash allowed_shells = /bin/bash,/bin/zsh
I can see the same errors as described above in my log file. "sudo systemctl | grep sssd" provides the following output:
sssd-nss.service loaded active running SSSD NSS Service responder ● sssd-pac.service loaded failed failed SSSD PAC Service responder sssd-pam.service loaded active running SSSD PAM Service responder sssd-ssh.service loaded active running SSSD SSH Service responder sssd.service loaded active running System Security Services Daemon sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket ● sssd-pac.socket loaded failed failed SSSD PAC Service responder socket sssd-pam-priv.socket loaded active running SSSD PAM Service responder private socket sssd-pam.socket loaded active running SSSD PAM Service responder socket sssd-ssh.socket loaded active running SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
It seems that sssd-pac is still started with the main sssd process: "sudo systemctl status sssd.service": ● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; preset: enabled) Active: active (running) since Mon 2023-08-07 12:56:45 CEST; 50min ago Main PID: 14410 (sssd) Tasks: 3 (limit: 9481) Memory: 19.8M CPU: 1.938s CGroup: /system.slice/sssd.service ├─14410 /usr/sbin/sssd -i --logger=files ├─14411 /usr/libexec/sssd/sssd_be --domain xxxx --uid 0 --gid 0 --logger=files └─14412 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files
Aug 07 12:56:44 yyyy systemd[1]: Starting sssd.service - System Security Services Daemon... Aug 07 12:56:45 yyyy sssd[14410]: Starting up Aug 07 12:56:45 yyyy sssd_be[14411]: Starting up Aug 07 12:56:45 yyyy sssd_pac[14412]: Starting up Aug 07 12:56:45 yyyy systemd[1]: Started sssd.service - System Security Services Daemon.
On Debian 11 I do net see /usr/libexec/sssd/sssd_pac as part of this output.
Does anybody have an idea on how to fix this?
Regards Steven
On Mon, Aug 7, 2023 at 2:02 PM Steven McCormack smc999@fedoraproject.org wrote:
Hello, I have a similar problem after upgrading to Debian 12. On all upgraded machines sssd-pac.service fails. My understanding is, that services listed in the services line are not socket activated. Therefore I completely removed this line in Debian 11. Since Debian preconfigured the socket services I would then still have failed services when I would add them to services=. This is my sssd.conf (domain names removed):
[sssd] domains = xxxx config_file_version = 2
[domain/xxxx] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = XXXX realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%u@%d ad_domain = xxxx use_fully_qualified_names = True ldap_id_mapping = True access_provider = ad ldap_user_ssh_public_key = altSecurityIdentities ad_gpo_access_control = disabled
[pam]
[pac]
[ssh]
[sudo]
[nss] default_shell = /bin/bash shell_fallback = /bin/bash allowed_shells = /bin/bash,/bin/zsh
I can see the same errors as described above in my log file. "sudo systemctl | grep sssd" provides the following output:
sssd-nss.service loaded active running SSSD NSS Service responder ● sssd-pac.service loaded failed failed SSSD PAC Service responder sssd-pam.service loaded active running SSSD PAM Service responder sssd-ssh.service loaded active running SSSD SSH Service responder sssd.service loaded active running System Security Services Daemon sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket ● sssd-pac.socket loaded failed failed SSSD PAC Service responder socket sssd-pam-priv.socket loaded active running SSSD PAM Service responder private socket sssd-pam.socket loaded active running SSSD PAM Service responder socket sssd-ssh.socket loaded active running SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
It seems that sssd-pac is still started with the main sssd process:
Hi,
does your SSSD version support the `implicit_pac_responder` sssd.conf option (see `man sssd.conf`)? If "yes", could you please try setting it to 'false'?
"sudo systemctl status sssd.service": ● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; preset: enabled) Active: active (running) since Mon 2023-08-07 12:56:45 CEST; 50min ago Main PID: 14410 (sssd) Tasks: 3 (limit: 9481) Memory: 19.8M CPU: 1.938s CGroup: /system.slice/sssd.service ├─14410 /usr/sbin/sssd -i --logger=files ├─14411 /usr/libexec/sssd/sssd_be --domain xxxx --uid 0 --gid 0 --logger=files └─14412 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files
Aug 07 12:56:44 yyyy systemd[1]: Starting sssd.service - System Security Services Daemon... Aug 07 12:56:45 yyyy sssd[14410]: Starting up Aug 07 12:56:45 yyyy sssd_be[14411]: Starting up Aug 07 12:56:45 yyyy sssd_pac[14412]: Starting up Aug 07 12:56:45 yyyy systemd[1]: Started sssd.service - System Security Services Daemon.
On Debian 11 I do net see /usr/libexec/sssd/sssd_pac as part of this output.
Does anybody have an idea on how to fix this?
Regards Steven _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi Alexey,
thanks for the information. implicit_pac_responder = flase did the trick. Now all services start as expected
Thanks Steven
Hi Steven,
On Thu, Aug 10, 2023 at 12:49 AM Steven McCormack smc999@fedoraproject.org wrote:
Hi Alexey,
thanks for the information. implicit_pac_responder = flase did the trick. Now all services start as expected
well... I must admit "monitor" activation vs "systemd/socket" activation configuration is somewhat messy...
I think with the current state of code upstream, it makes sense to reach out to maintainers of the Debian SSSD package: I think they either need to change default value of `implicit_pac_responder` to 'false' or disable sssd-pac.socket by default.
On 8/10/23 15:14, Alexey Tikhonov wrote:
Hi Steven,
On Thu, Aug 10, 2023 at 12:49 AM Steven McCormack smc999@fedoraproject.org wrote:
Hi Alexey,
thanks for the information. implicit_pac_responder = flase did the trick. Now all services start as expected
well... I must admit "monitor" activation vs "systemd/socket" activation configuration is somewhat messy...
I think with the current state of code upstream, it makes sense to reach out to maintainers of the Debian SSSD package: I think they either need to change default value of `implicit_pac_responder` to 'false' or disable sssd-pac.socket by default.
Hello,
I can confirm adding implicit_pac_responder = false to sssd section fixes the issue.
I forwarded this discussion to Debian package maintainers.
Regards, Adam.
sssd-users@lists.fedorahosted.org