July 2022 - FreeIPA-users - Fedora mailing-lists

who killed SSSD - ?
by lejeczek 21 Jul '22

21 Jul '22

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.

4 3

ssh key issues
by Andrew Meyer 21 Jul '22

21 Jul '22

I recently cleaned up a few server in my home lab. Deleted servers that I no longer needed. However It seems I have a server with an IP address that used previously. FreeIPA is reporting that it is in /var/lib/sss/pubconf/known_hosts but I can't reverse engineer the hostname by doing sshkey -R 1.2.3.4. I have run into this issue previously but it has bee quite some time. When I go to delete the line from /var/lib/sss/pubconf/known_hosts it is gone. If someone could help me that would be great. I didn't see anything on my FreeIPA master that indicated I did anything there.

5 12

Date range
by Jim Kinney 20 Jul '22

20 Jul '22

Is there a way to use a date range with the cli? Specifically trying to extract a list of users with password expiration between next Monday and next Friday. The ipa user-find --password-expiration= is a literal equals. And it's really specific down to the second. Can do this with external scripting but if there's a way use ipa first, that's preferred. -- Computers amplify human error Super computers are really cool

3 5

Could not login with AD user
by Ronald Wimmer 20 Jul '22

20 Jul '22

Today I was not able to log in with an AD user to an IPA client within a test setup. IPA users worked fine. DNS is managed externally. I figured out that the DNS-Record of that particular IPA client has not been created correctly. After having corrected the DNS entry and having dropped the SSSD cache on that client I could login with my AD user. Do you have an explanation for that or was it just a coincidence? Cheers, Ronald

4 13

RHEL9 Replica Install fail at 22/30 Importing RA key
by Ivars Strazdins 20 Jul '22

20 Jul '22

Hi guys, I am installing IPA replica on RHEL9 (well, Alma Linux 9 actually) and got exactly the same issue as here: https://access.redhat.com/discussions/6961739 <https://access.redhat.com/discussions/6961739> And similarly to the poster of that issue, also my IPA master server is IPA 4.6.8 on Centos7. I was trying to migrate IPA to a newer version by using Alma Linux 9. I removed Centos 7 replica and tried to install Alma Linux 9 replica. IPA client was installed without issues. No SELinux alerts. Content of /var/lib/ipa folder: [root@fricka ~]# ls /var/lib/ipa backup certs gssproxy passwds pki-ca private ra-agent.pem sysrestore sysupgrade Any suggestions how this could be resolved? Thank you in advance, Ivars Log of replica install: …. Starting replication, please wait until this has completed. Update in progress, 9 seconds elapsed Update succeeded [3/30]: creating ACIs for admin [4/30]: creating installation admin user [5/30]: configuring certificate server instance [6/30]: stopping certificate server instance to update CS.cfg [7/30]: backing up CS.cfg [8/30]: Add ipa-pki-wait-running [9/30]: secure AJP connector [10/30]: reindex attributes [11/30]: exporting Dogtag certificate store pin [12/30]: disabling nonces [13/30]: set up CRL publishing [14/30]: enable PKIX certificate path discovery and validation [15/30]: authorizing RA to modify profiles [16/30]: authorizing RA to manage lightweight CAs [17/30]: Ensure lightweight CAs container exists [18/30]: Ensuring backward compatibility [19/30]: destroying installation admin user [20/30]: starting certificate server instance [21/30]: Finalize replication settings [22/30]: configure certmonger for renewals [23/30]: Importing RA key Error storing key "keys/ra/ipaCert": CalledProcessError(Command ['/usr/libexec/ipa/custodia/ipa-custodia-ra-agent', '--import', '-'] returned non-zero exit status 1: 'Traceback (most recent call last):\n File "/usr/libexec/ipa/custodia/ipa-custodia-ra-agent", line 8, in <module>\n main(ra_agent_parser())\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", line 114, in main\n common.main(parser, export_key, import_key)\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/common.py", line 73, in main\n func(args, tmpdir, **kwargs)\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", line 69, in import_key\n ipautil.run(cmd, umask=0o027)\n File "/usr/lib/python3.9/site-packages/ipapython/ipautil.py", line 598, in run\n raise CalledProcessError(\nipapython.ipautil.CalledProcessError: CalledProcessError(Command [\'/usr/bin/openssl\', \'pkcs12\', \'-in\', \'/tmp/tmp5koo8ca2/import.p12\', \'-clcerts\', \'-nokeys\', \'-out\', \'/var/lib/ipa/ra-agent.pem\', \'-password\', \'file:/tmp/tmp5koo8ca2/passwd\'] returned non-zero exit status 1: \'Error outputting keys and certificates\\n802B104A807F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()\\n\')\n') [error] FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/ipa/ra-agent.key' Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [Errno 2] No such file or directory: '/var/lib/ipa/ra-agent.key' The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

3 4

FreeIPA Client <--> AD / Kerberos
by Ronald Wimmer 19 Jul '22

19 Jul '22

