November 2022 - FreeIPA-users - Fedora mailing-lists

ipa-restore in docker container
by Simon Thorley 09 Dec '22

09 Dec '22

Hi all, I am currently migrating a server from a locally installed FreeIPA setup to a CoreOS container setup and cannot find any documentation for this. I am assuming i am doing something wrong or missing something as i cannot find anyone else having an issue or even attempting it either. This is a fresh installed OS from an ignition file so should have no weirdness coming in from anywhere else. podman launch line: bin/podman run --name ipa \ -h thenom-srv1.thenom.local --read-only \ -v /var/lib/ipa-data:/data:Z \ -e IPA_SERVER_IP=192.168.101.6 \ -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp \ quay.io/freeipa/freeipa-server:fedora-36 I have finally got a fresh install running in a container but i am now trying to restore a backup into it from my old server. I have copied a ipa-full directory from my old service into the containers data volume folder on the host. I bash exec into the running IPA container then run ipa-restore /data/ipa-full-2022-11-11-04-03-19, type in my directory manager password and accept the prompts then just get a mass stream of tar errors and then fail: ... tar: setfileconat: Cannot set SELinux context for file 'var/lib/ipa/pki-ca': Permission denied tar: var/lib/ipa: Directory renamed before its status could be extracted tar: setfileconat: Cannot set SELinux context for file 'var/lib/pki/pki-tomcat/lib': Permission denied tar: setfileconat: Cannot set SELinux context for file 'var/lib/pki/pki-tomcat/ca': Permission denied tar: setfileconat: Cannot set SELinux context for file 'var/lib/pki/pki-tomcat': Permission denied tar: var/lib/pki: Directory renamed before its status could be extracted tar: etc/httpd/alias: Directory renamed before its status could be extracted tar: setfileconat: Cannot set SELinux context for file 'etc/pki/pki-tomcat/ca': Permission denied tar: etc/pki/pki-tomcat: Directory renamed before its status could be extracted tar: Exiting with failure status due to previous errors Restoring umask to 18 NSS is built without support of the legacy database(DBM) directory '/etc/ipa/nssdb' The ipa-restore command failed. See /data/var/log/iparestore.log for more information I get similar in the iparestore.log: ... tar: setfileconat: Cannot set SELinux context for file './THENOM-LOCAL/DBVERSION': Operation not supported tar: setfileconat: Cannot set SELinux context for file './THENOM-LOCAL/dse_instance.ldif': Operation not supported tar: setfileconat: Cannot set SELinux context for file './THENOM-LOCAL/dse_index.ldif': Operation not supported tar: setfileconat: Cannot set SELinux context for file './THENOM-LOCAL': Operation not supported tar: setfileconat: Cannot set SELinux context for file './files.tar': Operation not supported tar: setfileconat: Cannot set SELinux context for file '.': Operation not supported 2022-11-13T11:55:38Z DEBUG Starting external process 2022-11-13T11:55:38Z DEBUG args=['tar', '--xattrs', '--selinux', '-xzf', '/tmp/tmp7pt67l7sipa/ipa/files.tar', 'etc/ipa/default.conf'] 2022-11-13T11:55:40Z DEBUG Process finished, return code=0 2022-11-13T11:55:40Z DEBUG stdout= 2022-11-13T11:55:40Z DEBUG stderr=tar: setfileconat: Cannot set SELinux context for file 'etc/ipa/default.conf': Operation not supported This seems to make sense because from what i have read the selinux context on these /data files should be system_u:object_r:container_file_t and i am guessing unchanged\unchangeable due to the environment its running in. Any advice appreciated, thanks in advance. Simon

2 4

HTTP certificate expired
by Juan Pablo Lorier 05 Dec '22

05 Dec '22

