Forgot to add [1]: https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/
On Thu, 17 Oct 2024, 20.09 Alexander Bokovoy, <aboko...@redhat.com> wrote: > I have trouble answering from phone this week so I'll do a top post. I > think it is not something that can be supported as part of the standard > support policy so it is understandable why RHEL support people rejected it. > > You need to be very careful in your configuration because Kerberos will > require DNS resolution anyway. See my blog from 2019 for some details[1]. A > simple mistake and a client would look at a wrong kdc. It is just too > fragile. If you'd ever get a request to interop with that AD setup, you'd > be done. Any effort on the organization side to distribute certificates > issued in the same namespace and clients trusting both CAs to issue those > and having CA constraints to limit things? > > Some of those might be fixable through organizational policies but those > would definitely be not something we (FreeIPA) would be supporting because > they would conflict with practically every interop feature we have to > support. > > > > On Thu, 17 Oct 2024, 19.56 Rob Crittenden via FreeIPA-users, < > freeipa-users@lists.fedorahosted.org> wrote: > >> Sarah PETER via FreeIPA-users wrote: >> > Dear all, >> > >> > >> > >> > TLDR; >> > >> > We have an IPA setup consisting of four replicas (2 CA, 2 non-CA) >> > without any of the DNS records that ‘ipa dns-update-system-records‘ >> > suggests and we share our DNS domain with AD. Will we have any issues, >> > assuming that we are not using Kerberos automatic discovery, the krb, >> > sssd and ipa configuration files have the servers explicitly configured >> > and we are not using trust to Active Directory? >> >> We don't typically test this scenario but it should work. You'll be >> hardcoding configuration files with specific hosts so failover if a >> server is down may not be as robust but it should still work depending >> on how you are doing it. >> >> > >> > >> > I have inherited a 10-year-old FreeIPA setup with four replicas, which >> > is in a non-supported configuration according to RedHat support, but has >> > always worked fine for us. I would like to know if we can keep it >> > running like it is, or if we will face issues in the future and if yes, >> > which ones. >> >> Do they provide any specific reasons why your configuration is not >> supported? Is it this same DNS reason? >> >> > >> > >> > We are a small sub-group in a bigger organization managing our own Linux >> > VMs. We manage SSH login with sssd and LDAP logins to web services with >> > FreeIPA. Our parent organization runs Active Directory and the DNS >> > servers on the same domain that we have configured in FreeIPA. We do not >> > have any trust relationship with the Active Directory and won’t ever be >> > allowed to have it, either. We do not want any auto-discovery to happen, >> > to make sure other people’s machines don’t accidentally try to contact >> > or enroll with our infrastructure. Therefore, we have no DNS records at >> > all anywhere pointing to our IPA servers and instead always configure >> > this explicitly in the client and server install and ipa, sssd and krb >> > configuration files. >> > >> > >> > >> > We are in the process of migrating to RHEL 8 and the new ipa-healthcheck >> > complains on various levels about the missing DNS records (error for >> > ipa-ca, warning for the rest). RedHat support insisted that we need to >> > migrate our setup to a different domain and create the DNS records. >> > However, migration would be a huge challenge, because there is no >> > procedure to migrate all data in IPA (we have quite extensive HBAC >> > rules) and the DNS records we don’t want to create to prevent >> > auto-discovery and also wouldn’t be allowed from the parent >> organization. >> >> So healthcheck provides recommendations. It isn't the law. If you don't >> want DNS you don't have to use it AFAIR, particularly since you don't >> use AD. There are downsides but it should still work. >> >> Depending on the RHEL release check the ipahealthcheck.conf(5) man page >> for how to exclude certain results. This can make your healthcheck >> output end without warning or errors for things you want to ignore. >> >> > >> > I would appreciate if someone could tell me the actual issues that we >> > could encounter running this setup with multiple (2 CA, 2 non-CA) >> > replicas. I’m mostly concerned about complications with replication or >> > certificates (renewal). >> >> Assuming the hosts themselves are in DNS and/or /etc/hosts then >> replication should be unaffected. It doesn't rely on discovery. >> >> certificate renewal pretty much the same. Where you may have problems if >> you don't have ipa-ca.DOMAIN defined is OCSP and CRL because this is the >> name used for that so that the service isn't tied to a specific IPA >> host. >> >> We have an ipa to ipa migration tool in upstream that will make >> retaining all the records easier. It will still be disruptive because >> all the keys will be different so it isn't a panacea. >> >> Your biggest exposure is if an IPA server goes down for an extended >> time. Failover may not work as well as it would if you had discovery >> enabled. >> >> Ideally in a situation like this your Linux hosts would be in its own >> sub-domain that could be delegated to IPA and then it could work in its >> own little world. But that is understandably difficult to do after 10 >> years. >> >> rob >> >> -- >> _______________________________________________ >> 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 >> >
-- _______________________________________________ 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
