kpi-tomcatd failing to start
by girish f
I have IPA setup long back.
Some of the certificates expired. So i went back in time and then it's working super smooth.
When i did ipa-cert-fix --> error is Server-Cert not found
I renewed kerberos kdc.key kdc.crt.
But still it's failing to start the kpi_tomcatd. When i check status of kpi-tomcatd@kpi-tomcatd it shows running, but service starts to fail when
i come back to current time and restart ipactl restart.
need urgent help please
18 hours, 43 minutes
Remove bad replica nodes from list
by Satish Patel
Folks,
I am trying to build some replicas and somehow they failed but because they
are half baked they are stuck in master nodes and not letting me remove
them. I have tried all the options and don't know how to get rid of them.
I want to remove ldap-vx-010103-1.site5.example.com and
ldap-vx-010103-2.site5.example.com. I have removed them from topology and
from host and hostgroup ipaservers list but no luck. I have totally shut
down replicas nodes but still no luck. Are there any good ways to clean
them up?
[root@ldap-vx-010101-4 ~]# ipa-replica-manage list -v `hostname`
ldap-vx-010101-1.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-2.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-3.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-5.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010103-1.site5.example.com: replica
last init status: Error (0)
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (-1) Problem connecting to replica - LDAP
error: Can't contact LDAP server (connection error)
last update ended: 2024-05-11 10:30:33+00:00
ldap-vx-010103-2.site5.example.com: replica
last init status: Error (0) Total update succeeded
last init ended: 2024-05-10 20:35:02+00:00
last update status: Error (-1) Problem connecting to replica - LDAP
error: Can't contact LDAP server (connection error)
last update ended: 1970-01-01 00:00:00+00:00
ldap-vx-010103-3.site5.example.com: replica
last init status: Error (0) Total update succeeded
last init ended: 2024-05-10 21:14:53+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
1 day, 1 hour
[freeipa][ca] Changing IP of CA replica
by Satish Patel
Folks,
Is changing the IP address possible for a CA replica? I am having a hard
time creating new CA replicas so to buy sometime I would like to change the
IP address of the CA replica if it's easy.
I have external DNS, we don't use freeIPA based DNS and all certs are
self-sign.
~S
3 days, 13 hours
when 2FA enabled, with 2 factor prompt asking doesn't work
by seojeong kim
on server side, ipauserauthtype set as password + otp.
[root@xxxxxx /]# ipa user-show ereen-test --raw | grep ipauserauthtype
ipauserauthtype: password
ipauserauthtype: otp
And I added new configuration in /etc/ssh/sshd_config on my host which is ipa client is installed.
GSSAPIAuthentication yes
And /etc/sssd/sssd.conf
[prompting/password/sshd]
password_prompt = password :
[prompting/2fa/sshd]
first_prompt = first pwd :
second_prompt = second otp :
But all the time, when I try ssh login with ereen-test, the prompt asks "password :"
I expect 2 factor asking as I configured like below
first_prompt :
second_prompt :
Is there other configuration should I set more ?
4 days, 4 hours
vulnerability on port 8443 reported by Nessus scanner- caSigningCert cert-pki-ca
by Polavarapu Manideep Sai
Hi Team,
I have a vulnerability on port 8443 reported by Nessus scanner
I have third-party certificate already installed at LDAP and Apache services
I have root and intermediate certificate also installed on pki-tomcat service as shown below
The certificate "caSigningCert cert-pki-ca" which is causing this vulnerability
Any Suggestions to overcome this issue?
[root@aaa01 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert cert-pki-ca' |egrep -i 'Issuer:|Subject:'
Issuer: "CN=Certificate Authority,O=IPA.EXAMPLE.COM"
Subject: "CN=Certificate Authority,O=IPA.EXAMPLE.COM"
[root@aaa01 ~]# certutil -L -d /etc/dirsrv/slapd-IPA-EXAMPLE-COM/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
CN=*.IPA.EXAMPLE.COM u,u,u
IPA.EXAMPLE.COM IPA CA CT,C,C
NSS Certificate DB:NSS Certificate DB:CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group\, Inc.,C=US CT,C,C
[root@aaa01 ~]#
[root@aaa01 ~]#
[root@aaa01 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
ocspSigningCert cert-pki-ca u,u,u
Server-Cert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
NSS Certificate DB:NSS Certificate DB:CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group\, Inc.,C=US CT,C,C
Scanning Report and Solution Given:
8443 SSL Certificate Cannot Be Trusted The SSL certificate for this service cannot be trusted.
8443 SSL Self-Signed Certificate "The SSL certificate chain for this service ends in an unrecognized
self-signed certificate."
Solution:
Purchase or generate a proper SSL certificate for this service.
Regards
Sai
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
4 days, 14 hours
pki-tomcatd service stopped
by Natxo Asenjo
hi,
after a botched update (https://access.redhat.com/solutions/7065748) and
rolling back the changes, this service will not start:
# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
1 service(s) are not running
in journalctl I found this stdout/stderr messages:
May 24 11:40:35 kdc1.sub.domain.tld named[27437]: zone sub.domain.tld/IN:
sending notifies (serial 1716543629)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: ERROR: Unable to
parse version number: "11.5.0"
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Traceback (most
recent call last):
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/pkiserver.py", line 41, in
<module>
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
cli.execute(sys.argv)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/__init__.py", line 145, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
super().execute(args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/cli/__init__.py", line 217, in execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
module.execute(module_args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 144, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: self.upgrade(
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 178, in
upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
upgrader.upgrade()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 481, in upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: versions =
self.versions()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 238, in versions
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_current_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 341, in
get_current_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_tracker().get_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 141, in get_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: return
pki.util.Version(version)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/util.py", line 613, in __init__
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: raise
Exception('Unable to parse version number: %s' % obj)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Exception: Unable to
parse version number: "11.5.0"
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd(a)pki-tomcat.service: Control process exited, code=exited,
status=1/FAILURE
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd(a)pki-tomcat.service: Failed with result 'exit-code'.
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: Failed to start PKI Tomcat
Server pki-tomcat.
So it seems something is broken on this upgrade script. This is in in
almalinux 9.3
ipa-server-4.10.2-5.el9_3.alma.1.x86_64
I cannot upgrade because I get bitten by the named ldap thing, even though
the versions are newer.
I will create a replicat to a rhel host but first I need to get the CA up
and running obviously :-).
Any ideas?
Thanks!
--
regards,
natxo
--
--
Groeten,
natxo
4 days, 17 hours
Possible to adjust generated salt size for CRYPT-SHA512 passwords?
by Jason Borden
Greetings all,
I'm pretty new to FreeIPA and would like to know if I can adjust the salt size generated by FreeIPA when using CRYPT-SHA512 as the passwordStorageScheme.
After modifying the cn=config to use CRYPT-SHA512 passwords by default, new passwords are correctly generated using CRYPT-SHA512, however the size of the salt is tiny (only 2 base64 chars or about 12bits). I'd really like to configure FreeIPA to generate a larger salt, but I'm not sure if that's possible.
Just for background on why I've chosen to use CRYPT-SHA512 instead of the standard PBKDF2-SHA256 is because I intend to sync the password hashes in FreeIPA to a system we have that neither supports LDAP or Kerberos: postfixadmin. Postfixadmin supports CRYPT-SHA512 hashes but not PBKDF2-SHA256.
Thanks,
Jason
5 days, 17 hours
Recommended resolv.conf / hosts file
by David Harvey
Hi FreeIPA users,
I nested this under a related topic before (subject: Replica
re-initialization failing Replication bind with GSSAPI auth failed: LDAP
error 49 (Invalid credentials) () ) but it was admittedly a bit off topic...
Is configuring resolv.conf with the single resolver 127.0.0.1 the blessed /
recommended setup?
We've had some chicken and egg situations recently where dirsrv being sad
has broken local DNS resolution, and then krb behaviours and lookup for the
other IPA servers has been impaired as a result.
If solely using local bind / loopback in resolv.conf is the recommended
state, should we be putting the other IPA servers in /etc/hosts or anything
to make sure they can identify one and other in the case of dirsrv sadness?
Thanks in advance,
David
5 days, 20 hours
FreeIPA - Need help with Expired Certificate
by azeem
Hello!
I have inherited a FreeIPA server, and upon checking the certificate list with getcert list, it shows that the certificate is already expired. Does anyone know how to renew it? And coz of this issue, I am not able to enroll any any clients. Any help would be appreciated.
Request ID '20160825909273':
status: CA_UNREACHABLE
ca-error: Server at https://test.domain.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://test.domain.com:443/ca/eeca/ca/profileSubmitSSLClient': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: no
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-TEST-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-TEST-DOMAINCOM/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-TEST-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TEST-DOMAIN-COM
subject: CN=test.domain.com,O=TEST.DOMAIN.COM
expires: 2023-12-18 15:52:08 UTC
principal name: ldap/test.domain.com(a)TEST.DOMAIN.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv TEST.DOMAIN.COM
track: yes
auto-renew: yes
6 days, 13 hours
AllowUsers/Groups on ipa clients
by Sam Morris
On non-IPA clients I'm using AllowUsers/AllowGroups to restrict which
local users are able to SSH into a system.
On IPA clients I am using HBAC to control the same for IPA users. But
what's the best way to control which local users can SSH in to an IPA
client?
It looks like I could modify the ipausers group to be a POSIX group, and
then put 'AllowGroups ipausers' into sshd_config. That way all local
users would be denied, and all IPA suers would be allowed, with
pam_sss.so later controlling access based on HBAC.
Alternatively modifying PAM services to use pam_access.so and/or to
remove pam_localuser.so could work, but that seems a lot more
complicated, since the system-auth PAM config is managed by authselect,
and is included by all sorts of other services...
Are there any better alternatives?
Hm, now that I think about it, I'd like to be doing this for cockpit as
well. I suppose pam_wheel or pam_succeed_if can be used in
/etc/pam.d/cockpit, together with a POSIX ipausers group for this purpose.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
6 days, 16 hours