In which scenarios do I need IPA clients to be able to connect to Windows AD DCs directly (Kerberos 44/464 TCP/UDP)? I thought it was needed for passwordless logins because https://access.redhat.com/webassets/avalon/d/Red_Hat_Enterprise_Linux-8-Ins… says Kerberos. Jakubs blog post https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-… says "For password-based authentication requests, the IPA clients connect directly to the AD servers using Kerberos." Will I lose the ability to log in password-based if these ports are blocked by the firewall? Cheers, Ronald

1 0

RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (500)
by roy liang 19 Jul '22

19 Jul '22

> Hi, > > On Fri, Jul 15, 2022 at 8:28 AM roy liang via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> wrote: > > file > /var/run/ipa/renewal.lock that is used as cross-process lock and may > block the renewal. When the lock is not taken, its content looks like the > following: > # cat /var/run/ipa/renewal.lock > [lock] > locked = 0 > > The lock is taken for 1hour max and its expiration date is written in the > file, with the owner process as well. This means that even if something > went wrong (a renewal failing), your system will resume the renewal of the > other certs after one hour. > > We used to have an issue with renewals being blocked unnecessarily during > certmonger restart (https://pagure.io/freeipa/issue/8425) and it has been > fixed in IPA 4.8.9+. IIRC your version is older and you may be affected. In > this case, the workaround is to delete the lock file. > > flo > > 28172 root 20 0 228032 36424 12876 S 0.0 0.0 0:00.62 Thank you very much! rm -rf /var/run/ipa/renewal.lock After that, it did go well, but the status changed to CA_UNREACHABLE. I repeated getCert resubmit -i all expired ID for many times, but I still couldn't renew the certificate. Can you help analyze the reason?What else might I need to do? repeated getCert resubmit -i xx root@ipa-test-65-199:/var/log/pki# getcert list |egrep 'Request|status|expires' Request ID '20200509160847': status: MONITORING expires: 2022-04-29 16:08:24 UTC Request ID '20200509160848': status: MONITORING expires: 2022-04-29 16:08:23 UTC Request ID '20200509160849': status: MONITORING expires: 2022-04-29 16:08:24 UTC Request ID '20200509160850': status: MONITORING expires: 2040-05-09 16:08:22 UTC Request ID '20200509160851': status: MONITORING expires: 2022-04-29 16:08:44 UTC Request ID '20200509160852': status: MONITORING expires: 2022-04-29 16:08:23 UTC Request ID '20200509160914': status: CA_UNREACHABLE expires: 2022-05-10 16:09:13 UTC Request ID '20200509160938': status: CA_UNREACHABLE expires: 2022-05-10 16:09:38 UTC root@ipa-test-65-199:/var/log/pki# getcert list |egrep 'Request|status|expires|ca-error' Request ID '20200509160847': status: MONITORING expires: 2022-04-29 16:08:24 UTC Request ID '20200509160848': status: MONITORING expires: 2022-04-29 16:08:23 UTC Request ID '20200509160849': status: MONITORING expires: 2022-04-29 16:08:24 UTC Request ID '20200509160850': status: MONITORING expires: 2040-05-09 16:08:22 UTC Request ID '20200509160851': status: MONITORING expires: 2022-04-29 16:08:44 UTC Request ID '20200509160852': status: MONITORING expires: 2022-04-29 16:08:23 UTC Request ID '20200509160914': status: CA_UNREACHABLE ca-error: Server at https://ipa-test-65-199.hiido.host.yydevops.com/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (500)). expires: 2022-05-10 16:09:13 UTC Request ID '20200509160938': status: CA_UNREACHABLE ca-error: Server at https://ipa-test-65-199.hiido.host.yydevops.com/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (500)). expires: 2022-05-10 16:09:38 UTC root@ipa-test-65-199:/var/log/pki# date -R Thu, 28 Apr 2022 00:16:51 +0800

3 6

SSSD prompting/2fa
by Sigbjorn Lie 16 Jul '22

16 Jul '22

Hi list, When I have a 2FA enabled user account, I receive the two password prompt for sudo at a host, even on hosts where 2FA is not required. This breaks Ansible for me, when using "become" with Ansible. I am testing the [prompting/2fa] options in sssd to remediate this. I have the following configuration: --- [prompting/2fa/sudo] first_prompt = 'Please enter your password and optional OTP token value: ' single_prompt = True --- This provides me with a single prompt, with the configured text when I run sudo on this host. However the 2FA OTP code is no longer optional. If I do not enter both my password and an OTP code, the authentication fails. So still this does not fix Ansible for me. From var/log/secure: --- Jun 3 09:15:16 myhost.mydomain.tld sudo[2289804]: pam_sss(sudo:auth): authentication failure; logname=myusername uid=12345678 euid=0 tty=/dev/pts/1 ruser= myusername rhost= user= myusername Jun 3 09:15:16 myhost.mydomain.tld sudo[2289804]: pam_sss(sudo:auth): received for user myusername: 7 (Authentication failure) Jun 3 09:15:18 myhost.mydomain.tld sudo[2289804]: myusername : 1 incorrect password attempt ; TTY=pts/1 ; PWD=/home/myusername ; USER=root ; COMMAND=list --- The only change performed is to add the above prompting configuration to sssd.conf. If I remove the prompting configuration from sssd.conf, I can now authentiate using only my password, even though with two prompts. In either way, I am unable to run Ansible anymore. Any suggestions on how to fix this? Regards, Siggi

