April 2025 - FreeIPA-users - Fedora mailing-lists

Replication error not corrected by reinitializing replication
by David Brown 06 Nov '25

06 Nov '25

Hi, I have a small two node FreeIPA setup. (auth1 & auth2) I noticed today that I was getting a replication error on node 2 (auth2) about missing CSN in the changelog. I reinitialized the two nodes replicating auth1 -> auth2 and this has fixed replication issues in the past, but the error persists. I can create users and delete users from each side of the replication and it appears to be replicating those changes and they seem (non-definitively) to be in sync, but this error concerns me and reinitializing doesn't appear to solve it. Here are the logs. Any help is resolving this would be fantastic as I'm not finding much help via web searches. Thanks, David The sanitized error: Apr 16 10:50:31 auth2 ns-slapd[8419]: [16/Apr/2025:10:50:31.682835677 -0400] - ERR - agmt="cn=caToauth1...." (auth1:389) - clcache_load_buffer - Can't locate CSN 66587eaa000100050000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. Apr 16 10:50:31 auth2 ns-slapd[8419]: [16/Apr/2025:10:50:31.684721395 -0400] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToauth1...." (auth1:389): CSN 66587eaa000100050000 not found, we aren't as up to date, or we purged Apr 16 10:50:31 auth2 ns-slapd[8419]: [16/Apr/2025:10:50:31.685877312 -0400] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToauth1...." (auth1:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. Santitized re-initialization ipa topologysegment-reinitialize domain auth1....-to-auth2.... --right -------------------------------------------------------------------------------------------- Replication refresh for segment: "auth1....-to-auth2...." requested. -------------------------------------------------------------------------------------------- The sanitized logs of the re-initialization Apr 16 10:45:59 auth2 ns-slapd[8419]: [16/Apr/2025:10:45:59.963872886 -0400] - ERR - ipa-topology-plugin - ipa_topo_be_state_changebackend userRoot is going offline; inactivate plugin Apr 16 10:45:59 auth2 ns-slapd[8419]: [16/Apr/2025:10:45:59.966877380 -0400] - NOTICE - NSMMReplicationPlugin - multisupplier_be_state_change - Replica dc=...,dc=... is going offline; disabling replication Apr 16 10:46:00 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:00.189646600 -0400] - INFO - bdb_instance_start - Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database Apr 16 10:46:00 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:00.891598813 -0400] - ERR - agmt="cn=caToauth1...." (auth1:389) - clcache_load_buffer - Can't locate CSN 66587eaa000100050000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. Apr 16 10:46:00 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:00.893083190 -0400] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToauth1...." (auth1:389): CSN 66587eaa000100050000 not found, we aren't as up to date, or we purged Apr 16 10:46:00 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:00.894538030 -0400] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToauth1...." (auth1:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.403074677 -0400] - INFO - bdb_import_monitor_threads - import userRoot: Workers finished; cleaning up... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.605238770 -0400] - INFO - bdb_import_monitor_threads - import userRoot: Workers cleaned up. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.606678188 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Indexing complete. Post-processing... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.607860375 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Generating numsubordinates (this may take several minutes to complete)... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.618231549 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Generating numSubordinates complete. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.620014951 -0400] - INFO - bdb_get_nonleaf_ids - import userRoot: Gathering ancestorid non-leaf IDs... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.621434375 -0400] - INFO - bdb_get_nonleaf_ids - import userRoot: Finished gathering ancestorid non-leaf IDs. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.622574267 -0400] - INFO - ldbm_get_nonleaf_ids - import userRoot: Starting sort of ancestorid non-leaf IDs... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.623757818 -0400] - INFO - ldbm_get_nonleaf_ids - import userRoot: Finished sort of ancestorid non-leaf IDs. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.626748319 -0400] - INFO - bdb_ancestorid_new_idl_create_index - import userRoot: Creating ancestorid index (new idl)... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.632623820 -0400] - INFO - bdb_ancestorid_new_idl_create_index - import userRoot: Created ancestorid index (new idl). Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.633896253 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Flushing caches... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.635305588 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Closing files... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.728196646 -0400] - INFO - bdb_public_bdb_import_main - import userRoot: Import complete. Processed 729 entries in 3 seconds. (243.00 entries/sec) Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.737959417 -0400] - ERR - ipa-topology-plugin - ipa_topo_be_state_change - backend userRoot is coming online; checking domain level and init shared topology Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.744152900 -0400] - NOTICE - NSMMReplicationPlugin - multisupplier_be_state_change - Replica dc=...,dc=... is coming online; enabling replication Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.754743353 -0400] - WARN - NSMMReplicationPlugin - replica_reload_ruv - New data for replica dc=...,dc=... does not match the data in the changelog. Apr 16 10:46:02 auth2 ns-slapd[8419]: Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.862749463 -0400] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding the replication changelog RUV, this may take several minutes... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.864263319 -0400] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding replication changelog RUV complete. Result 0 (Success) Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.872479720 -0400] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=...,dc=...--no CoS Templates found, which should be added before the CoS Definition. Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.874025309 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.875303781 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.876489711 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.877770904 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.879231097 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.880458410 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.881648891 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.882722133 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.884124162 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.885222292 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.886404863 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.887615474 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.889102423 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.890327963 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.891412886 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.892586141 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.899706161 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.901020418 -0400] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=...,dc=... does not exist Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.907037194 -0400] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding the replication changelog RUV, this may take several minutes... Apr 16 10:46:02 auth2 ns-slapd[8419]: [16/Apr/2025:10:46:02.908357262 -0400] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding replication changelog RUV complete. Result 0 (Success)

