Dear Rob and Alexander, thank you very much for the insights!
Sorry, my email client doesn’t format inline replies properly, so here are my answers: The reasons RedHat mentioned for the unsupported setup was mainly that we are using the same domain/realm as the company AD and that the DNS records were missing. Regarding hardcoding the configuration files, we are fine with that, we have automation in place that manages those files. This will also help in cases where one hosts goes down for an extended time. The hosts themselves have correct DNS entries and /etc/hosts files. I will check if we can get that ipa-ca.DOMAIN DNS entry at least then, to avoid issues with CRL. I’m looking forward to the IPA-to-IPA migration tool. Once that is available, we will check if we can migrate to a different domain. My understanding of Kerberos is still very limited, so I will need to check how changing the realm to SUB.COMPANY.COM affects our setup, considering many of our hosts in IPA are in the parent domain COMPANY.COM. We are not actively using Kerberos in our current setup, and I don’t see a use case where we would have to, same for the interaction with AD. Does IPA rely on Kerberos working? “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?” No, nothing like that. We are not getting any support for our setup from the parent organisation (therefore also no AD trust). Best regards, Sarah From: Alexander Bokovoy <[email protected]> Date: Thursday, 17 October 2024 at 19:11 To: FreeIPA users list <[email protected]> Cc: Sarah PETER <[email protected]>, Rob Crittenden <[email protected]> Subject: Re: [Freeipa-users] Re: IPA setup without DNS entries You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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, <[email protected]<mailto:[email protected]>> 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, <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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
