Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
And the log says: 2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user 2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout 2024-03-11T15:05:24Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound( ipalib.errors.NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca 2024-03-11T15:05:24Z DEBUG File "/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py", line 781, in run_script return_value = main_function() ^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 354, in install install_step_0(standalone, replica_config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 422, in install_step_0 ca.configure_instance(
File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 505, in configure_instance self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed, exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica, lets the
replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated. When this error happens, it can either mean that the entry was not replicated or that the bind failed.
In order to know exactly what is happening for you, you can check - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue. # ldapsearch -D "cn=directory manager" -W -b uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password. For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3 pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4 wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d*{PBKDF2_SHA256}*AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
which means that the replica used PBKDF2_SHA256 as password storage scheme. You need to check if this password storage scheme is supported on the master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command: # ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b "cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
If the replica is using a password scheme not supported on the master, you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
flo
And the log says: 2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user 2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout 2024-03-11T15:05:24Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound( ipalib.errors.NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca 2024-03-11T15:05:24Z DEBUG File "/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py", line 781, in run_script return_value = main_function() ^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 354, in install install_step_0(standalone, replica_config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 422, in install_step_0 ca.configure_instance(
File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 505, in configure_instance self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed, exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica, lets the replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated. When this error happens, it can either mean that the entry was not replicated or that the bind failed.
In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password.
For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3 pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4 wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d {PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
Yes, and the value is the same on both replicas, both the encoded base64 and the password scheme: {PBKDF2_SHA256}AAAIAGIHopZZSHY8.....
Since I changed it as described in the link i included...
which means that the replica used PBKDF2_SHA256 as password storage scheme. You need to check if this password storage scheme is supported on the master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command: # ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b "cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
Yes, and they both support PBKDF2_SHA256 both as plugin and password storage scheme
If the replica is using a password scheme not supported on the master, you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
4.9.10 and 4.11.1
(fedora is just now updating it to 4.11.1-2 will look at the changes)
Anyway, thanks for the help so far, i can now see the account replicated but i don't quite understand why it doesn't work...
flo
And the log says: 2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user 2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout 2024-03-11T15:05:24Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound( ipalib.errors.NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca 2024-03-11T15:05:24Z DEBUG File "/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py", line 781, in run_script return_value = main_function() ^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 354, in install install_step_0(standalone, replica_config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 422, in install_step_0 ca.configure_instance(
File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 505, in configure_instance self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 789, in setup_admin raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed, exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien ian.kumlien@gmail.com wrote:
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica, lets
the replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated.
When this error happens, it can either mean that the entry was not
replicated or that the bind failed.
In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and
check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the
userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password.
For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword::
e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo
e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d
{PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
Yes, and the value is the same on both replicas, both the encoded base64 and the password scheme: {PBKDF2_SHA256}AAAIAGIHopZZSHY8.....
Since I changed it as described in the link i included...
which means that the replica used PBKDF2_SHA256 as password storage
scheme.
You need to check if this password storage scheme is supported on the
master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command:
# ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b
"cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
Yes, and they both support PBKDF2_SHA256 both as plugin and password storage scheme
If the replica is using a password scheme not supported on the master,
you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
4.9.10 and 4.11.1
(fedora is just now updating it to 4.11.1-2 will look at the changes)
Anyway, thanks for the help so far, i can now see the account replicated but i don't quite understand why it doesn't work...
Your ipa-ca-install command failed at 2024-03-11T15:05:24Z. Can you check on the master around this date if there is a connection from replica to master with a BIND attempt that would be failing? The logs are in /var/log/dirsrv/slapd-YOURDOMAIN/access. Look for something similar to BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca". Then note the conn number and op number and look for the RESULT with the same conn and op, for instance:
[13/Mar/2024:09:10:01.331583308 +0000] conn=106 op=2 BIND dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca" method=128 version=3 [13/Mar/2024:09:10:01.355201520 +0000] conn=106 op=2 RESULT err=0 tag=97 nentries=0 wtime=0.000106547 optime=0.023642452 etime=0.023744831 dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca"
The lines may be separated by other logs, and the err=xxx will show if the bind is successful or failed. err=0 means success, err=49 means invalid credentials.
flo
flo
And the log says: 2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user 2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout 2024-03-11T15:05:24Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File
"/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin raise errors.NotFound( ipalib.errors.NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca 2024-03-11T15:05:24Z DEBUG File "/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py", line 781, in run_script return_value = main_function() ^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 354, in install install_step_0(standalone, replica_config, options,
custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 422, in install_step_0 ca.configure_instance(
File
"/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py",
line 505, in configure_instance self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method()
File
"/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed, exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389 -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
Do not reply to spam, report it:
On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien ian.kumlien@gmail.com wrote:
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica, lets the replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated. When this error happens, it can either mean that the entry was not replicated or that the bind failed.
In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password.
For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3 pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4 wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d {PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
Yes, and the value is the same on both replicas, both the encoded base64 and the password scheme: {PBKDF2_SHA256}AAAIAGIHopZZSHY8.....
Since I changed it as described in the link i included...
which means that the replica used PBKDF2_SHA256 as password storage scheme. You need to check if this password storage scheme is supported on the master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command: # ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b "cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
Yes, and they both support PBKDF2_SHA256 both as plugin and password storage scheme
If the replica is using a password scheme not supported on the master, you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
4.9.10 and 4.11.1
(fedora is just now updating it to 4.11.1-2 will look at the changes)
Anyway, thanks for the help so far, i can now see the account replicated but i don't quite understand why it doesn't work...
Your ipa-ca-install command failed at 2024-03-11T15:05:24Z. Can you check on the master around this date if there is a connection from replica to master with a BIND attempt that would be failing? The logs are in /var/log/dirsrv/slapd-YOURDOMAIN/access. Look for something similar to BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca". Then note the conn number and op number and look for the RESULT with the same conn and op, for instance:
[13/Mar/2024:09:10:01.331583308 +0000] conn=106 op=2 BIND dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca" method=128 version=3 [13/Mar/2024:09:10:01.355201520 +0000] conn=106 op=2 RESULT err=0 tag=97 nentries=0 wtime=0.000106547 optime=0.023642452 etime=0.023744831 dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca"
The lines may be separated by other logs, and the err=xxx will show if the bind is successful or failed. err=0 means success, err=49 means invalid credentials.
Yes, it does fail with invalid credentials...
[11/Mar/2024:15:25:34.887970467 +0100] conn=118429 op=2 BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca" method=128 version=3 [11/Mar/2024:15:25:34.888893033 +0100] conn=118429 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000265028 optime=0.000950489 etime=0.001212411 - Invalid credentials
Latest test, states [13/Mar/2024:10:41:45.063122671 +0100] conn=192008 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000244892 optime=0.001078282 etime=0.001320065 - No such entry
I did remove it. as in uninstalled freeipa-4 removed the server and removed that account, just to make sure it was replicated properly...:
[--8<--]
On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien ian.kumlien@gmail.com wrote:
On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien ian.kumlien@gmail.com wrote:
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi,
So i have spent quite some time trying to get out of the swamp that is centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master, changed on replica as detailed here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica, lets the replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated. When this error happens, it can either mean that the entry was not replicated or that the bind failed.
In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password.
For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3 pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4 wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d {PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
Yes, and the value is the same on both replicas, both the encoded base64 and the password scheme: {PBKDF2_SHA256}AAAIAGIHopZZSHY8.....
Since I changed it as described in the link i included...
which means that the replica used PBKDF2_SHA256 as password storage scheme. You need to check if this password storage scheme is supported on the master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command: # ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b "cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
Yes, and they both support PBKDF2_SHA256 both as plugin and password storage scheme
If the replica is using a password scheme not supported on the master, you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
4.9.10 and 4.11.1
(fedora is just now updating it to 4.11.1-2 will look at the changes)
Anyway, thanks for the help so far, i can now see the account replicated but i don't quite understand why it doesn't work...
Your ipa-ca-install command failed at 2024-03-11T15:05:24Z. Can you check on the master around this date if there is a connection from replica to master with a BIND attempt that would be failing? The logs are in /var/log/dirsrv/slapd-YOURDOMAIN/access. Look for something similar to BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca". Then note the conn number and op number and look for the RESULT with the same conn and op, for instance:
[13/Mar/2024:09:10:01.331583308 +0000] conn=106 op=2 BIND dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca" method=128 version=3 [13/Mar/2024:09:10:01.355201520 +0000] conn=106 op=2 RESULT err=0 tag=97 nentries=0 wtime=0.000106547 optime=0.023642452 etime=0.023744831 dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca"
The lines may be separated by other logs, and the err=xxx will show if the bind is successful or failed. err=0 means success, err=49 means invalid credentials.
Yes, it does fail with invalid credentials...
[11/Mar/2024:15:25:34.887970467 +0100] conn=118429 op=2 BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca" method=128 version=3 [11/Mar/2024:15:25:34.888893033 +0100] conn=118429 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000265028 optime=0.000950489 etime=0.001212411 - Invalid credentials
Latest test, states [13/Mar/2024:10:41:45.063122671 +0100] conn=192008 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000244892 optime=0.001078282 etime=0.001320065 - No such entry
I did remove it. as in uninstalled freeipa-4 removed the server and removed that account, just to make sure it was replicated properly...:
[--8<--]
As a side node, the conncheck for ipa-ca-install fails all the time now, when executing check on remote master it ends with this: 2024-03-14T07:42:26Z DEBUG Destroyed connection context.rpcclient_139905569284576 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with following error message(s): invalid 'cn': must be "freeipa-4.xerces.lan" 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
Which seems really strange...
Hi,
On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien ian.kumlien@gmail.com wrote:
On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien ian.kumlien@gmail.com wrote:
On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud flo@redhat.com
wrote:
Hi,
On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien ian.kumlien@gmail.com
wrote:
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud <
flo@redhat.com> wrote:
Hi,
On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
Hi,
So i have spent quite some time trying to get out of the swamp
that is
centos stream 8 and back to something with a actual upgrade path, fedora =)
Everything works except the ipa-ca-install on the replica - mostly fails at the same step
At some point the conncheck failed, dropping me in to a prompt
asking
for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on
master,
changed on replica as detailed here:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with
interoperability
ipa-ca-install --skip-conncheck Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3
minutes
[1/28]: creating certificate server db [2/28]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded
[3/28]: creating ACIs for admin [4/28]: creating installation admin user ipaserver.install.dogtaginstance: ERROR Unable to log in as uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on ldap://freeipa-1.xerces.lan:389 [error] NotFound:
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for
details:
NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to ldap://freeipa-1.xerces.lan:389
The installation of a CA clone creates this user on the replica,
lets the replication copy the entry on the master and then checks by doing a ldap bind from the replica to the master that the entry has been properly replicated.
When this error happens, it can either mean that the entry was not
replicated or that the bind failed.
In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this
entry and check if it exists. If the entry is present, the replication properly propagated the entry from replica to master and you are probably hitting the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
- on the replica, do a ldapsearch for this entry and check the
userpassword attribute. It is base64-encoded, and you can decode it in order to find the password storage scheme that was used to encrypt the password.
For instance on my machine:
dn: uid=admin-replica.ipa.test,ou=people,o=ipaca userPassword::
e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
If I base64 decode the value:
# echo
e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp | base64 -d
{PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai
Yes, and the value is the same on both replicas, both the encoded base64 and the password scheme: {PBKDF2_SHA256}AAAIAGIHopZZSHY8.....
Since I changed it as described in the link i included...
which means that the replica used PBKDF2_SHA256 as password storage
scheme.
You need to check if this password storage scheme is supported on
the master (we had issues in the past with a password storage scheme used by the replica that was not supported on the master and caused the bind to fail, https://bugzilla.redhat.com/show_bug.cgi?id=2151071). The list of supported password storage schemes is available with the following command:
# ldapsearch -D "cn=directory manager" -W -LLL -o ldif-wrap=no -b
"cn=Password Storage Schemes,cn=plugins,cn=config" -s one dn
Yes, and they both support PBKDF2_SHA256 both as plugin and password storage scheme
If the replica is using a password scheme not supported on the
master, you are probably hitting the above BZ. There were fixes for multiple versions of 389-ds, we would need to know your exact versions on the replica and the master to point you to the right advisory.
4.9.10 and 4.11.1
(fedora is just now updating it to 4.11.1-2 will look at the changes)
Anyway, thanks for the help so far, i can now see the account replicated but i don't quite understand why it doesn't work...
Your ipa-ca-install command failed at 2024-03-11T15:05:24Z. Can you
check on the master around this date if there is a connection from replica to master with a BIND attempt that would be failing? The logs are in /var/log/dirsrv/slapd-YOURDOMAIN/access. Look for something similar to BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca". Then note the conn number and op number and look for the RESULT with the same conn and op, for instance:
[13/Mar/2024:09:10:01.331583308 +0000] conn=106 op=2 BIND
dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca" method=128 version=3
[13/Mar/2024:09:10:01.355201520 +0000] conn=106 op=2 RESULT err=0
tag=97 nentries=0 wtime=0.000106547 optime=0.023642452 etime=0.023744831 dn="uid=admin-replica0.ipa.test,ou=people,o=ipaca"
The lines may be separated by other logs, and the err=xxx will show if
the bind is successful or failed. err=0 means success, err=49 means invalid credentials.
Yes, it does fail with invalid credentials...
[11/Mar/2024:15:25:34.887970467 +0100] conn=118429 op=2 BIND dn="uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca" method=128 version=3 [11/Mar/2024:15:25:34.888893033 +0100] conn=118429 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000265028 optime=0.000950489 etime=0.001212411 - Invalid credentials
Latest test, states [13/Mar/2024:10:41:45.063122671 +0100] conn=192008 op=2 RESULT err=49 tag=97 nentries=0 wtime=0.000244892 optime=0.001078282 etime=0.001320065 - No such entry
I did remove it. as in uninstalled freeipa-4 removed the server and removed that account, just to make sure it was replicated properly...:
[--8<--]
As a side node, the conncheck for ipa-ca-install fails all the time now, when executing check on remote master it ends with this: 2024-03-14T07:42:26Z DEBUG Destroyed connection context.rpcclient_139905569284576 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with following error message(s): invalid 'cn': must be "freeipa-4.xerces.lan" 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
Which seems really strange...
The message is highly misleading, but basically means that the conncheck
part tried to check the connection to freeipa-4.xerces.lan, there was an issue and then a different server was tried. Discussed in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Can you provide the exact OS + ipa / 389-ds-base versions that you have on your server and on your replica? And any relevant info about the history of the master (for instance, was the master initially installed with this version or was it upgraded from older versions).
flo
On Thu, Mar 14, 2024 at 7:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien ian.kumlien@gmail.com wrote:
On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien ian.kumlien@gmail.com wrote:
[--8<--]
As a side node, the conncheck for ipa-ca-install fails all the time now, when executing check on remote master it ends with this: 2024-03-14T07:42:26Z DEBUG Destroyed connection context.rpcclient_139905569284576 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with following error message(s): invalid 'cn': must be "freeipa-4.xerces.lan" 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
Which seems really strange...
The message is highly misleading, but basically means that the conncheck part tried to check the connection to freeipa-4.xerces.lan, there was an issue and then a different server was tried. Discussed in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Ok, i have actually looked at that and checked the pki security-domain-show --- perhaps i should look at the bug options as well...
Can you provide the exact OS + ipa / 389-ds-base versions that you have on your server and on your replica? And any relevant info about the history of the master (for instance, was the master initially installed with this version or was it upgraded from older versions).
I verified that the plugin is available on the other end, so ... Centos 8 Stream - master: ipa-server-dns-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch ipa-server-4.9.10-6.module_el8.7.0+1209+42bcbcde.x86_64 ipa-server-common-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch 389-ds-base-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64 389-ds-base-libs-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64
Fedora 39 - replica: freeipa-server-common-4.11.1-2.fc39.noarch freeipa-server-4.11.1-2.fc39.x86_64 freeipa-server-dns-4.11.1-2.fc39.noarch 389-ds-base-libs-2.4.5-1.fc39.x86_64 389-ds-base-2.4.5-1.fc39.x86_64
Hi,
On Mon, Mar 18, 2024 at 3:38 PM Ian Kumlien ian.kumlien@gmail.com wrote:
On Thu, Mar 14, 2024 at 7:36 PM Florence Blanc-Renaud flo@redhat.com wrote:
Hi,
On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien ian.kumlien@gmail.com
wrote:
On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien ian.kumlien@gmail.com
wrote:
[--8<--]
As a side node, the conncheck for ipa-ca-install fails all the time now, when executing check on remote master it ends with this: 2024-03-14T07:42:26Z DEBUG Destroyed connection context.rpcclient_139905569284576 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with following error message(s): invalid 'cn': must be "freeipa-4.xerces.lan" 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
Which seems really strange...
The message is highly misleading, but basically means that the conncheck
part tried to check the connection to freeipa-4.xerces.lan, there was an issue and then a different server was tried. Discussed in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Ok, i have actually looked at that and checked the pki security-domain-show --- perhaps i should look at the bug options as well...
Can you provide the exact OS + ipa / 389-ds-base versions that you have
on your server and on your replica? And any relevant info about the history of the master (for instance, was the master initially installed with this version or was it upgraded from older versions).
I verified that the plugin is available on the other end, so ... Centos 8 Stream - master: ipa-server-dns-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch ipa-server-4.9.10-6.module_el8.7.0+1209+42bcbcde.x86_64 ipa-server-common-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch 389-ds-base-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64 389-ds-base-libs-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64
Fedora 39 - replica: freeipa-server-common-4.11.1-2.fc39.noarch freeipa-server-4.11.1-2.fc39.x86_64 freeipa-server-dns-4.11.1-2.fc39.noarch 389-ds-base-libs-2.4.5-1.fc39.x86_64 389-ds-base-2.4.5-1.fc39.x86_64
In this version of 389-ds the default password storage scheme is PBKDF2-SHA *512* but as far as I know, 389-ds-base-1.4.3.28 does not support this scheme, only PBKDF2_SHA*256*. You either need to update the master to a more recent version or force a different password storage scheme on the replica, for instance by providing the following config file to ipa-replica-install: # cat /tmp/dse.ldif dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: PBKDF2_SHA256 # ipa-replica-install [...] --dirsrv-config-file /tmp/dse.ldif
HTH, flo
freeipa-users@lists.fedorahosted.org