Hi Flo (and other helpful people on this list), After fixing the SID/PAC issue, i am back to looking as to why the ipa-replica-conncheck fails when installing the CA to a (working) replica.
I ran your suggested commands and they look fine now. [root@ipa011 ~]# kdestroy kdestroy: No credentials cache found while destroying cache [root@ipa011 ~]# kinit -V -kt /etc/krb5.keytab host/ [email protected] Using default cache: 0 Using principal: host/[email protected] Using keytab: /etc/krb5.keytab Authenticated to Kerberos v5 [root@ipa011 ~]# kvno HTTP/[email protected] HTTP/[email protected]: kvno = 1 I can run the following BEFORE i install the replica and it works 100%, it is part of our pre-reqs in our docs to make sure comms work. ipa-replica-conncheck --master=ipa008.ad.companyx.fm --auto-master-check --realm=AD.companyx.FM --principal=nicholas.cross After i install the replica with ipa-replica-install. (no DNS, no CA) then running the above ipa-replica-conncheck command fails and we see the errors as described. Some logs: 1. before ipa-replica-install - conn check works. http://sprunge.us/4yrInD 2. after successful ipa-replica-install - but conn check fails http://sprunge.us/gvqEle new replica versions [root@ipa011 ~]# rpm -qa | grep ipa | sort almalinux-logos-ipa-90.5.1-1.1.el9.noarch ipa-client-4.10.1-6.el9.x86_64 ipa-client-common-4.10.1-6.el9.noarch ipa-common-4.10.1-6.el9.noarch ipa-healthcheck-0.12-1.el9.noarch ipa-healthcheck-core-0.12-1.el9.noarch ipa-selinux-4.9.8-7.el9_0.noarch ipa-server-4.10.1-6.el9.x86_64 ipa-server-common-4.10.1-6.el9.noarch ipa-server-dns-4.10.1-6.el9.noarch libipa_hbac-2.8.2-2.el9.x86_64 python3-ipaclient-4.10.1-6.el9.noarch python3-ipalib-4.10.1-6.el9.noarch python3-ipaserver-4.10.1-6.el9.noarch python3-libipa_hbac-2.8.2-2.el9.x86_64 sssd-ipa-2.8.2-2.el9.x86_64 current master versions [nicholas.cross@ipa008 ~]$ rpm -qa | grep ipa | sort almalinux-logos-ipa-90.5.1-1.1.el9.noarch ipa-client-4.10.0-8.el9_1.x86_64 ipa-client-common-4.10.0-8.el9_1.noarch ipa-common-4.10.0-8.el9_1.noarch ipa-healthcheck-0.9-9.el9.noarch ipa-healthcheck-core-0.9-9.el9.noarch ipa-selinux-4.9.8-7.el9_0.noarch ipa-server-4.10.0-8.el9_1.x86_64 ipa-server-common-4.10.0-8.el9_1.noarch ipa-server-dns-4.10.0-8.el9_1.noarch libipa_hbac-2.7.3-4.el9_1.3.x86_64 python3-ipaclient-4.10.0-8.el9_1.noarch python3-ipalib-4.10.0-8.el9_1.noarch python3-ipaserver-4.10.0-8.el9_1.noarch python3-libipa_hbac-2.7.3-4.el9_1.3.x86_64 sssd-ipa-2.7.3-4.el9_1.3.x86_64 thanks, Nick On Tue, 23 May 2023 at 10:01, Florence Blanc-Renaud <[email protected]> wrote: > Hi, > > the replica-conncheck error means that a call to server_conncheck reached > the wrong server. ipa-replica-conncheck performs multiple checks: > - first from the replica to the existing master (here we seem to be good) > - then from the existing master to the replica, by doing a call to the > XMLRPC api server_conncheck on the master. If the connection from replica > to master fails, another server is tried (in this case, the replica > launches server_conncheck on itself), but there is a security that ensures > the right server is handling the call. > The logs shows that the connection fails because of SASL auth failure: > 2023-05-22T18:14:03Z INFO Connection to > https://ipa010.ad.companyx.fm/ipa/json failed with Insufficient access: > SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or > the credentials were unavailable or inaccessible (Credential cache is empty) > > Are you able to do kinit -kt /etc/krb5.keytab host/<replicafqdn>@<REALM> > on the replica? And then kvno HTTP/<serverfqdn>@<REALM> ? > flo > > On Tue, May 23, 2023 at 9:55 AM Nicholas Cross via FreeIPA-users < > [email protected]> wrote: > >> That was the /var/log/ipareplica-conncheck.log log file >> >> it does looks like a DNs issue, but im not sure where. >> >> dns resolves the host fine on the host >> >> [root@ipa011 ~]# host ipa011 >> ipa011.ad.companyx.fm has address 10.32.225.7 >> >> [root@ipa011 ~]# grep ipa /etc/ipa/default.conf >> host = ipa011.ad.companyx.fm >> xmlrpc_uri = https://ipa011.ad.companyx.fm/ipa/xml >> ca_host = ipa010.ad.companyx.fm >> >> it's odd as i run the connection check before the start of the install, >> to check ports and routes. it works fine. >> replica install works. >> dns install works. >> just the ca installer comes back with this error. >> >> As an additional test i added the dns record for this host into IPA >> before the install. Normally we don't need to, but just as a test, but it >> made no difference. >> >> >> We do have new DNS forwarders on the network - these are in front of the >> IPA servers. They are there just take the load from the k8s clusters away >> from IPA DNS. >> Would the CA install break if the DNS lookups are "proxied" by the DNS >> forwarders? >> All DNS tests i can think of work via the forwarders. The IPA clients >> (100s) are all fine with them. >> >> I will update the client to ignore the forwarders, but if you can think >> of anything else to try? >> >> thanks, Nick >> _______________________________________________ >> FreeIPA-users mailing list -- [email protected] >> To unsubscribe send an email to >> [email protected] >> 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/[email protected] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
