IPA setup without DNS entries

[Sarah PETER]

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?

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.

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.

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).

Best regards,
Sarah

[Rob Crittenden]

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

[Alexander Bokovoy]

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, <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Alexander Bokovoy]

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,  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, <
> [e-mail]> 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 -- [e-mail]
> > To unsubscribe send an email to
> > [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue

[Sarah PETER]

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 
Date: Thursday, 17 October 2024 at 19:11
To: FreeIPA users list 
Cc: Sarah PETER , Rob Crittenden 
Subject: Re: [Freeipa-users] Re: IPA setup without DNS entries
You don't often get email from [e-mail]. Learn why this is importanthttps://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, <[e-mail]> 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, <[e-mail]> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]
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/[e-mail]...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Rob Crittenden]

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 
> *Date: *Thursday, 17 October 2024 at 19:11
> *To: *FreeIPA users list 
> *Cc: *Sarah PETER , Rob Crittenden 
> *Subject: *Re: [Freeipa-users] Re: IPA setup without DNS entries
>
> You don't often get email from [e-mail]. 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, <[e-mail]
> > 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,
> <[e-mail]
> <mailto:[e-mail]>> 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 --
>     [e-mail]
>     <mailto:[e-mail]>
>     To unsubscribe send an email to
>     [e-mail]
>     <mailto:[e-mail]>
>     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/[e-mail]
>     Do not reply to spam, report it:
>     https://pagure.io/fedora-infrastructure/new_issue