[Freeipa-users] Freeipa web UI: An error has occurred (IPA Error 4302: CertificateFormatError)
Many hosts in our web ui show a null status for “enrolled”. When you do a search that includes any of these host objects the web UI posts errors, and if you click on one of the problem hosts the same error stops anything from loading on the host page. I’ve been trying to solve this problem on my own for quite some time and have not been successful. It’s impossible to remove the host through the web UI and using CLI commands seem to remove the entry from IPA (host is not found with ipa host-find), but it is still visible in the UI. One thing that may be common with all of these hosts is that they were enrolled with our IPA system back while we were running version 3.0 and likely have had issues for quite some time. Multiple updates have happened since then, and all of our hosts added within the last year are working fine. I suspect there’s an issue with a path somewhere for a certificate database, but I’m unable to pinpoint what is going wrong. I’m currently cloning 2 of my IPA servers into a private dmz to test fixes so I can try things without worry... 1. Realized we had many certificates that were expired and not renewing with “getcert list” on primary IPA server 2. Tried every document I could find on renewing the certificates but was never completely successful (on version 4.1 which is our current in production) 3. Upgraded to 4.4 and was actually able to renew all certificates listed on the main IPA server showing current below 4. After having success with #3 I was able to start the CA service without error and everything on the server seems to be working as expected 5. Have attempted many variations of removing a problem host and adding it back, but the errors in the web UI persist. Output from "getcert list": Number of certificates and requests being tracked: 8. Request ID '20160901214852': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=CA Audit,O=DOMAIN.COM expires: 2018-08-22 22:13:44 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160901214853': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=OCSP Subsystem,O=DOMAIN.COM expires: 2018-08-22 21:49:26 UTC eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160901214854': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=CA Subsystem,O=DOMAIN.COM expires: 2018-08-22 21:49:18 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160901214855': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=Certificate Authority,O=DOMAIN.COM expires: 2036-09-01 05:05:00 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save
[Freeipa-users] Repair a corrupted database
Hi List, I've got two boxes running FreeIPA 4.1.4. The Database on the first master is corrupted. Log looks like this: [17/Apr/2017:10:22:51 -0400] - libdb: BDB0689 changelog/id2entry.db page 27523 is on free list with type 5 [17/Apr/2017:10:22:51 -0400] - libdb: BDB0061 PANIC: Invalid argument [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_abort, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] DSRetroclPlugin - replog: an error occured while adding change number 8485210, dn = changenumber=8485210,cn=changelog: Operations error. [17/Apr/2017:10:22:51 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_begin, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - FATAL ERROR at idl_new.c (1); server stopping as database recovery needed. Looks like it's broken. Good news is I have a replica that's working quite well. What I'd like to do is to recover the database or create a new database on the first master and then just fill it with the current data from the replica. Is this possible? As a lazy admin I'm hoping to avoid making the replica the CA and building a new replica. Can someone point me to a guide, docs or walk me through the procedure? Thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Admin cannot retrieve keytab -- is that expected?
On Mon, Apr 17, 2017 at 04:49:59PM +0300, Alexander Bokovoy wrote: > On Mon, 17 Apr 2017, Jan Pazdziora wrote: > > > > Hello, > > > > on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve > > new keytab for a service but they cannot retrieve the existing keys > > with the -r option. Is that expected? > Yes. Access to existing keys is intentionally restricted. There are > additional commands that allow to set up how to grant such access based > on the management of a service. There is no way to set up a blank > permission for that, though, as permission is based on the specific > attributes in the service entry. > > # ipa service-add foobar/$(hostname) > -- > Added service "foobar/nyx.xs.ipa.c...@xs.ipa.cool" > -- > Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Managed by: nyx.xs.ipa.cool > > # ipa service-allow-retrieve-keytab foobar/$(hostname) --groups=admins > Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Managed by: nyx.xs.ipa.cool > Groups allowed to retrieve keytab: admins > - > Number of members added 1 > - > > # ipa service-show foobar/$(hostname) --all --raw|grep ipaAllowedToPerform > ipaAllowedToPerform;read_keys: > cn=admins,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Admin cannot retrieve keytab -- is that expected?
On Mon, 17 Apr 2017, Jan Pazdziora wrote: Hello, on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve new keytab for a service but they cannot retrieve the existing keys with the -r option. Is that expected? Yes. Access to existing keys is intentionally restricted. There are additional commands that allow to set up how to grant such access based on the management of a service. There is no way to set up a blank permission for that, though, as permission is based on the specific attributes in the service entry. # ipa service-add foobar/$(hostname) -- Added service "foobar/nyx.xs.ipa.c...@xs.ipa.cool" -- Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool Managed by: nyx.xs.ipa.cool # ipa service-allow-retrieve-keytab foobar/$(hostname) --groups=admins Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool Managed by: nyx.xs.ipa.cool Groups allowed to retrieve keytab: admins - Number of members added 1 - # ipa service-show foobar/$(hostname) --all --raw|grep ipaAllowedToPerform ipaAllowedToPerform;read_keys: cn=admins,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool This is all documented very well: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/retrieve-existing-keytabs.html -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Admin cannot retrieve keytab -- is that expected?
Hello, on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve new keytab for a service but they cannot retrieve the existing keys with the -r option. Is that expected? # kdestroy -A # kinit admin Password for ad...@example.test: # ipa host-add test1.example.test --force --- Added host "test1.example.test" --- Host name: test1.example.test Principal name: host/test1.example.t...@example.test Principal alias: host/test1.example.t...@example.test Password: False Keytab: False Managed by: test1.example.test # ipa service-add HTTP/test1.example.test --force Added service "HTTP/test1.example.t...@example.test" Principal name: HTTP/test1.example.t...@example.test Principal alias: HTTP/test1.example.t...@example.test Managed by: test1.example.test # ipa-getkeytab -p HTTP/test1.example.test -k /tmp/http.keytab Keytab successfully retrieved and stored in: /tmp/http.keytab # ipa-getkeytab -r -p HTTP/test1.example.test -k /tmp/http.keytab.1 Failed to parse result: Insufficient access rights Failed to get keytab # -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