6 11

Port 389 on IPA servers
by Ronald Wimmer 16 Jul '22

16 Jul '22

The official RedHat doumentation states > The TCP port 389 is not required to be open on IdM servers for trust, but it is necessary for clients communicating with the IdM server. Is this still true? Or could LDAPS/Port 636 be used as well? Cheers, Ronald

5 5

After the server time rollback, the state is stuck in the submit state
by roy liang 15 Jul '22

15 Jul '22

It's been stuck all day #service certmonger restart getcert list | egrep 'status|Request' Request ID '20200609161251': status: SUBMITTING Request ID '20200609161252': status: SUBMITTING Request ID '20200609161253': status: SUBMITTING Request ID '20200609161254': status: MONITORING Request ID '20200609161255': status: SUBMITTING Request ID '20200609161256': status: SUBMITTING Request ID '20200609161317': status: SUBMITTING Request ID '20200609161342': status: SUBMITTING 28172 root 20 0 228032 36424 12876 S 0.0 0.0 0:00.62 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28125 root 20 0 228028 36376 12828 S 0.0 0.0 0:00.59 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28132 root 20 0 228028 36364 12832 S 0.0 0.0 0:00.65 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28143 root 20 0 228028 36356 12808 S 0.8 0.0 0:00.68 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28170 root 20 0 228040 36356 12800 S 0.0 0.0 0:00.63 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28145 root 20 0 228028 36344 12804 S 0.0 0.0 0:00.67 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28142 root 20 0 228028 36324 12776 S 0.0 0.0 0:00.64 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28144 root 20 0 228028 36320 12784 S 0.0 0.0 0:00.64 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28146 root 20 0 228028 36300 12760 S 0.0 0.0 0:00.66 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28147 root 20 0 228028 36288 12744 S 0.0 0.0 0:00.67 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28126 root 20 0 228028 36280 12732 S 0.0 0.0 0:00.54 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28141 root 20 0 228028 36252 12708 S 0.0 0.0 0:00.64 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28148 root 20 0 228028 36232 12684 S 0.0 0.0 0:00.66 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/dogtag-ipa-renew-agent-submit 28129 root 20 0 228028 36212 12672 S 0.0 0.0 0:00.60 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28171 root 20 0 228024 36192 12636 S 0.0 0.0 0:00.62 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28127 root 20 0 228024 36172 12636 S 0.0 0.0 0:00.58 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28131 root 20 0 228028 36164 12620 S 0.0 0.0 0:00.62 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28130 root 20 0 228028 36152 12616 S 0.8 0.0 0:00.61 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit 28128 root 20 0 228028 36128 12584 S 0.0 0.0 0:00.57 /usr/bin/python2 -E /usr/lib/certmonger/ipa-server-guard /usr/lib/certmonger/ipa-submit root@ipa-ca-65-197:/home/liangrui# strace -p 28130 strace: Process 28130 attached select(0, NULL, NULL, NULL, {6, 426367} ) = 0 (Timeout) open("/var/run/ipa/renewal.lock", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 flock(3, LOCK_EX) = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 lseek(3, 0, SEEK_SET) = 0 read(3, "[lock]\nlocked = 1\nowner = ipa-se"..., 4096) = 81 read(3, "", 4096) = 0 close(3) = 0 select(0, NULL, NULL, NULL, {10, 0}) = 0 (Timeout) open("/var/run/ipa/renewal.lock", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 flock(3, LOCK_EX) = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 lseek(3, 0, SEEK_SET) = 0 read(3, "[lock]\nlocked = 1\nowner = ipa-se"..., 4096) = 81 read(3, "", 4096) = 0 close(3) = 0 select(0, NULL, NULL, NULL, {10, 0}) = 0 (Timeout) open("/var/run/ipa/renewal.lock", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 flock(3, LOCK_EX) = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 lseek(3, 0, SEEK_SET) = 0 read(3, "[lock]\nlocked = 1\nowner = ipa-se"..., 4096) = 81 read(3, "", 4096) = 0 close(3) = 0 select(0, NULL, NULL, NULL, {10, 0}) = 0 (Timeout) open("/var/run/ipa/renewal.lock", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 flock(3, LOCK_EX) = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=81, ...}) = 0 lseek(3, 0, SEEK_SET) = 0 read(3, "[lock]\nlocked = 1\nowner = ipa-se"..., 4096) = 81 read(3, "", 4096) = 0 close(3) = 0 select(0, NULL, NULL, NULL, {10, 0}^Cstrace: Process 28130 detached <detached ...>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2022