Ricardo Mendes via FreeIPA-users wrote:
Hello again Rob,
I really would like to express my appreciation for the feedback you've been giving and trying to help man really amazing!
I have detailed some of the issues I'm going through now here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But basically, I disabled DNSSEC Master on the first server (last lines of the output on that link) that went reasonably well apart from the can't connect to CMS error. So then when I tried to setup the DNSSEC on the replica, it says there's already a DNSSEC key master. Basically anything that's done is out of sync.
See https://www.freeipa.org/page/Howto/DNSSEC#Migrate_DNSSEC_master_to_another_I...
One thing I did actually was to run “ipa-cacert-manage renew --self-signed” on the CA Master as I was looking to return to a more... comfortable/default configuration and also I was looking to see if maybe this would fix the pki-tomcat issue. It did not, but the command ran OK. but I think the other servers don't know about it.
Uhh. Your CA was already self-signed wasn't it? All you did before was replace the HTTP and LDAP certs right?
I also tried to setup another master.
First installed ipa-client, output here: https://pastebin.com/4y8ipupc has some errors.
What is the server idi3? It reports as an IPA master but it wasn't verified.
Then when installing replica, got the following: https://pastebin.com/JXVqSmLs
So it fails with wrong credentials BUT that server (id01) is the server that is accepting the correct DM password, and so I'm not being able to create another replica.
It isn't the DM password that is bad it's something else. Look at the log file as the output suggests, it may have additional details.
- If I removed the references to CA Master on the replica (id01) and for
the dnssec key master manually, deleting references, could I then re-add that role to other replicas?
You have to have a CA to clone from. For DNSSEC yes, see the link above.
- Is there any files I can copy from the replica that is working (and
accepting the correct DM password) to the first master, to restore some functionality? Or even someway fix the pki-tomcat connection to LDAP?
It is likely not something that straightforward.
Regarding the first master with the failing CMS, I've also been through Florence's blog, particularly this article: https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcat...
- the CS.cfg file seems normal with expected values
- the "subsystemCert cert-pki-ca" is present
- the private key can be read using the password
- certmap.conf looks all correct
- running the command "ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso" fails as DM password is rejected. But I am 100% on the DM password and the DM password works on the replica.
Then perhaps it really is different. The DM password isn't replicated.
You might try copying the hash from the working to the non-working master. See https://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpasswo...
And then follow https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
So I can't go past this on troubleshooting pki-tomcat.
I've been with this issues for so long that I'm starting to thing if I just should start a clean new setup and manually migrate things somehow manually? Everything just looks out of sync, completely broken and I am getting less hope each time. Been through the docs but the solutions proposed are not working, I've been trying a couple. There's always some errors, or it seems that something works, but then you realize it only worked locally, but was not propagated. (like the dnssec key master). Don't know where to turn next.
It depends on how many entries you have. Migration in IPA is more meant from a pure-LDAP solution to IPA. There is currently no easy IPA to IPA migration, retaining everything as-it-was.
rob
Kind regards, Ricardo _______________________________________________ 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...
Hi Rob,
About id13, is a dead and gone replica.
About this link: https://www.freeipa.org/page/Howto/DNSSEC#Migrate_DNSSEC_master_to_another_I...
I had found it and it was the guide I used to migrate the DNSSEC Key Master. The issue is that it completed on the DNSSEC Key Master:
# ipa-dns-install --disable-dnssec-master
finished:
Done configuring DNS key synchronization service (ipa-dnskeysyncd). Unconfiguring ods-enforcerd Exporting DNSSEC data before uninstallation Unconfiguring ipa-ods-exporter ipaserver.plugins.dogtag: ERROR ra.find(): Unable to communicate with CMS (500) Unexpected error - see /var/log/ipaserver-install.log for details: CertificateOperationError: Certificate operation cannot be completed: Unable to communicate with CMS (500)
But when I query the servers....... different results. The dnssec key master says there's no server with that role, while replicas still think there's a dnssec key master:
ON DNSSEC Key Master (main):
[root@main ~]# ldapsearch -Y GSSAPI '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' SASL/GSSAPI authentication started SASL username: rmendes@DOMAIN.IO SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=domain,dc=io> (default) with scope subtree # filter: (&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster)) # requesting: ALL #
# search result search: 4 result: 0 Success
# numResponses: 1
ON REPLICA (id01):
[root@id01 ~]# ldapsearch -Y GSSAPI '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' SASL/GSSAPI authentication started SASL username: rmendes@DOMAIN.IO SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=domain,dc=io> (default) with scope subtree # filter: (&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster)) # requesting: ALL #
# DNSSEC, main.domain.io, masters, ipa, etc, domain.io dn: cn=DNSSEC,cn=main.domain.io,cn=masters,cn=ipa,cn=etc,dc=domain,dc=io objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: startOrder 100 ipaConfigString: dnssecKeyMaster ipaConfigString: enabledService cn: DNSSEC
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
And then, when I run the ipa-dns-install ......
[root@id01 ~]# ipa-dns-install --dnssec-master --kasp-db=/root/ipa-kasp.db.backup
The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the IPA Server.
This includes: * Configure DNS (bind) * Configure SoftHSM (required by DNSSEC) * Configure ipa-dnskeysyncd (required by DNSSEC) * Configure ipa-ods-exporter (required by DNSSEC key master) * Configure OpenDNSSEC (required by DNSSEC key master) * Generate DNSSEC master key (required by DNSSEC key master)
NOTE: DNSSEC zone signing is not enabled by default
Plan carefully, replacing DNSSEC key master is not recommended
To accept the default shown in brackets, press the Enter key.
Do you want to setup this IPA server as DNSSEC key master? [no]: yes DNSSEC key master(s): main.domain.io Only one DNSSEC key master is supported in current version.
Fails.
My CA was self signed.... well I was using the Let's Encrypt plugin and I thought that qualified as external CA?
So if I must have a CA to clone from, and my CA server is breaking apart, there's no way I can manually remove that role form that server so it would let me "start" this role from the replica? I've tried several approaches, some from here, but all fail:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
There are some "copies" on the folder /etc/dirsrv/
There's the expected "slapd-DOMAIN-IO" but I also have a "try_ca_renew-slapd-DOMAIN-IO" dir dated from 8 of June that resembles a copy of "slapd-DOMAIN-IO" so I was wondering if between one and other maybe copying some files would work?
I was also tempted to remove the replication agreements between the replica and the master (they don't seem to be working anyway), remove the DNS entries and then try to replicate from id01 solely, don't know if that would work either because the references to DNSSEC Key Master and CA Master still exist on that replica anyway so probably would fail.
Ricardo
On 25/06/2020 21:07, Rob Crittenden wrote:
Ricardo Mendes via FreeIPA-users wrote:
Hello again Rob,
I really would like to express my appreciation for the feedback you've been giving and trying to help man really amazing!
I have detailed some of the issues I'm going through now here: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But basically, I disabled DNSSEC Master on the first server (last lines of the output on that link) that went reasonably well apart from the can't connect to CMS error. So then when I tried to setup the DNSSEC on the replica, it says there's already a DNSSEC key master. Basically anything that's done is out of sync.
See https://www.freeipa.org/page/Howto/DNSSEC#Migrate_DNSSEC_master_to_another_I...
One thing I did actually was to run “ipa-cacert-manage renew --self-signed” on the CA Master as I was looking to return to a more... comfortable/default configuration and also I was looking to see if maybe this would fix the pki-tomcat issue. It did not, but the command ran OK. but I think the other servers don't know about it.
Uhh. Your CA was already self-signed wasn't it? All you did before was replace the HTTP and LDAP certs right?
I also tried to setup another master.
First installed ipa-client, output here: https://pastebin.com/4y8ipupc has some errors.
What is the server idi3? It reports as an IPA master but it wasn't verified.
Then when installing replica, got the following: https://pastebin.com/JXVqSmLs
So it fails with wrong credentials BUT that server (id01) is the server that is accepting the correct DM password, and so I'm not being able to create another replica.
It isn't the DM password that is bad it's something else. Look at the log file as the output suggests, it may have additional details.
- If I removed the references to CA Master on the replica (id01) and for
the dnssec key master manually, deleting references, could I then re-add that role to other replicas?
You have to have a CA to clone from. For DNSSEC yes, see the link above.
- Is there any files I can copy from the replica that is working (and
accepting the correct DM password) to the first master, to restore some functionality? Or even someway fix the pki-tomcat connection to LDAP?
It is likely not something that straightforward.
Regarding the first master with the failing CMS, I've also been through Florence's blog, particularly this article: https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcat...
- the CS.cfg file seems normal with expected values
- the "subsystemCert cert-pki-ca" is present
- the private key can be read using the password
- certmap.conf looks all correct
- running the command "ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso" fails as DM password is rejected. But I am 100% on the DM password and the DM password works on the replica.
Then perhaps it really is different. The DM password isn't replicated.
You might try copying the hash from the working to the non-working master. See https://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpasswo...
And then follow https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
So I can't go past this on troubleshooting pki-tomcat.
I've been with this issues for so long that I'm starting to thing if I just should start a clean new setup and manually migrate things somehow manually? Everything just looks out of sync, completely broken and I am getting less hope each time. Been through the docs but the solutions proposed are not working, I've been trying a couple. There's always some errors, or it seems that something works, but then you realize it only worked locally, but was not propagated. (like the dnssec key master). Don't know where to turn next.
It depends on how many entries you have. Migration in IPA is more meant from a pure-LDAP solution to IPA. There is currently no easy IPA to IPA migration, retaining everything as-it-was.
rob
Kind regards, Ricardo _______________________________________________ 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...
freeipa-users@lists.fedorahosted.org