3 5

Problem with "Login failed due to an unknown reason" / PKINIT OpenSSL error
by Ville Teronen 06 Nov '25

06 Nov '25

Hello, We are currently experiencing strange behavior on FreeIPA system related to PKINIT OpenSSL error when trying to log in through FreeIPA web gui. This started happening as we upgraded our second replica with "dnf ugprade". Freeipa packages in themself haven't been updated. Our setup is basically as follows. ipa.tre-1.web1.fi ipa.tku-2.web1.fi <-- the one not working. GUI throws an error "Login failed due to an unknown reason" httpd error log has the following line after error: [Fri Feb 25 19:32:50.776457 2022] [wsgi:error] [pid 17977:tid 18319] [remote 10.20.11.2:49472] ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/bin/kinit', '-n', '-c', '/run/ipa/ccaches/armor_17977', '-X', 'X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt', '-X', 'X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem'] returned non-zero exit status 1: 'kinit: Cannot read password while getting initial credentials\\n') Now if I try to run " KRB5_TRACE=/dev/stdout /usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_15581 -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem" I get the following output [19260] 1645812760.557398: Getting initial credentials for WELLKNOWN/ANONYMOUS(a)IPA.WEB1.FI [19260] 1645812760.557400: Sending unauthenticated request [19260] 1645812760.557401: Sending request (186 bytes) to IPA.WEB1.FI [19260] 1645812760.557402: Initiating TCP connection to stream 10.20.13.5:88 [19260] 1645812760.557403: Sending TCP request to stream 10.20.13.5:88 [19260] 1645812760.557404: Received answer (538 bytes) from stream 10.20.13.5:88 [19260] 1645812760.557405: Terminating TCP connection to stream 10.20.13.5:88 [19260] 1645812760.557406: Response was from primary KDC [19260] 1645812760.557407: Received error from KDC: -1765328359/Additional pre-authentication required [19260] 1645812760.557410: Preauthenticating using KDC method data [19260] 1645812760.557411: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133) [19260] 1645812760.557412: Selected etype info: etype aes256-cts, salt "IPA.WEB1.FIWELLKNOWNANONYMOUS", params "" [19260] 1645812760.557413: Received cookie: MIT1\x00\x00\x00\x01\x8f\xcb\x99\x9c~\xed!^Qj\xa3\x0a\x82~\xe94\x04\x0ck[j=\x08\xd2\x97j'K2\x8f\xa0\xf6\xc3\x89Z@\x8b]\xc3K\xc2h\xfa\xaek\x11\x91y\xc9\xf0\xadG\x13\x9a\xb2\xb6\x1c\x12\xbfr\x0a'Z\xfe\x12\x81\x1a>2\x8c\x1a\xf2\x96\xdc]&qH\x08\x1f\x0d\xc0a{\xe8\xff\xbbF\x9c\x86`\xd6G\xc4*5\xccL\xc1m\xc0\xa7b\x8b]od\xfa*\xd4.bmB\x9d\x92\xb7\xf9($\xa4D\xea\xcd\xc6\xe3p\xac$\xf4 [19260] 1645812760.557414: Preauth module pkinit (147) (info) returned: 0/Success [19260] 1645812760.557415: PKINIT client received freshness token from KDC [19260] 1645812760.557416: Preauth module pkinit (150) (info) returned: 0/Success [19260] 1645812760.557417: PKINIT loading CA certs and CRLs from FILE [19260] 1645812760.557418: PKINIT loading CA certs and CRLs from FILE [19260] 1645812760.557419: PKINIT loading CA certs and CRLs from FILE [19260] 1645812760.557420: PKINIT client computed kdc-req-body checksum 9/B79768B0DAD630709ABFE35C1E2B6FDAB714913D [19260] 1645812760.557422: PKINIT client making DH request [19260] 1645812760.557423: Preauth module pkinit (16) (real) returned: 0/Success [19260] 1645812760.557424: Produced preauth for next request: PA-FX-COOKIE (133), PA-PK-AS-REQ (16) [19260] 1645812760.557425: Sending request (1674 bytes) to IPA.WEB1.FI [19260] 1645812760.557426: Initiating TCP connection to stream 10.20.13.5:88 [19260] 1645812760.557427: Sending TCP request to stream 10.20.13.5:88 [19260] 1645812760.557428: Received answer (2619 bytes) from stream 10.20.13.5:88 [19260] 1645812760.557429: Terminating TCP connection to stream 10.20.13.5:88 [19260] 1645812760.557430: Response was from primary KDC [19260] 1645812760.557431: Processing preauth types: PA-PK-AS-REP (17), PA-PKINIT-KX (147) [19260] 1645812760.557432: Preauth module pkinit (147) (info) returned: 0/Success [19260] 1645812760.557433: PKINIT OpenSSL error: Failed to verify CMS message [19260] 1645812760.557434: PKINIT OpenSSL error: error:1700006B:CMS routines::content type not enveloped data [19260] 1645812760.557435: PKINIT OpenSSL error: error:03000098:digital envelope routines::invalid digest [19260] 1645812760.557436: PKINIT client could not verify DH reply [19260] 1645812760.557437: Preauth module pkinit (17) (real) returned: -1765328320/Failed to verify CMS message: content type not enveloped data [19260] 1645812760.557438: Produced preauth for next request: (empty) [19260] 1645812760.557439: Getting AS key, salt "IPA.WEB1.FIWELLKNOWNANONYMOUS", params "" Password for WELLKNOWN/ANONYMOUS(a)IPA.WEB1.FI: [19260] 1645812776.928337: AS key obtained from gak_fct: aes256-cts/3840 kinit: Password incorrect while getting initial credentials But this only happens on the "dc2" one. If I would run this on the "dc1" it would work just fine. I have tried running ipa-pkinit-manage disable ipa-pkinit-manage enable to regen the cert but it didn't help. Any suggestions / pointers at why the OpenSSL error on the tku-2 is showing up.

6 11

IPA DNS ACL (respond with a different IP depending on the requester)
by Daniel PC 24 Oct '25

24 Oct '25

I would like to configure DNS to respond with a different IP depending on the requester source IP. Bind allow it using ACL. Do you know if it is possible to implement this feature on IPA integrated DNS? thank you

3 4

Error upgrading to version 4.11.0
by Luis Correia 19 Oct '25

19 Oct '25

Hello all. I'm currently running a FreeIPA server on Docker using the rocky-9-4.10.2 and trying to upgrade my installation to version rocky-9-4.11.0, but currently getting this error: 2024-08-28T09:21:52Z DEBUG Failed to check CA status: cannot connect to 'http://<my-freeipa-hostname>:8080/ca/admin/ca/getStatus': [Errno 111] Connection refused 2024-08-28T09:22:38Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2024-08-28T09:22:38Z DEBUG File "/usr/lib/python3.9/site-packages/ipapython/admintool.py", line 180, in execute return_value = self.run() File "/usr/lib/python3.9/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python3.9/site-packages/ipaserver/install/server/upgrade.py", line 2081, in upgrade upgrade_configuration() File "/usr/lib/python3.9/site-packages/ipaserver/install/server/upgrade.py", line 1803, in upgrade_configuration ca.start('pki-tomcat') File "/usr/lib/python3.9/site-packages/ipaserver/install/service.py", line 575, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python3.9/site-packages/ipaplatform/base/services.py", line 304, in start ipautil.run([paths.SYSTEMCTL, "start", File "/usr/lib/python3.9/site-packages/ipapython/ipautil.py", line 599, in run raise CalledProcessError( 2024-08-28T09:22:38Z DEBUG The ipa-server-upgrade command failed, exception: CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd(a)pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd(a)pki-tomcat.service canceled.\n') 2024-08-28T09:22:38Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd(a)pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd(a)pki-tomcat.service canceled.\n') 2024-08-28T09:22:38Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information The endpoint that FreeIPA tries to connect to eventually generates a 404 error (logs from var/log/pki/pki-tomcat/localhost_access_log.2024-08-28.txt): 172.18.0.2 - - [28/Aug/2024:09:22:33 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 172.18.0.2 - - [28/Aug/2024:09:22:34 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 172.18.0.2 - - [28/Aug/2024:09:22:35 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 172.18.0.2 - - [28/Aug/2024:09:22:36 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 172.18.0.2 - - [28/Aug/2024:09:22:37 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 172.18.0.2 - - [28/Aug/2024:09:22:38 +0000] "GET /ca/admin/ca/getStatus HTTP/1.1" 404 784 Can anyone help? This makes it so that I'm completely unable to update FreeIPA to the latest version, which I currently need to do. Thanks!

5 9

Unable to delete ID range
by Jeremy Tourville 14 Oct '25

14 Oct '25

We are running IPA server 4.9.11 We previously had a domain trust established with AD. Presently, the trust has been removed and we are trying to remove / clean up the ID range for AD. When doing so, using the command ipa idrange-del <range_name>, we get the error: "ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving objects with ID out of the defined range is not allowed" Any suggestions to troubleshoot and remove this range?

5 9

Fedora 41 - ssl/tls alert handshake failure on CA subsystem
by Hannes Eberhardt 01 Jul '25

01 Jul '25

Hi, I recently upgraded my FreeIPA host system from Fedorda 40 to 41. Since the upgrade I am unable to access the details of the CA subsystem. While I get a list/overview of all certificates that are available in the directory, FreeIPA throws an error if I try to access a specific certificate or CA. The error is: IPA Error 907: Network Error cannot connect to 'https://my-idm-server.idm.my.domain:443/ca/rest/certs/216402019788816070027…' : [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] ssl/tls alert handshake failure (_ssl.c:2638) I am also getting this error while running the ipa-healthcheck. { "source": "ipahealthcheck.dogtag.ca", "check": "DogtagCertsConnectivityCheck", "result": "ERROR", "uuid": "84949312-c4a1-4924-95e5-338894d2ee27", "when": "20250122094218Z", "duration": "0.022545", "kw": { "key": "cert_show_ra", "error": "cannot connect to 'https://my-idm-server.idm.my.domain:443/ca/rest/certs/198421384424903357883…' : [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] ssl/tls alert handshake failure (_ssl.c:2638)", "serial": "198421384424903357883919048254057663382", "msg": "Request for certificate failed: {error}" } }, [...] I am able to get a working TLS Handshake and a sensible reply with curl on the same machine. At first I guessd it might be an incompatiblity with TLSv1.3, so I tried to configure only TLSv1.2 in the httpd ssl.conf, but this did not resolve the issue. I also tried to use the legacy system crypto-policy instead of the default one. So I don't really think that this is a cipher missmatch/compatiblity issue. Could this be a verification issue on the certificate chain somewhere? Does someone maybe have a hint where to start looking next and get this fixed? FreeIPA Version 4.12.2 OS: Fedora 41 Server, no upgrades pending, default repos. Thank you for your help! Cheers, Hannes

3 10

Crashes in bind9 name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001))
by Kees Bakker 26 Jun '25

26 Jun '25

Hi, After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued. This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison. Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs. If anybody here on the list has an idea, then please let me know. Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9 Stack trace: Stack trace of thread 6432: #0 0x00007fb5a348b94c __pthread_kill_implementation (libc.so.6 + 0x8b94c) #1 0x00007fb5a343e646 raise (libc.so.6 + 0x3e646) #2 0x00007fb5a34287f3 abort (libc.so.6 + 0x287f3) #3 0x00005570cbbea5b5 assertion_failed.cold (named + 0x1c5b5) #4 0x00007fb5a433d420 isc_assertion_failed (libisc-9.16.23-RH.so + 0x1c420) #5 0x00007fb5a409f9ca dns_name_equal (libdns-9.16.23-RH.so + 0x9f9ca) #6 0x00007fb5a40b48ec dns_order_find (libdns-9.16.23-RH.so + 0xb48ec) #7 0x00007fb5a4429de8 query_addrrset.lto_priv.0 (libns-9.16.23-RH.so + 0x1dde8) #8 0x00007fb5a442eece query_gotanswer (libns-9.16.23-RH.so + 0x22ece) #9 0x00007fb5a4432b8b fetch_callback (libns-9.16.23-RH.so + 0x26b8b) #10 0x00007fb5a43781bd isc_task_run (libisc-9.16.23-RH.so + 0x571bd) #11 0x00007fb5a43632a9 process_netievent (libisc-9.16.23-RH.so + 0x422a9) #12 0x00007fb5a4363425 process_queue (libisc-9.16.23-RH.so + 0x42425) #13 0x00007fb5a4363c17 async_cb (libisc-9.16.23-RH.so + 0x42c17) #14 0x00007fb5a4285afd uv__async_io.part.0 (libuv.so.1 + 0xaafd) #15 0x00007fb5a42a185e uv__io_poll.part.0 (libuv.so.1 + 0x2685e) #16 0x00007fb5a428b568 uv_run (libuv.so.1 + 0x10568) #17 0x00007fb5a43634db nm_thread (libisc-9.16.23-RH.so + 0x424db) #18 0x00007fb5a4375f9a isc__trampoline_run (libisc-9.16.23-RH.so + 0x54f9a) #19 0x00007fb5a3489c02 start_thread (libc.so.6 + 0x89c02) #20 0x00007fb5a350ec40 __clone3 (libc.so.6 + 0x10ec40) -- Kees

4 7

ipa-replica-install -- cannot get past [26/41]: creating DS keytab
by Jonathon Jenkins 10 Jun '25

10 Jun '25

Greetings, I cannot get the ipa-replica-install to proceed past step 26/41 - creating DS keytab. I see the command that is to be run, and I can run that just fine before and after the ipa-replica-install command, and it creates the keytab. I am not sure how to proceed from here - the bug reports I see all pertain to earlier versions, and my files reflect those changes. I have also tried running this with all manner of password flags, which are correct, but still getting insufficient access rights. particulars: centos 7 3.10.0-957.1.3.el7.x86_64 ipa-server-4.6.4-10.el7.centos.x86_64 ipa-common-4.6.4-10.el7.centos.noarch ipa-server-common-4.6.4-10.el7.centos.noarch ipa-client-4.6.4-10.el7.centos.x86_64 ipa-server-dns-4.6.4-10.el7.centos.noarch ipa-client-common-4.6.4-10.el7.centos.noarch * Note: anonymized output below ipapython.ipautil: DEBUG stderr= ipalib.backend: DEBUG Created connection context.ldap2_139891568509776 ipaserver.install.service: DEBUG duration: 7 seconds ipaserver.install.service: DEBUG [26/41]: creating DS keytab [26/41]: creating DS keytab ipalib.frontend: DEBUG raw: service_add(u'ldap/<ipa-replica-host>@<domain>.NET', force=True, version=u'2.229') ipalib.frontend: DEBUG service_add(ipapython.kerberos.Principal('ldap/<ipa-replica-host>@<domain>.NET'), force=True, all=False, raw=False, version=u'2.229', no_members=False) ipalib.frontend: DEBUG raw: host_show(u'<ipa-replica-host>', version=u'2.229') ipalib.frontend: DEBUG host_show(u'<ipa-replica-host>', rights=False, all=False, raw=False, version=u'2.229', no_members=False) ipalib.install.sysrestore: DEBUG Backing up system configuration file '/etc/dirsrv/ds.keytab' ipalib.install.sysrestore: DEBUG -> Not backing up - '/etc/dirsrv/ds.keytab' doesn't exist ipapython.ipautil: DEBUG Starting external process ipapython.ipautil: DEBUG args=/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master> ipapython.ipautil: DEBUG Process finished, return code=9 ipapython.ipautil: DEBUG stdout= ipapython.ipautil: DEBUG stderr=Failed to parse result: Insufficient access rights Retrying with pre-4.0 keytab retrieval method... Failed to parse result: Insufficient access rights Failed to get keytab! Failed to get keytab ipaserver.install.service: DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 1308, in request_service_keytab super(DsInstance, self).request_service_keytab() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab ipautil.run(args, nolog=nolog) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run raise CalledProcessError(p.returncode, arg_string, str(output)) CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipaserver.install.service: DEBUG [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipalib.backend: DEBUG Destroyed connection context.ldap2_139891548583120 ipalib.install.sysrestore: DEBUG Backing up system configuration file '/etc/ipa/default.conf' ipalib.install.sysrestore: DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipapython.admintool: DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 319, in run return cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 364, in run return self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 389, in execute for rval in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 658, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 521, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 518, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 65, in _install for unused in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/__init__.py", line 622, in main replica_install(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 406, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1431, in install fstore=fstore) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 113, in install_replica_ds setup_pkinit=not options.no_pkinit, File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 419, in create_replica self.start_creation(runtime=30) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 1308, in request_service_keytab super(DsInstance, self).request_service_keytab() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab ipautil.run(args, nolog=nolog) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run raise CalledProcessError(p.returncode, arg_string, str(output)) ipapython.admintool: DEBUG The ipa-replica-install command failed, exception: CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipapython.admintool: ERROR Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

3 4

Re: freeIPA fails update 4.12.2-5.el9 t 4.12.2-9.el9
by Vicente Quintans 03 Jun '25

03 Jun '25

We found this issue today, upgrading from Fedora 40 to Fedora 41. In dogtagpki the /ca/rest/account/login endpoint (actually all /ca/rest endpoints) was moved to /ca/v1 in this commit: https://github.com/dogtagpki/pki/commit/850e6b9e5128264a471e57b70ab8d970cf9… We were able to complete the upgrade succesfully modifying the file /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py changing al "/rest" to "/v1". With this modification ipa-server-upgrade completed successfully. It seems there is some kind of version mismatch. Greetings, Vicente Quintáns.

10 35

FreeIPA failed after upgrading to fedora 42
by Ian Kumlien 09 May '25

09 May '25

Hi, I have two freeipa servers that failed after the upgrade. On one, i managed to fix it with ipa-cert-fix since they had expired again, but i'm now left with: ipa-backup Preparing backup on freeipa1.... Error: Local roles CA, DNS, DNSKeySync do not match globally used roles CA, DNS, DNSKeySync, KRA. A backup done on this host would not be complete enough to restore a fully functional, identical cluster. The ipa-backup command failed. See /var/log/ipabackup.log for more information And on the other pki-tomcat doesn't start without ca_signing.csr which it never had according to backups... Any clues?

3 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users April 2025