Sarah PETER wrote: > 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.
If you don't use OCSP or CRLs then don't treat this as a blocker. You'll just have to deal with annoying warnings from ipa-healthcheck or use the exclude settings to skip them. > > > 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. It should work. You just will probably need to pass in extra options to ipa-client-install so it can find the right realm. > > > 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? Yes Kerberos is required. > > > “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). I guess I'd say "don't fix what ain't broke." IPA should be able to run fine in complete isolation. It's just so much nicer when DNS is involved (I can't believe I'm praising DNS). Just a note about migration. It is looking pretty good right now in beta. It will add a way to make major changes like changing realm but it comes at a cost. All clients will need to be re-enrolled, certificates issued and new replicas added. But for your island of Linux floating in a sea of AD it will let you continue to be independent and still utilize DNS discovery. Sometimes I want to throttle my local network admin for past decisions then remember that's me and just sigh heavily instead. rob > > > > 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
