Re: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update
It's a two level domain. BTW. Something to add. It happens with an Ubuntu Zesty (17.04) client. This has freeipa 4.4.x while the rest of the network (and server) runs with freeipa 4.3.x On 15-04-17 17:29, Jake wrote: > is your "mydomain" actually a one level tld or example.com > > - Original Message - > From: "Kees Bakker" > To: "freeipa-users" > Sent: Thursday, April 13, 2017 10:30:33 AM > Subject: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain > in DHCP dyndns update > > Hey, > > Hopefully someone here can hint me towards a (easier) solution. > > In short, for correct DHCP-DDNS updates there should be a non-fqdn in > /etc/hostname > To install IPA client I am forced to have a fqdn in /etc/hostname. But now > the DHCP-DDNS > results in duplicated domain portion of the DNS entries. > > The details. > We have a FreeIPA environment with DNS and DHCP. I've configured bind and > dhcpd to do DDNS. For the most part it is working as expected. > > When the hostname of a system is a non-fqdn the end result is what I want to > see. Say I have > /etc/hostname: test02 > then after it started up there is a new forward map (using "mydomain" here > instead of the real thing). >test01 -> 172.16.16.252 > and a reverse map in 16.16.172.in-addr.arpa zone >252 -> test02.mydomain > > Some lines from /var/log/syslog > dhcpd[82333]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via > eno1 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating > zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252 > dhcpd[82333]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from > 00:16:3e:8e:91:12 (test02) via eno1 > dhcpd[82333]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating > zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID > AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE= > dhcpd[82333]: Added new forward map from test02.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating > zone '16.16.172.in-addr.arpa/IN': adding an RR at > '252.16.16.172.in-addr.arpa' PTR test02.mydomain. > dhcpd[82333]: Added reverse map from 252.16.16.172.in-addr.arpa. to > test02.mydomain > > However, when I want to add this system as a IPA client I am forced to > fill in a fqdn in /etc/hostname. So I change /etc/hostname to have > test01.mydomain > The provisioning succeeds and all seems well. > > But after a reboot the system requests DHCP to register as test01.mydomain. > And > the DHCP server does a DNS update for test01.mydomain.mydomain. > The DNS zone for mydomain now has > test01 for all the SSHFP records > test01.mydomain for the A record > The reverse map for 16.16.172.in-addr.arpa has > 231 -> test01.mydomain.mydomain > > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': deleting an RR at test02.mydomain A > dhcpd[4550]: DHCPREQUEST for 172.16.16.252 from 00:16:3e:8e:91:12 (test02) > via eno1 > dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02.mydomain) > via eno1 > dhcpd[4550]: Removed forward map from test02.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': deleting an RR at test02.mydomain DHCID > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' A 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' DHCID > AAAB+5EmVxuf4utDMDZxjqAiqIds6Briv5awEp5W3whNsLc= > dhcpd[4550]: Added new forward map from test02.mydomain.mydomain to > 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone '16.16.172.in-addr.arpa/IN': adding an RR at > '252.16.16.172.in-addr.arpa' PTR test02.mydomain.mydomain. > dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to > test02.mydomain.mydomain > > > To work around I then change the /etc/hostname back to test01, restart > the network and everything if fine afterwards. > > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain A > dhcpd[4550]: DHCPRELEASE of 172.16.16.252 from 00:16:3e:8e:91:12 > (test02.mydomain) via eno1 (found) > dhcpd[4550]: Removed forward map from test02.mydomain.mydomain to > 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain DHCID > dhcpd[4550]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating > zone 'mydomain/IN': update unsuccessful: test02.mydomain: 'name not in use' >
[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 command
[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