On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud <f...@redhat.com> wrote: > > Hi, > > On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien <ian.kuml...@gmail.com> wrote: >> >> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud <f...@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.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/ >> >> >> >> 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<--] -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
