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, < [email protected]> 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 -- [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
