ssh key issues
by Andrew Meyer
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.
1 year, 9 months
Date range
by Jim Kinney
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
1 year, 9 months
Could not login with AD user
by Ronald Wimmer
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
1 year, 9 months
RHEL9 Replica Install fail at 22/30 Importing RA key
by Ivars Strazdins
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
1 year, 9 months
RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (500)
by roy liang
> 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
1 year, 9 months
SSSD prompting/2fa
by Sigbjorn Lie
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
1 year, 9 months
Port 389 on IPA servers
by Ronald Wimmer
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
1 year, 9 months
After the server time rollback, the state is stuck in the submit state
by roy liang
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 ...>
1 year, 9 months
ipa-healthcheck Error - how to remove an old replica in pki DB ?
by Kathy Zhu
Hi Team,
We are migrating from Centos 7 IPA to Red Hat 8.6. After adding the first
Red Hat master, it reported error:
# ipa-healthcheck
--source=pki.server.healthcheck.clones.connectivity_and_data
Internal server error HTTPSConnectionPool(host='ipa4.example.com',
port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3
(Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection
object at 0x7f0611b6d5c0>: Failed to establish a new connection: [Errno -2]
Name or service not known',))
[
{
"source": "pki.server.healthcheck.clones.connectivity_and_data",
"check": "ClonesConnectivyAndDataCheck",
"result": "ERROR",
"uuid": "bfb9aeac-2e86-4d1d-ac2a-3cb62300527e",
"when": "20220711221016Z",
"duration": "0.768881",
"kw": {
"status": "ERROR: pki-tomcat : Internal error testing CA clone.
Host: ipa4.example.com Port: 443"
}
}
]
#
ipa4 was a master we had years ago. it did not show up as a dangling master
in the domain. However, it remains in pki DB. How to safely clean it out
from pki DB?
Another interesting fact I like to point out - Centos 7 ipa-healthcheck
does not report this.
Thanks!
Kathy.
1 year, 9 months