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
Re: [Freeipa-users] who killed SSSD - ?
by Rob Crittenden
cc'ing the sssd users list.
rob
lejeczek via FreeIPA-users wrote:
> Hi guys.
>
> One of the masters started recently to find SSSD dead and says the
> killer is the WATCHDOG - but I'm not sure about that.
> From sssd.log:
> ...
> ********************** BACKTRACE DUMP ENDS HERE
> *********************************
>
> (2022-07-21 7:11:01): [sssd] [svc_child_info] (0x0020): Child [991]
> ('pac':'pac') was terminated by own WATCHDOG
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0020): Child [984]
> ('abba.xx.priv.yy':'%BE_abba.xx.priv.yy') was terminated by own WATCHDOG
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child [9744]
> ('nss':'nss') exited with code [3]
> ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
> BACKTRACE:
> * (2022-07-21 7:11:14): [sssd] [sbus_dispatch_reconnect] (0x0400):
> Connection lost. Terminating active requests.
> * (2022-07-21 7:11:14): [sssd] [sbus_dispatch_reconnect] (0x4000):
> Remote client terminated the connection. Releasing data...
> * (2022-07-21 7:11:14): [sssd] [sbus_connection_free] (0x4000):
> Connection 0x5576314d9180 will be freed during next loop!
> * (2022-07-21 7:11:14): [sssd] [mt_svc_restart] (0x0400):
> Scheduling service abba.xx.priv.yy for restart 1
> * (2022-07-21 7:11:14): [sssd] [get_provider_config] (0x0100):
> Formed command '/usr/libexec/sssd/sssd_be --domain abba.xx.priv.yy --uid
> 0 --gid 0 --logger=files' for provider '%BE_abba.xx.priv.yy'
> * (2022-07-21 7:11:14): [sssd] [start_service] (0x0100): Queueing
> service abba.xx.priv.yy for startup
> * (2022-07-21 7:11:14): [sssd] [mt_svc_exit_handler] (0x1000):
> SIGCHLD handler of service nss called
> * (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child
> [9744] ('nss':'nss') exited with code [3]
> ********************** BACKTRACE DUMP ENDS HERE
> *********************************
>
> (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child [9758]
> ('pac':'pac') exited with code [3]
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:16): [sssd] [svc_child_info] (0x0040): Child [9876]
> ('nss':'nss') exited with code [3]
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:16): [sssd] [svc_child_info] (0x0040): Child [9877]
> ('pac':'pac') exited with code [3]
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:20): [sssd] [svc_child_info] (0x0040): Child [9903]
> ('nss':'nss') exited with code [3]
> * ... skipping repetitive backtrace ...
> (2022-07-21 7:11:20): [sssd] [monitor_restart_service] (0x0010):
> Process [nss], definitely stopped!
> (2022-07-21 7:11:20): [sssd] [monitor_quit] (0x3f7c0): Returned with: 1
> (2022-07-21 7:11:20): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [pac][9904]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [pac]
> terminated with a signal
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [abba.xx.priv.yy][9875]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child
> [abba.xx.priv.yy] exited gracefully
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [sudo][990]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [sudo]
> exited gracefully
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [ssh][989]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [ssh]
> exited gracefully
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [ifp][988]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [ifp]
> exited gracefully
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [pam][987]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [pam]
> exited gracefully
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating
> [implicit_files][983]
> (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child
> [implicit_files] exited gracefully
>
> This "death" happens randomly, well, to me at least. Can be just after
> reboot or several hours of uptime.
> There is more in log files from /var/log/sssd but before I clutter
> emails with more logs snippets I was hoping some expert can share some
> thoughts.
>
> many thanks, L.
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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/freeipa-users@lists.fedoraho...
>
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
1 year, 4 months
Re: Session Recording with sssd is not working
by Stephen Gallagher
A better place for this question is the sssd-users list (which I've just CCed).
On Fri, Jul 15, 2022 at 7:24 AM Sergio Belkin <sebelk(a)gmail.com> wrote:
>
> Hi, I've configured sssd to use session recording along with tlog but it's not working.
>
> I don't use any domain for authentication, all users are local
>
> This my configuration files:
>
> **/etc/sssd/sssd.conf**
> ```
> [sssd]
> domains = files
> services = pam, sudo, nss, ssh
>
> [domain/files]
> id_provider = files
> ```
>
> Is the above configuration correct?
>
> And **/etc/sssd/conf.d/sssd-session-recording.conf** :
>
> ```
> [session_recording]
> scope=all
> exclude_users=
> exclude_groups=
> ```
> I don't find ny errors:
>
> ```
> [root@munster ~]# sssctl config-check
> Issues identified by validators: 0
>
> Messages generated during configuration merging: 0
>
> Used configuration snippet files: 1
> /etc/sssd/conf.d/sssd-session-recording.conf
> [root@munster ~]# systemctl status sssd
> ● sssd.service - System Security Services Daemon
> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
> Active: active (running) since Wed 2022-07-13 23:40:25 -03; 9h ago
> Main PID: 971 (sssd)
> Tasks: 6 (limit: 38124)
> Memory: 55.9M
> CPU: 2.409s
> CGroup: /system.slice/sssd.service
> ├─ 971 /usr/sbin/sssd -i --logger=files
> ├─ 1030 /usr/libexec/sssd/sssd_be --domain files --uid 0 --gid 0 --logger=files
> ├─ 1035 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
> ├─ 1036 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --logger=files
> ├─ 1037 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
> └─ 1038 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files
>
> jul 13 23:40:24 munster.belkin.home systemd[1]: Starting sssd.service - System Security Services Daemon...
> jul 13 23:40:24 munster.belkin.home sssd[971]: Starting up
> jul 13 23:40:24 munster.belkin.home sssd_be[1030]: Starting up
> jul 13 23:40:24 munster.belkin.home sssd_ssh[1038]: Starting up
> jul 13 23:40:24 munster.belkin.home sssd_pam[1035]: Starting up
> jul 13 23:40:24 munster.belkin.home sssd_sudo[1036]: Starting up
> jul 13 23:40:24 munster.belkin.home sssd_nss[1037]: Starting up
> jul 13 23:40:25 munster.belkin.home systemd[1]: Started sssd.service - System Security Services Daemon.
> jul 13 23:40:41 munster.belkin.home sssd_nss[1037]: Enumeration requested but not enabled
> ```
>
> But recording sessions does not work.
>
> Relevant packages:
>
> ```
> sssd-2.7.3-1.fc36.x86_64
> tlog-12-2.fc36.x86_64
> fedora-release-common-36-17.noarch
> ```
>
> Please could you help me to figure out why session recording is not working?
>
> Thanks in advance!
>
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1 year, 4 months
Re: Can SSSD be set up to disallow login if provider not available?
by Alexey Tikhonov
Hi,
On Thu, Jul 7, 2022 at 12:14 PM Fisher, Philip <phil.fisher(a)dxc.com> wrote:
> Hi SSSD experts
>
> I have tried examining various documentation and man pages but I am unable
> to determine the answer. Specifically, for security reasons, we require
> user on our Linux servers to login via AD credentials only (unless they are
> a specific local user). In particular, if the provider is offline/not
> available (in this case an AD server/servers) then login should fail.
>
Sounds like `cache_credentials = false`? (see `man sssd.conf`)
>
> I thought it would be possible by setting various "cache" parameters but
> the documentation suggests that zero (0) is not a useful value.
>
> So, can this be done? And if so, how? And if I missed some simple thing
> in the documentation a reply pointing me to said documentation would be
> acceptable :-).
>
> Thanks.
> Phil
>
> --
> Phil J Fisher
> UNIX Technology Consultant
>
>
>
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates. It is intended
> exclusively for the addressee. The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate any part of this
> message. If you have received this message in error, please destroy and
> delete all copies and notify the sender by return e-mail. Regardless of
> content, this e-mail shall not operate to bind DXC Technology Company or
> any of its affiliates to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
1 year, 5 months
Can SSSD be set up to disallow login if provider not available?
by Fisher, Philip
Hi SSSD experts
I have tried examining various documentation and man pages but I am unable to determine the answer. Specifically, for security reasons, we require user on our Linux servers to login via AD credentials only (unless they are a specific local user). In particular, if the provider is offline/not available (in this case an AD server/servers) then login should fail.
I thought it would be possible by setting various "cache" parameters but the documentation suggests that zero (0) is not a useful value.
So, can this be done? And if so, how? And if I missed some simple thing in the documentation a reply pointing me to said documentation would be acceptable :-).
Thanks.
Phil
--
Phil J Fisher
UNIX Technology Consultant
DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
1 year, 5 months