Hi, I have a production server that was not maintained and I see that the HTTP certificate has expired long ago. I tried to renew it but I'm not being agle to get it right. The initial status was: Request ID '20191219011208': status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN stuck: yes key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key' certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' Then following this thread https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… I got it to this state: Request ID '20191219011208': status: MONITORING ca-error: Server at https://dc1.tnu.com.uy/ipa/xml failed request, will retry: -504 (HTTP POST to URL 'https://XXXX/ipa/xml' failed. libcurl failed even to execute the HTTP transaction, explaining: SSL certificate problem: certificate has expired). stuck: no key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/XXXXX-443-RSA' certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' The post indicates that I have to put an old date in the server to get it renewed, but as the server is in production, it means that all clients will fail to log to the server. Evenmore, what time should I return to, before the certificate expiration or right after? Thanks in advance

3 25

ipa-healthcheck errors
by Rob Verduijn 03 Dec '22

03 Dec '22

Hello, After todays update I noticed I am now running rocky 8.7 freeipa was updated just fine and is working nicely. However after running ipa-healthcheck I was treated with a HUGE amount of errors. After some digging I found that certmonger stopped tracking of all my certs. Figuring out how to get all the certs tracked again took quite some time examples or hints on how to do this are sadly missing in ipa-healthcheck they would have been very usefull So now all untracked certs are tracked and no longer in ipa-healthcheck output. But there are still quite a few errors left which have no clue Does anybody know how to fix the errors from ipa-healthcheck ? (see txt below) Any help would be appreciated Rob ipa-healthcheck args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such object', 'ctrls': [], 'ldap_request': "search_ext_s(('cn=changelog5,cn=config', 0, '(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'], 'serverctrls': None, ' clientctrls': None, 'escapehatch': 'i am sure'}) on instance TJAKO-THUIS"},) [ { "source": "ipahealthcheck.ipa.certs", "check": "IPACertTracking", "result": "CRITICAL", "uuid": "711d096f-c1a8-4528-873d-522498811fbf", "when": "20221118235210Z", "duration": "2.149582", "kw": { "exception": "bus, object_path and dbus_interface must not be None." } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertDNSSAN", "result": "CRITICAL", "uuid": "06997e50-52cd-4240-9b90-41cd7bf9e9f6", "when": "20221118235212Z", "duration": "2.599630", "kw": { "exception": "bus, object_path and dbus_interface must not be None." } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "CRITICAL", "uuid": "5fe7388f-6ec6-433f-87df-4596eabee060", "when": "20221118235224Z", "duration": "2.801779", "kw": { "exception": "bus, object_path and dbus_interface must not be None." } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertmongerCA", "result": "ERROR", "uuid": "7a588ee8-f3f0-4db4-91d0-b236a9dcbb81", "when": "20221118235224Z", "duration": "0.009275", "kw": { "key": "dogtag-ipa-ca-renew-agent-reuse", "msg": "Certmonger CA '{key}' missing" } }, { "source": "ipahealthcheck.ipa.files", "check": "IPAFileCheck", "result": "CRITICAL", "uuid": "2e82818e-7210-4cf2-bd99-7490841348c6", "when": "20221118235226Z", "duration": "0.199291", "kw": { "exception": "bus, object_path and dbus_interface must not be None." } } ]

4 14

'transportCert cert-pki-kra' mix up
by GH 02 Dec '22

02 Dec '22

I've got two ancient (3.1?) IPA servers that have been upgraded over time. Last January things got really goofy with certificates and I got it all sorted. However, now I've got an old issue creeping back in. The 'transportCert cert-pki-kra' is mismatched between the CS.cfg and the tracked certificate. This is a multi-master setup. The signing master seems to be the one that's off. It's tracking the updated original 'transportCert cert-pki-kra' certificate. However, the "secondary" master is tracking a newly generated 'transportCert cert-pki-kra', which is also what both CS.cfg's are referencing. Neither one of the certificates is expired. Everything else seems to be in working order. Here is ipa-healthcheck's only relevant error: "source": "ipahealthcheck.dogtag.ca", "kw": { "msg": "Certificate 'transportCert cert-pki-kra' does not match the value of ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg", "directive": "ca.connector.KRA.transportCert", "key": "transportCert cert-pki-kra" }, So, what should I copy where to get this sorted? It seems like the updated original 'transportCert cert-pki-kra' should be copied into the CS.cfg and then manually scp the NSS files from "primary" to "secondary"? What commands would you use to do this? I've got a lot of commands noted and am beginning to get confused as to which ones should be used to get this sorted. Thanks.

6 26

Re: failed to add IPA Replica(Centos 8) on existing IPA cluster (Centos 7) with CA role enabled.
by Florence Blanc-Renaud 29 Nov '22

29 Nov '22

Hi, please keep the list in copy as the resolution steps can often help other users. On Fri, Nov 25, 2022 at 4:55 PM Dushyant Khobragade <dushyantk.sun(a)gmail.com> wrote: > Hi Flo, > Thank you for response. > I could see below logs in /var/log/ipareplica-install.log > <<Truncated>>> > 2022-11-25T15:43:46Z DEBUG certmonger request is in state > 'GENERATING_KEY_PAIR' > 2022-11-25T15:43:46Z DEBUG certmonger request is in state 'SUBMITTING' > 2022-11-25T15:44:11Z DEBUG certmonger request is in state 'CA_UNREACHABLE' > 2022-11-25T15:44:11Z DEBUG Cert request 20221125154346 failed: > CA_UNREACHABLE (Server at https://innsv01p1.mylab.domain/ipa/json failed > request, will retry: 4001 (The service principal for subject alt name > ipa-ca. mylab.domain in certificate request does not exist).) > Is IPA configured as DNS server? You can check with # ipa config-show | grep DNS IPA DNS servers: fedora36.ipa.test If there is at least one server in the IPA DNS servers list, then IPA is configured as DNS server. It should contain a DNS record for ipa-ca.mylab.domain with the IP addresses of all the CA servers: # ipa dnsrecord-show mylab.domain ipa-ca Record name: ipa-ca A record: xxx.xxx.xxx.xxx If you are using an external DNS server, make sure that there is an A record for ipa-ca. You can generate an update file using # ipa dns-update-system-records --dry-run 2022-11-25T15:44:11Z DEBUG Giving up on cert request 20221125154346 > 2022-11-25T15:44:11Z DEBUG certmonger request is in state 'GENERATING_CSR' > 2022-11-25T15:44:12Z DEBUG certmonger request is in state 'SUBMITTING' > 2022-11-25T15:44:13Z DEBUG certmonger request is in state 'POST_SAVED_CERT' > 2022-11-25T15:44:14Z DEBUG certmonger request is in state 'MONITORING' > 2022-11-25T15:44:14Z DEBUG Cert request 20221125154411 was successful > <<Truncated>>> > ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP server", > 'ctrls': [], 'info': 'error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed > (certificate is not yet valid)'} > 2022-11-25T15:45:40Z CRITICAL Failed to configure CA instance > It's not clear if this error or the previous one is the root cause, but the content of /var/log/pki/pki-ca-spawn.<date>.log on the replica may give some hints. *Certificate not yet valid* would strongly suggest that the dates are not in sync on the master and the replica. flo > 2022-11-25T15:45:40Z CRITICAL See the installation logs and the following > files/directories for more information: > 2022-11-25T15:45:40Z CRITICAL /var/log/pki/pki-tomcat > 2022-11-25T15:45:40Z DEBUG Traceback (most recent call last): > File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", > line 635, in start_creation > run_step(full_msg, method) > File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", > line 621, in run_step > method() > File "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py", > line 627, in __spawn_instance > nolog_list=nolog_list > File > "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py", > line 227, in spawn_instance > self.handle_setup_error(e) > File > "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py", > line 606, in handle_setup_error > ) from None > RuntimeError: CA configuration failed. > 2022-11-25T15:45:40Z DEBUG [error] RuntimeError: CA configuration failed. > 2022-11-25T15:45:40Z DEBUG Removing /root/.dogtag/pki-tomcat/ca > >>Truncted>> > > > Thanks & Regards, > Dushyant > > > > > > > On Fri, Nov 25, 2022 at 7:18 AM Florence Blanc-Renaud <flo(a)redhat.com> > wrote: > >> Hi, >> >> On Fri, Nov 25, 2022 at 3:59 PM dushyant k via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: >> >>> I am trying to add new replica Centos 8 IPA v.4.7 to my existing centos >>> 7 IPA cluster which has IPA version 4.6 >>> >>> I am able to add centos 8 replica as ipa client however while adding as >>> replica with setup-ca. it failing. >>> >>> Please provide the logs from the failing replica >> (/var/log/ipareplica-install.log). >> >> >>> Also it would be great if anyone can provide documents on migrating IPA >>> to centos 8 from centos 7 >>> >> The doc is available here: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… >> >> HTH, >> flo >> >> >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to >>> freeipa-users-leave(a)lists.fedorahosted.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >>

3 3

Local account override IPA account
by Kevin Vasko 29 Nov '22

29 Nov '22

I know this is probably stupid but we have a server with a local account (let’s call this local user “user1”). This server and its install predated our IPA install. This local user also has sudoers exception for this account for a “NOPASSWD” locally on this machine and this machine alone. After some period of time (it’s been like this for years), we added this “user1” account to FreeIPA so we could use it on other select machine. We kept using the local account as if nothing changed. This server with the local “user1” account was on Ubuntu 18.04 and with this set up was working fine. We upgraded it to Ubuntu 20.04 and it broke the sudoers “NOPASSWD”. This local account can no longer execute commands without a password as it seems sssd is overriding the “local account” and going back to IPA and asking for its authentication (user1 on this box is local and has a uid of 1000, the freeipa user1 had the random freeIPA generated 123456789 UID). In my nsswitch.conf For passwd, group, sudoers all of them have “files” listed first which should instruct sssd to prioritize local account information first, correct? If I remove “sss” from the nsswitch sudoers line it works as expected. Is this a regression in sssd or something else Im missing? -Kevin

2 1

IPA servers stopped replicating and cannot get them to replicate again.
by kelly＠fergason.com 29 Nov '22

29 Nov '22

Hello all, I have inherited an IPA setup that has some issues. I was unfamiliar with the IPA software, but am learning a lot really fast. They had 4 servers, ipa01-04. Replication went from 01 to 02 to 03, and I don't recall how 04 was updated. Replication stopped working from ipa01 to ipa02, and I have not been able to get it going again. At this time, we have one working ipa server, with no redundancy. Ipa02 and 03 are shutdown at the moment, ipa04 was rebuilt and I used it to try to create a new replica. I have tried to reinitialize the replication to ipa02, and I have tried to create new replicas. These are set as domainlevel 1, so the process is to create a replica by promoting a client. The general process used here was to clear up any replication agreements between servers and attempt to reinitialize or install the new replica. It pretty much always fails the same way. We had a consultant work with us, and they were unable to determine what the problem was. Some basics about the setup. We are running Oracle Linux 7.9, ipa-server 4.6.8-5.0.1. I have also tried Oracle Linux 8, and ipa-server 4.9.10, but there is no difference. DNS is not managed by the ipa server. Replication seems to be the basis for DR and upgrading, so it would be really nice to get this working again. I am attaching the console output of the ipa-replica-install command, and the install log file. Any insights as to how to get this going again would be greatly appreciated. If anyone needs more information, please let me know. Thanks, Kelly kelly(a)fergason.com

2 1

freeipa dns resolving for non local domains fails
by Rob Verduijn 25 Nov '22

25 Nov '22

Hello, I've found an issue with my ipa dns setup. all local dns queries work fine. However queries outside my ipa domain fail most of the time. I found this error in the logs: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out I think that this causes my problems with external dns. Anybody who knows how to deal with this ? Rob

2 4

FreeIPA 4.9.11
by Antonio Torres 25 Nov '22

25 Nov '22

1 0

failed to add IPA Replica(Centos 8) on existing IPA cluster (Centos 7) with CA role enabled.
by dushyant k 25 Nov '22

25 Nov '22

I am trying to add new replica Centos 8 IPA v.4.7 to my existing centos 7 IPA cluster which has IPA version 4.6 I am able to add centos 8 replica as ipa client however while adding as replica with setup-ca. it failing. Also it would be great if anyone can provide documents on migrating IPA to centos 8 from centos 7

3 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2022