Re: DNS and FreeIPA
by Ian Willis
Hi All,
Angus you appear to be struggling with fundamental concepts of how to
manage DNS rather than how to manage FreeIPA. It appears you've already
made design decisions without understanding the implications. You
really need to understand the concept of split brain DNS and the
complications associated with this approach and if delegation provides
a better solution.
1. FreeIPA either needs to manage DNS, or you need to do it manually
with a third party DNS system, or you can run two sets authoritative
DNS servers one of which is freeIPA and the other which could be a
third party and manually keep them in sync.
2. If you use FreeIPA to manage DNS in a public manner it will
expose the DNS records of associated hosts. What is the issue with
exposing your private IP addresses and hostnames, they're not routable?
Its just security through obscurity, your security should rely upon
stronger foundations.
3. It's not an admins vs devs thing. I'm an admin not a dev you're
just struggling to understand how DNS works and are thrashing around
thinking that a point and click solution will solve this lack of domain
expertise. It won't, understand your requirements and design to them.
Read the BIND documentation, more specifically Split DNS
https://bind9.readthedocs.io/en/latest/
https://bind9.readthedocs.io/en/latest/advanced.html#split-dns
In relation to your question.
* You've already decided that you are using a third party DNS provider
for the domain, that's making this harder. You might want to consider
delegating a subdomain of this domain to freeipa to manage as it's more
straightforward to take that approach, especially if you want
externally available services. However you need to understand how
Delegation works, as the owner of a domain you can delegate a subdomain
to another set of servers.
* You state that you're not exposing any of your internal servers to
the internet. If this is the case why do you need a public DNS domain?
Basically by definition you don't, so the problem is that you're asking
a nonsense question and getting frustrated by the fact that you're not
getting a response that answers you question. I suspect that the domain
will offer some public services and some private services and that's
what you're struggling with. However you haven't articulated this
either.
-----Original Message-----
From: Angus Clarke via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org>
Reply-To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
To: Rafael Jeffman <rjeffman(a)redhat.com>
Cc: Dave Mintz <davemintz64(a)gmail.com>, FreeIPA users list <
freeipa-users(a)lists.fedorahosted.org>, Peter Larsen <
peter(a)peterlarsen.org>, Angus Clarke <angus(a)charworth.com>
Subject: [Freeipa-users] Re: DNS and FreeIPA
Date: Mon, 27 Dec 2021 20:27:14 +0000
Hi Rafael
I appreciate your response but we're (just me?) still lacking in
direction as to how to properly use your software in the real world -
to me It feels like an admins vs devs topic although I could easily be
missing something :)
I mention the Microsoft documentation because i haven't found anything
on this topic in RedHat land. I just remember the MS docs being the
only source of useful information when last I checked.
Ok let's try this:
I've just registered angusclarke.com with a public DNS provider and am
ready to deploy FreeIPA for my corporate network which uses a private
IP space. How do I do this?
According to this
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
then I should have a domain delegated to me, but I am not a public DNS
provider, I'm just Angus Clarke ... Nor do I want my private IP space
available to be looked up in a public DNS record ... And I'd rather
have my private IP
records handled by my internal DNS system - all of this is standard
practise for companies and individuals however I dont think this topic
is suitably addressed in the redhat documentation
- I see a disconnect in the recommendation pasted above vs the
installation documentation for FreeIPA.
Maybe I've missed it, maybe I can promote the topic here and it can be
championed in the right direction, maybe I can even help on the topic
myself.
Regards
Angus
From: Rafael Jeffman <rjeffman(a)redhat.com>
Sent: Monday, 27 December 2021, 8:15 pm
To: Angus Clarke
Cc: FreeIPA users list; Dave Mintz; Peter Larsen
Subject: Re: [Freeipa-users] Re: DNS and FreeIPA
Hello Angus,
On Mon, Dec 27, 2021 at 11:31 AM Angus Clarke <angus(a)charworth.com>
wrote:
>
> Hi Rafael
>
>
>
>
>
> What is not clear to me is how to integrate FreeIPA with a real
> public DNS domain, which I think is what Dave is referring to as he
> mentioned he owns a legitimate domain. In any case, AFAIK we're not
> supposed to use made up domains for internal DNS anymore
> ...
>
>
Although you shouldn't use a domain name you don't own, if your DNS
server is not visible outside of your network, the issues you have with
domain names would be contained to your local network (like not being
able to access 'awellknowsearch.com'
if you use this domain name in
your own network).
>
> I see the docs talk about
> server.idm.example.com - presumably
> example.com is supposed to be some legitimate DNS domain and
> idm.example.com is a delegated subdomain, although this doesn't
> appear to be explained. Microsoft docs talk about using delegated
> subdomains of legitimate public DNS domains for internal corporate
> DNS, which is what got me into this train of thought in
> the first place.
>
>
>
>
>
> Delegating a subdomain to a private IP (your internal DNS server) and
> hiding that delegation with a split view on your public DNS is one
> way of hiding the subdomain from public view whilst keeping all your
> private DNS data private and hosted/managed in house.
> Whether you use FreeIPA's DNS for internally hosting
> idm.example.com or not is a matter of choice I suppose.
>
>
A delegated subdomain is simply a subdomain for which the authoritative
DNS server is not the same as the main domain. I'm not sure about which
Microsoft docs you mention, but on Azure, subdomain delegation might be
required depending on what you want to do on Azure. For private
subdomains, if you have full control of the domain/hosts, there might
not
be a need to delegate the subdomain (as in Peter Larsen's message).
Also, if you consider using split view, FreeIPA DNS should not be used,
and
if you use an external DNS any configuration should be carried on that
DNS
provider, so it is not a matter of configuring DNS within FreeIPA. The
discussion on configuring FreeIPA DNS only makes sense if using
FreeIPA's
integrated DNS.
>
>
>
> Whilst I'm here and at the opposite end of this topic, I run
> bad.domain for our FreeIPA DNS domain (going back years to the
> original installation) with the realm BAD - I'm getting a bit
> uncomfortable about this configuration and wondered if I'll drop out
> of
> support at some point - any thoughts on that? (I surely can't be the
> only one!)
>
>
>
>
>
> I haven't used FreeIPA's DNS.
>
>
If you don't use FreeIPA's DNS, there is no problem in using whatever
your DNS nameserver supports, as long as FreeIPA entries are correct
and accessible. You may find which records need to be available with
`ipa dns-update-system-records --dry-run`.
Hope this helps,
Rafael
>
>
>
>
>
> Thanks
>
> Angus
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Rafael Jeffman via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org>
>
> Sent: Monday, 27 December 2021, 1:31 pm
>
> To: FreeIPA users list
>
> Cc: Dave Mintz; Peter Larsen; Rafael Jeffman
>
> Subject: [Freeipa-users] Re: DNS and FreeIPA
>
>
>
>
>
> Sorry for the top reply, but this is more an overview about all
> messages
> than a direct answer. Everything here assumes you are using FreeIPA's
> integrated DNS.
>
>
>
> First, it was suggested that split view DNS is used. Don't do that,
> as it
> is not supported by FreeIPA. Use it only if you manage your own
> external
> DNS, without using FreeIPA to manage entries.
>
>
>
>
>
> Regarding forwarding DNS queries, the easiest way is to set a global
> forwarder. In my home lab I use public ones, like Google and
> Cloudflare,
> and I'm not much concerned about external traffic, so I leave the
> default
> configuration, "forward first", enabled.
>
>
>
> You can find more information about the available options here:
>
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>
>
>
> A lot more about working with DNS can be found
>
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>
>
>
> Regards,
>
>
>
> Rafael
>
>
>
>
>
>
>
>
> On Mon, Dec 27, 2021 at 1:40 AM Dave Mintz via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org> wrote:
>
>
> > Hi Peter,
> >
> >
> >
> > Thank you so much!
> >
> > Could you please elaborate on how to configure the FreeIPA DNS
> > server to forward only non-local-domain queries?
> >
> >
> >
> > In the DNS Global Configuration there is the Forward policy
> >
> > Forward first
> >
> > Forward only
> >
> > Forwarding disabled
> >
> >
> >
> > Which one should be used to do what you say below?
> >
> > Do I need to set a Global forwarder?
> >
> >
> >
> > Best,
> >
> > Dave
> >
> >
> >
> >
> >
> > > On Dec 26, 2021, at 10:00 PM, Peter Larsen via FreeIPA-users <
> > freeipa-users(a)lists.fedorahosted.org> wrote:
> >
> > >
> >
> > > On Sun, 2021-12-26 at 14:16 -0500, Dave Mintz via FreeIPA-users
> > wrote:
> >
> > >> Hello,
> >
> > >> I have been trying to set up FreeIPA on an internal CentOS 8
> > server.
> >
> > >> I was successful in getting it running, I set up DNS for
> > internal
> >
> > >> queries. It worked. However, when I tried to set up SSL certs
> > I ran
> >
> > >> into issue.
> >
> > >>
> >
> > >> My question is this:
> >
> > >> I own a legitimate domain.
> >
> > >> It is not “hosted”.
> >
> > >> I have no intention of exposing any of my internal servers to
> > the
> >
> > >> Internet.
> >
> > >> How do I go about configuring the DNS at my registrar so that
> > when I
> >
> > >> configure my internal servers, including FreeIPA, DNS, SSL,
> > email,
> >
> > >> etc., any requests that go out to the Internet will resolve
> >
> > >> correctly?
> >
> > >>
> >
> > >> Any help or pointers to documentation would be greatly
> > appreciated.
> >
> > >
> >
> > > I have freeIPA with DNS over several replication instances
> > running. The
> >
> > > domains are like yours mostly internal and not to resolve
> > externally.
> >
> > > Without a lot of boring details, you do not need to register your
> > TLD
> >
> > > if you just use the domain internally. As long as the resolver
> > your
> >
> > > internal hosts point to is your authoritative DNS server that
> > FreeIPA
> >
> > > manages, the clients will get responses as they need.
> >
> > >
> >
> > > This requires your server not to just blindly forward all DNS
> >
> > > externally. I have forward turned off on my domains. This means
> > when a
> >
> > > client requests a public DNS address, the bind server managed by
> >
> > > FreeIPA will do a NS lookup to see where the request needs to be
> > sent.
> >
> > > It's not 1.1.1.1 or similar services doing that. Works great for
> > a
> >
> > > small network where your domain is 100% internal.
> >
> > >
> >
> > > You can have an external NS too and they can provide very
> > different
> >
> > > answers. Perhaps you just want MX to resolve externally but an
> > ocean of
> >
> > > internal addresses should not. If someone outside your network
> > tries to
> >
> > > resolve an address, they will hit the external resolver (not
> > managed by
> >
> > > FreeIPA!) and only resolve what it knows about.
> >
> > >
> >
> > >
> >
> > > _______________________________________________
> >
> > > FreeIPA-users mailing list --
> > freeipa-users(a)lists.fedorahosted.org
> >
> > > To unsubscribe send an email to
> > freeipa-users-leave(a)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.fedoraho...
> >
> > > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
> > _______________________________________________
> >
> > FreeIPA-users mailing list --
> > freeipa-users(a)lists.fedorahosted.org
> >
> > To unsubscribe send an email to
> > freeipa-users-leave(a)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.fedoraho...
> >
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
> >
>
>
>
>
>
> --
>
>
>
> Rafael Guterres Jeffman
>
>
> Senior Software Engineer
> FreeIPA - Red Hat
>
>
>
>
>
>
>
>
>
>
_______________________________________________FreeIPA-users mailing
list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
2 years, 3 months
Re: DNS and FreeIPA
by Jim Kinney
This is far easier than it sounds.
As long as you never want to see any angusclark.com website or host names from anywhere not connected to your private network, just use that domain name in freeipa and and hosts and their ip addresses to freeipa dns. Now when any system on your private network looks for myhost.angusclark.com they get the address from your internal only dns. From outside, that myhosts.angusclark.com host doesn't exist.
Unless you set your freeipa dns as the nameserver in your domain hosting setup, outside will only get a default parked page for web lookup and nothing else.
Assuming your private network does actually have a need for internet access and you do have a gateway set up and it acts as your default router, then you will want to add an upstream dns server in your freeipa dns setup to resolve the non-angusclark.com addresses. Your freeipa dns server will only request data from the upstream source as required. It will never see a (legitimate) request from upstream since you never published the freeipa server dns as being available.
Note: any system with internet access will get probed for security holes. Use good network hygiene and block ports on the systems that should not be seen from the internet.
On December 27, 2021 3:27:14 PM EST, Angus Clarke via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> wrote:
>Hi Rafael
>
>I appreciate your response but we're (just me?) still lacking in
>direction as to how to properly use your software in the real world -
>to me It feels like an admins vs devs topic although I could easily be
>missing something :)
>
>I mention the Microsoft documentation because i haven't found anything
>on this topic in RedHat land. I just remember the MS docs being the
>only source of useful information when last I checked.
>
>
>Ok let's try this:
>
>I've just registered angusclarke.com with a public DNS provider and am
>ready to deploy FreeIPA for my corporate network which uses a private
>IP space. How do I do this?
>
>According to this
>https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
>then I should have a domain delegated to me, but I am not a public DNS
>provider, I'm just Angus Clarke ... Nor do I want my private IP space
>available to be looked up in a public DNS record ... And I'd rather
>have my private IP records handled by my internal DNS system - all of
>this is standard practise for companies and individuals however I dont
>think this topic is suitably addressed in the redhat documentation - I
>see a disconnect in the recommendation pasted above vs the installation
>documentation for FreeIPA.
>
>Maybe I've missed it, maybe I can promote the topic here and it can be
>championed in the right direction, maybe I can even help on the topic
>myself.
>
>Regards
>Angus
>
>
>
>From: Rafael Jeffman <rjeffman(a)redhat.com>
>Sent: Monday, 27 December 2021, 8:15 pm
>To: Angus Clarke
>Cc: FreeIPA users list; Dave Mintz; Peter Larsen
>Subject: Re: [Freeipa-users] Re: DNS and FreeIPA
>
>Hello Angus,
>
>On Mon, Dec 27, 2021 at 11:31 AM Angus Clarke
><angus(a)charworth.com<mailto:angus@charworth.com>> wrote:
>Hi Rafael
>
>What is not clear to me is how to integrate FreeIPA with a real public
>DNS domain, which I think is what Dave is referring to as he mentioned
>he owns a legitimate domain. In any case, AFAIK we're not supposed to
>use made up domains for internal DNS anymore ...
>
>Although you shouldn't use a domain name you don't own, if your DNS
>server is not visible outside of your network, the issues you have with
>domain names would be contained to your local network (like not being
>able to access
>'awellknowsearch.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fawellkn...>'
>if you use this domain name in
>your own network).
>
>
>
>I see the docs talk about
>server.idm.example.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver....>
>- presumably
>example.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample...>
>is supposed to be some legitimate DNS domain and
>idm.example.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.exa...>
>is a delegated subdomain, although this doesn't appear to be explained.
>Microsoft docs talk about using delegated subdomains of legitimate
>public DNS domains for internal corporate DNS, which is what got me
>into this train of thought in the first place.
>
>Delegating a subdomain to a private IP (your internal DNS server) and
>hiding that delegation with a split view on your public DNS is one way
>of hiding the subdomain from public view whilst keeping all your
>private DNS data private and hosted/managed in house. Whether you use
>FreeIPA's DNS for internally hosting
>idm.example.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.exa...>
>or not is a matter of choice I suppose.
>
>A delegated subdomain is simply a subdomain for which the authoritative
>DNS server is not the same as the main domain. I'm not sure about which
>Microsoft docs you mention, but on Azure, subdomain delegation might be
>required depending on what you want to do on Azure. For private
>subdomains, if you have full control of the domain/hosts, there might
>not
>be a need to delegate the subdomain (as in Peter Larsen's message).
>
>Also, if you consider using split view, FreeIPA DNS should not be used,
>and
>if you use an external DNS any configuration should be carried on that
>DNS
>provider, so it is not a matter of configuring DNS within FreeIPA. The
>discussion on configuring FreeIPA DNS only makes sense if using
>FreeIPA's
>integrated DNS.
>
>Whilst I'm here and at the opposite end of this topic, I run bad.domain
>for our FreeIPA DNS domain (going back years to the original
>installation) with the realm BAD - I'm getting a bit uncomfortable
>about this configuration and wondered if I'll drop out of support at
>some point - any thoughts on that? (I surely can't be the only one!)
>
>I haven't used FreeIPA's DNS.
>
>If you don't use FreeIPA's DNS, there is no problem in using whatever
>your DNS nameserver supports, as long as FreeIPA entries are correct
>and accessible. You may find which records need to be available with
>`ipa dns-update-system-records --dry-run`.
>
>Hope this helps,
>
>Rafael
>
>
>Thanks
>Angus
>
>
>
>
>
>________________________________
>From: Rafael Jeffman via FreeIPA-users
><freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>
>Sent: Monday, 27 December 2021, 1:31 pm
>To: FreeIPA users list
>Cc: Dave Mintz; Peter Larsen; Rafael Jeffman
>Subject: [Freeipa-users] Re: DNS and FreeIPA
>
>Sorry for the top reply, but this is more an overview about all
>messages
>than a direct answer. Everything here assumes you are using FreeIPA's
>integrated DNS.
>
>First, it was suggested that split view DNS is used. Don't do that, as
>it
>is not supported by FreeIPA. Use it only if you manage your own
>external
>DNS, without using FreeIPA to manage entries.
>
>Regarding forwarding DNS queries, the easiest way is to set a global
>forwarder. In my home lab I use public ones, like Google and
>Cloudflare,
>and I'm not much concerned about external traffic, so I leave the
>default
>configuration, "forward first", enabled.
>
>You can find more information about the available options here:
>
>https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess...>
>
>A lot more about working with DNS can be found
>
>https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess...>
>
>Regards,
>
>Rafael
>
>
>On Mon, Dec 27, 2021 at 1:40 AM Dave Mintz via FreeIPA-users
><freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>
>wrote:
>Hi Peter,
>
>Thank you so much!
>Could you please elaborate on how to configure the FreeIPA DNS server
>to forward only non-local-domain queries?
>
>In the DNS Global Configuration there is the Forward policy
>Forward first
>Forward only
>Forwarding disabled
>
>Which one should be used to do what you say below?
>Do I need to set a Global forwarder?
>
>Best,
>Dave
>
>
>> On Dec 26, 2021, at 10:00 PM, Peter Larsen via FreeIPA-users
><freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>
>wrote:
>>
>> On Sun, 2021-12-26 at 14:16 -0500, Dave Mintz via FreeIPA-users
>wrote:
>>> Hello,
>>> I have been trying to set up FreeIPA on an internal CentOS 8 server.
>>> I was successful in getting it running, I set up DNS for internal
>>> queries. It worked. However, when I tried to set up SSL certs I
>ran
>>> into issue.
>>>
>>> My question is this:
>>> I own a legitimate domain.
>>> It is not “hosted”.
>>> I have no intention of exposing any of my internal servers to the
>>> Internet.
>>> How do I go about configuring the DNS at my registrar so that when I
>>> configure my internal servers, including FreeIPA, DNS, SSL, email,
>>> etc., any requests that go out to the Internet will resolve
>>> correctly?
>>>
>>> Any help or pointers to documentation would be greatly appreciated.
>>
>> I have freeIPA with DNS over several replication instances running.
>The
>> domains are like yours mostly internal and not to resolve externally.
>> Without a lot of boring details, you do not need to register your TLD
>> if you just use the domain internally. As long as the resolver your
>> internal hosts point to is your authoritative DNS server that FreeIPA
>> manages, the clients will get responses as they need.
>>
>> This requires your server not to just blindly forward all DNS
>> externally. I have forward turned off on my domains. This means when
>a
>> client requests a public DNS address, the bind server managed by
>> FreeIPA will do a NS lookup to see where the request needs to be
>sent.
>> It's not 1.1.1.1 or similar services doing that. Works great for a
>> small network where your domain is 100% internal.
>>
>> You can have an external NS too and they can provide very different
>> answers. Perhaps you just want MX to resolve externally but an ocean
>of
>> internal addresses should not. If someone outside your network tries
>to
>> resolve an address, they will hit the external resolver (not managed
>by
>> FreeIPA!) and only resolve what it knows about.
>>
>>
>> _______________________________________________
>> FreeIPA-users mailing list --
>freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
>> To unsubscribe send an email to
>freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@lists.fedorahosted.org>
>> Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.f...>
>> List Guidelines:
>https://fedoraproject.org/wiki/Mailing_list_guidelines<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedora...>
>> List Archives:
>https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....>
>> Do not reply to spam on the list, report it:
>https://pagure.io/fedora-infrastructure<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure...>
>_______________________________________________
>FreeIPA-users mailing list --
>freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
>To unsubscribe send an email to
>freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@lists.fedorahosted.org>
>Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.f...>
>List Guidelines:
>https://fedoraproject.org/wiki/Mailing_list_guidelines<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedora...>
>List Archives:
>https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....>
>Do not reply to spam on the list, report it:
>https://pagure.io/fedora-infrastructure<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure...>
>
>
>--
>Rafael Guterres Jeffman
>Senior Software Engineer
>FreeIPA - Red Hat
>
>
>
>
>--
>Rafael Guterres Jeffman
>Senior Software Engineer
>FreeIPA - Red Hat
--
Computers amplify human error
Super computers are really cool
2 years, 3 months
Re: DNS and FreeIPA
by Rafael Jeffman
Hello Angus,
On Mon, Dec 27, 2021 at 11:31 AM Angus Clarke <angus(a)charworth.com> wrote:
> Hi Rafael
>
> What is not clear to me is how to integrate FreeIPA with a real public DNS
> domain, which I think is what Dave is referring to as he mentioned he owns
> a legitimate domain. In any case, AFAIK we're not supposed to use made up
> domains for internal DNS anymore ...
>
Although you shouldn't use a domain name you don't own, if your DNS
server is not visible outside of your network, the issues you have with
domain names would be contained to your local network (like not being
able to access 'awellknowsearch.com' if you use this domain name in
your own network).
> I see the docs talk about server.idm.example.com - presumably example.com
> is supposed to be some legitimate DNS domain and idm.example.com is a
> delegated subdomain, although this doesn't appear to be explained.
> Microsoft docs talk about using delegated subdomains of legitimate public
> DNS domains for internal corporate DNS, which is what got me into this
> train of thought in the first place.
>
> Delegating a subdomain to a private IP (your internal DNS server) and
> hiding that delegation with a split view on your public DNS is one way of
> hiding the subdomain from public view whilst keeping all your private DNS
> data private and hosted/managed in house. Whether you use FreeIPA's DNS for
> internally hosting idm.example.com or not is a matter of choice I suppose.
>
A delegated subdomain is simply a subdomain for which the authoritative
DNS server is not the same as the main domain. I'm not sure about which
Microsoft docs you mention, but on Azure, subdomain delegation might be
required depending on what you want to do on Azure. For private
subdomains, if you have full control of the domain/hosts, there might not
be a need to delegate the subdomain (as in Peter Larsen's message).
Also, if you consider using split view, FreeIPA DNS should not be used, and
if you use an external DNS any configuration should be carried on that DNS
provider, so it is not a matter of configuring DNS within FreeIPA. The
discussion on configuring FreeIPA DNS only makes sense if using FreeIPA's
integrated DNS.
> Whilst I'm here and at the opposite end of this topic, I run bad.domain
> for our FreeIPA DNS domain (going back years to the original installation)
> with the realm BAD - I'm getting a bit uncomfortable about this
> configuration and wondered if I'll drop out of support at some point - any
> thoughts on that? (I surely can't be the only one!)
>
> I haven't used FreeIPA's DNS.
>
If you don't use FreeIPA's DNS, there is no problem in using whatever
your DNS nameserver supports, as long as FreeIPA entries are correct
and accessible. You may find which records need to be available with
`ipa dns-update-system-records --dry-run`.
Hope this helps,
Rafael
> Thanks
> Angus
>
>
>
>
>
> ------------------------------
> *From:* Rafael Jeffman via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org>
> *Sent:* Monday, 27 December 2021, 1:31 pm
> *To:* FreeIPA users list
> *Cc:* Dave Mintz; Peter Larsen; Rafael Jeffman
> *Subject:* [Freeipa-users] Re: DNS and FreeIPA
>
> Sorry for the top reply, but this is more an overview about all messages
> than a direct answer. Everything here assumes you are using FreeIPA's
> integrated DNS.
>
> First, it was suggested that split view DNS is used. Don't do that, as it
> is not supported by FreeIPA. Use it only if you manage your own external
> DNS, without using FreeIPA to manage entries.
>
> Regarding forwarding DNS queries, the easiest way is to set a global
> forwarder. In my home lab I use public ones, like Google and Cloudflare,
> and I'm not much concerned about external traffic, so I leave the default
> configuration, "forward first", enabled.
>
> You can find more information about the available options here:
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess...>
>
> A lot more about working with DNS can be found
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess...>
>
> Regards,
>
> Rafael
>
>
> On Mon, Dec 27, 2021 at 1:40 AM Dave Mintz via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org> wrote:
>
>> Hi Peter,
>>
>> Thank you so much!
>> Could you please elaborate on how to configure the FreeIPA DNS server to
>> forward only non-local-domain queries?
>>
>> In the DNS Global Configuration there is the Forward policy
>> Forward first
>> Forward only
>> Forwarding disabled
>>
>> Which one should be used to do what you say below?
>> Do I need to set a Global forwarder?
>>
>> Best,
>> Dave
>>
>>
>> > On Dec 26, 2021, at 10:00 PM, Peter Larsen via FreeIPA-users <
>> freeipa-users(a)lists.fedorahosted.org> wrote:
>> >
>> > On Sun, 2021-12-26 at 14:16 -0500, Dave Mintz via FreeIPA-users wrote:
>> >> Hello,
>> >> I have been trying to set up FreeIPA on an internal CentOS 8 server.
>> >> I was successful in getting it running, I set up DNS for internal
>> >> queries. It worked. However, when I tried to set up SSL certs I ran
>> >> into issue.
>> >>
>> >> My question is this:
>> >> I own a legitimate domain.
>> >> It is not “hosted”.
>> >> I have no intention of exposing any of my internal servers to the
>> >> Internet.
>> >> How do I go about configuring the DNS at my registrar so that when I
>> >> configure my internal servers, including FreeIPA, DNS, SSL, email,
>> >> etc., any requests that go out to the Internet will resolve
>> >> correctly?
>> >>
>> >> Any help or pointers to documentation would be greatly appreciated.
>> >
>> > I have freeIPA with DNS over several replication instances running. The
>> > domains are like yours mostly internal and not to resolve externally.
>> > Without a lot of boring details, you do not need to register your TLD
>> > if you just use the domain internally. As long as the resolver your
>> > internal hosts point to is your authoritative DNS server that FreeIPA
>> > manages, the clients will get responses as they need.
>> >
>> > This requires your server not to just blindly forward all DNS
>> > externally. I have forward turned off on my domains. This means when a
>> > client requests a public DNS address, the bind server managed by
>> > FreeIPA will do a NS lookup to see where the request needs to be sent.
>> > It's not 1.1.1.1 or similar services doing that. Works great for a
>> > small network where your domain is 100% internal.
>> >
>> > You can have an external NS too and they can provide very different
>> > answers. Perhaps you just want MX to resolve externally but an ocean of
>> > internal addresses should not. If someone outside your network tries to
>> > resolve an address, they will hit the external resolver (not managed by
>> > FreeIPA!) and only resolve what it knows about.
>> >
>> >
>> > _______________________________________________
>> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> > To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>> > Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.f...>
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedora...>
>> > List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....>
>> > Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure...>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.f...>
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedora...>
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....>
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure...>
>>
>
>
> --
> Rafael Guterres Jeffman
> Senior Software Engineer
> FreeIPA - Red Hat
>
>
>
--
Rafael Guterres Jeffman
Senior Software Engineer
FreeIPA - Red Hat
2 years, 3 months
DNS and FreeIPA
by Dave Mintz
Hello,
I have been trying to set up FreeIPA on an internal CentOS 8 server. I was successful in getting it running, I set up DNS for internal queries. It worked. However, when I tried to set up SSL certs I ran into issue.
My question is this:
I own a legitimate domain.
It is not “hosted”.
I have no intention of exposing any of my internal servers to the Internet.
How do I go about configuring the DNS at my registrar so that when I configure my internal servers, including FreeIPA, DNS, SSL, email, etc., any requests that go out to the Internet will resolve correctly?
Any help or pointers to documentation would be greatly appreciated.
Dave
2 years, 3 months
SSL error after upgrade
by Per Qvindesland
Hi AllAfter an update to 4.9.6-10, I am unable to view any of the certificates that the IPA server has signed, I get error: An error has occurred (IPA Error 4301: CertificateOperationError) when I click on Authnticaiton -> Certificates, if I click on "Certificate Autorities" then I get popup message with the error "Failed to authenticate to CA REST API" and "An error has occurred (IPA Error 4016: RemoteRetrieveError)" is showing on the screen.ipactl status is showing everything as running:ipactl status Directory Service: RUNNINGkrb5kdc Service: RUNNINGkadmin Service: RUNNINGnamed Service: RUNNINGhttpd Service: RUNNINGipa-custodia Service: RUNNINGpki-tomcatd Service: RUNNINGsmb Service: RUNNINGwinbind Service: RUNNINGipa-otpd Service: RUNNINGipa-dnskeysyncd Service: RUNNINGipa: INFO: The ipactl command was successfulDoes anyone know what's causing this error?I ran ipa-healthcheck and pasted the output below, it reports that it's missing SRV records but the IPA server is the DNS server and it has the SRV records.RegardsPeripa-healthcheck ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)[ { "source": "ipahealthcheck.dogtag.ca", "check": "DogtagCertsConnectivityCheck", "result": "ERROR", "uuid": "ac0200eb-3ec8-405f-ba5e-523cbb40ad6b", "when": "20211222151125Z", "duration": "0.016156", "kw": { "msg": "Request for certificate failed, Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "2f010c35-7d7d-431f-89b0-c342516cf296", "when": "20211222151130Z", "duration": "0.412221", "kw": { "key": "20211104170633", "serial": 7, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "10a946e2-e511-417a-b189-a66f1b555470", "when": "20211222151130Z", "duration": "0.519989", "kw": { "key": "20211104170628", "serial": 5, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "7c85e383-8508-4b8e-a10b-838b0b70eb73", "when": "20211222151130Z", "duration": "0.618106", "kw": { "key": "20211104170629", "serial": 2, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "1776678c-d997-435b-b809-52576128a2e9", "when": "20211222151130Z", "duration": "0.709013", "kw": { "key": "20211104170630", "serial": 4, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "f02ff5d9-13cf-4582-9bd3-7567b32c415d", "when": "20211222151130Z", "duration": "0.789825", "kw": { "key": "20211104170631", "serial": 1, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "d30b17b3-f45e-4317-bf8e-c1c13c3f77e3", "when": "20211222151131Z", "duration": "0.903311", "kw": { "key": "20211104170632", "serial": 3, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "32ff9bb7-69b8-4af3-8c20-9f2ab4394a73", "when": "20211222151131Z", "duration": "0.969296", "kw": { "key": "20211104170635", "serial": 34, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "18fb96f0-7a64-4c1c-b03b-bb21e3f90bf1", "when": "20211222151131Z", "duration": "1.065584", "kw": { "key": "20211104170634", "serial": 8, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertRevocation", "result": "ERROR", "uuid": "d82cdf6d-4d4b-44e4-9aa8-33211aa55c96", "when": "20211222151131Z", "duration": "1.116597", "kw": { "key": "20210811074531", "serial": 10, "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)", "msg": "Request for certificate serial number {serial} in request {key} failed: {error}" } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "cc0c7d5c-1132-4b18-ac8e-c7625d3963f0", "when": "20211222151131Z", "duration": "0.015692", "kw": { "msg": "Expected SRV record missing", "key": "_ldap._tcp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "f0d6873f-b681-457d-8006-9e5bb051b9df", "when": "20211222151131Z", "duration": "0.017296", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._tcp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "92a5517d-5f73-4f49-8874-bf6bbeb2ed9d", "when": "20211222151131Z", "duration": "0.018275", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._udp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "7f1994fb-e1dc-4d8c-93c5-5ba2e6652427", "when": "20211222151131Z", "duration": "0.019243", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos-master._tcp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "e9bbd202-8f37-4a44-b9b0-377ae5a53d08", "when": "20211222151131Z", "duration": "0.020150", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos-master._udp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "2d4a438f-6271-470e-a6f5-68a30858d928", "when": "20211222151131Z", "duration": "0.021502", "kw": { "msg": "Expected SRV record missing", "key": "_kpasswd._tcp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "828efbaf-2071-4693-94f4-0e4c2ec884c0", "when": "20211222151131Z", "duration": "0.022772", "kw": { "msg": "Expected SRV record missing", "key": "_kpasswd._udp.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "b0a73e45-da65-43a6-a540-8e092e3e4d76", "when": "20211222151131Z", "duration": "0.023895", "kw": { "msg": "Expected SRV record missing", "key": "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.proxdynamics.com.:lda...." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "3329eea5-c794-4201-a973-82f22b58f151", "when": "20211222151131Z", "duration": "0.025341", "kw": { "msg": "Expected SRV record missing", "key": "_ldap._tcp.dc._msdcs.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "dde9dd12-e044-4bde-a75f-2ea4d96910dc", "when": "20211222151131Z", "duration": "0.027364", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.proxdynamics.com....." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "9ebec84f-aa7d-4ba9-8c4e-ca8dd2aa98c8", "when": "20211222151131Z", "duration": "0.029421", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.proxdynamics.com....." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "cd921441-98bf-4fc1-a043-ed35a056e818", "when": "20211222151131Z", "duration": "0.030800", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._tcp.dc._msdcs.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "93f21c35-a10d-418b-a549-c0c70d6330cd", "when": "20211222151131Z", "duration": "0.031808", "kw": { "msg": "Expected SRV record missing", "key": "_kerberos._udp.dc._msdcs.proxdynamics.com.:ldap2.inne.proxdynamics.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "331ef74f-e5d6-47d8-a666-a352320772de", "when": "20211222151131Z", "duration": "0.034319", "kw": { "msg": "Got {count} ipa-ca A records, expected {expected}", "count": 0, "expected": 1 } }]
2 years, 4 months
Re: IPA Server Upgrade: CA REST API: 403 error
by Alexander Bokovoy
On to, 23 joulu 2021, Dungan, Scott A. via FreeIPA-users wrote:
>Thanks for the link, Ferrão!
>
>Using the information from that thread, I inspected the contents of /etc/pki/pki-tomcat/server.xml and noticed that on lines 129 and 171, there were two values listed: one for sectet= and one for requiredSecret=. In addition, the two secrets were different. Only the “secret=” value matched what was located in the /etc/httpd/conf.d/ipa-pki-proxy.conf for the ProxyPassMatch statements that Rob referred to in the thread you linked. I went ahead and changed the value of “requiredSecret=” to be the same in server.xml, restarted IPA services, and the error was resolved!
>
>Questions unanswered: where did this other (incorrect) value for
>requiredSecret come from? Some sort of failure in the upgrade script?
>Having both secret and requiredSecret specified (both with the same
>correct value) is now required in /etc/pki/pki-tomcat/server.xml?
>Looking at the other not-yet-upgraded IPA servers, that line only lists
>sectet=
The right thread to watch is https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
As I said there, "is that both pki upgrade code and ipa upgrade
code triggered and pki upgrade code adds 'requiredSecret' part. IPA
upgrade code is present since FreeIPA 4.9.0, since March 2020, more than
1.5 years ago."
PKI added upgrade support code in their RHEL 8.5.0 update. As a result,
FreeIPA's code seems to stumble on some of the upgrade paths. Since it
is triggered during new IPA package upgrade, we get this mix of two
upgrade routines that create a conflicting configuration together.
PKI upgrade code refactoring ignores Tomcat version which is wrong.
https://bugzilla.redhat.com/show_bug.cgi?id=2006070 tracks a fix for
this on PKI side and it will be out in next minor RHEL 8 version,
hopefully (and in CentOS 8 Stream before that).
>
>Fixed line #129 in /etc/pki/pki-tomcat/server.xml for IPA server version 4.9.6-10:
>
><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost4" name="Connector1" secret="123456789abcdefghijklmnopqrstuvwxyz" requiredSecret="123456789abcdefghijklmnopqrstuvwxyz"/>
>
>Line #129 in /etc/pki/pki-tomcat/server.xml for IPA server version 4.9.6-6:
>
><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost4" name="Connector1" secret="123456789abcdefghijklmnopqrstuvwxyz "/>
>
>-Scott
>
>From: Vinícius Ferrão <ferrao(a)versatushpc.com.br>
>Sent: Wednesday, December 22, 2021 11:15 AM
>To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>Cc: Dungan, Scott A. <sdungan(a)caltech.edu>
>Subject: Re: [Freeipa-users] IPA Server Upgrade: CA REST API: 403 error
>
>Sorry. Wrong link. This is the one: https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg1258...
>Sent from my iPhone
>
>
>On 22 Dec 2021, at 16:14, Vinícius Ferrão <ferrao(a)versatushpc.com.br<mailto:ferrao@versatushpc.com.br>> wrote:
> Is this related?
>
>https://pagure.io/freeipa/issue/9041
>Sent from my iPhone
>
>
>On 22 Dec 2021, at 15:35, Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>
>Prior to running yum update on one of our IPA servers running RHEL8 version 4.9.6-6, ipa-healthcheck showed no errors. After running the update to 4.9.6-10, healthcheck threw “non-2xx response from CA REST API: 403” errors:
>
>[root@ipa1 ~]# ipa-healthcheck --failures-only
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
>[
> {
> "source": "ipahealthcheck.dogtag.ca",
> "check": "DogtagCertsConnectivityCheck",
> "result": "ERROR",
> "uuid": "0fcf1f94-16d3-4f33-aabc-446403a8190f",
> "when": "20211222175722Z",
> "duration": "0.715360",
> "kw": {
> "msg": "Request for certificate failed, Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "969b76e2-bda7-4d47-a76b-fa48b59e469f",
> "when": "20211222175735Z",
> "duration": "1.208329",
> "kw": {
> "key": "20210406003327",
> "serial": 7,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "696f34d9-e965-4d23-8a60-192811cedd51",
> "when": "20211222175735Z",
> "duration": "1.479161",
> "kw": {
> "key": "20210406003320",
> "serial": 5,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "bd716c75-de8b-4893-9e6e-f474dcf898a6",
> "when": "20211222175735Z",
> "duration": "1.747070",
> "kw": {
> "key": "20210406003321",
> "serial": 2,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "59815cd0-e48c-47bf-965f-c089bcf0f2dd",
> "when": "20211222175736Z",
> "duration": "2.021750",
> "kw": {
> "key": "20210406003322",
> "serial": 4,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "ea34c649-7823-4c35-b54d-7b3aaf8677c8",
> "when": "20211222175736Z",
> "duration": "2.291332",
> "kw": {
> "key": "20210406003323",
> "serial": 1,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "8ed4da7b-dec9-4dc5-ad05-ac7064181481",
> "when": "20211222175736Z",
> "duration": "2.567577",
> "kw": {
> "key": "20210406003326",
> "serial": 3,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "faf9b70b-333e-4e08-a211-bd887c346d13",
> "when": "20211222175736Z",
> "duration": "2.723022",
> "kw": {
> "key": "20211130180109",
> "serial": 20,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "6f4097a7-c62a-4771-9019-90c3fa8d0e80",
> "when": "20211222175737Z",
> "duration": "2.985982",
> "kw": {
> "key": "20210406003328",
> "serial": 8,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "check": "IPACertRevocation",
> "result": "ERROR",
> "uuid": "1e7bfdc0-6dbf-4d0c-a102-86b312c8181e",
> "when": "20211222175737Z",
> "duration": "3.136052",
> "kw": {
> "key": "20201110192416",
> "serial": 10,
> "error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
> "msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
> }
> }
>]
>
>Logging into web ui works, but when clicking through to the Authentication tab, the following error pops:
>
>IPA Error 4301: CertificateOperationError
>Certificate operation cannot be completed: Unable to communicate with CMS (403)
>
>About three weeks ago, we had replication issues with this particular server but resolved them with Rob’s help. See the thread here: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
>Any help would be appreciated. Thanks,
>
>Scott
>
>_______________________________________________
>FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
>To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@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.fedoraho...
>Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2 years, 4 months
Re: IPA Server Upgrade: CA REST API: 403 error
by Vinícius Ferrão
Is this related?
https://pagure.io/freeipa/issue/9041
Sent from my iPhone
On 22 Dec 2021, at 15:35, Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> wrote:
Prior to running yum update on one of our IPA servers running RHEL8 version 4.9.6-6, ipa-healthcheck showed no errors. After running the update to 4.9.6-10, healthcheck threw “non-2xx response from CA REST API: 403” errors:
[root@ipa1 ~]# ipa-healthcheck --failures-only
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
[
{
"source": "ipahealthcheck.dogtag.ca",
"check": "DogtagCertsConnectivityCheck",
"result": "ERROR",
"uuid": "0fcf1f94-16d3-4f33-aabc-446403a8190f",
"when": "20211222175722Z",
"duration": "0.715360",
"kw": {
"msg": "Request for certificate failed, Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "969b76e2-bda7-4d47-a76b-fa48b59e469f",
"when": "20211222175735Z",
"duration": "1.208329",
"kw": {
"key": "20210406003327",
"serial": 7,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "696f34d9-e965-4d23-8a60-192811cedd51",
"when": "20211222175735Z",
"duration": "1.479161",
"kw": {
"key": "20210406003320",
"serial": 5,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "bd716c75-de8b-4893-9e6e-f474dcf898a6",
"when": "20211222175735Z",
"duration": "1.747070",
"kw": {
"key": "20210406003321",
"serial": 2,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "59815cd0-e48c-47bf-965f-c089bcf0f2dd",
"when": "20211222175736Z",
"duration": "2.021750",
"kw": {
"key": "20210406003322",
"serial": 4,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "ea34c649-7823-4c35-b54d-7b3aaf8677c8",
"when": "20211222175736Z",
"duration": "2.291332",
"kw": {
"key": "20210406003323",
"serial": 1,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "8ed4da7b-dec9-4dc5-ad05-ac7064181481",
"when": "20211222175736Z",
"duration": "2.567577",
"kw": {
"key": "20210406003326",
"serial": 3,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "faf9b70b-333e-4e08-a211-bd887c346d13",
"when": "20211222175736Z",
"duration": "2.723022",
"kw": {
"key": "20211130180109",
"serial": 20,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "6f4097a7-c62a-4771-9019-90c3fa8d0e80",
"when": "20211222175737Z",
"duration": "2.985982",
"kw": {
"key": "20210406003328",
"serial": 8,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "1e7bfdc0-6dbf-4d0c-a102-86b312c8181e",
"when": "20211222175737Z",
"duration": "3.136052",
"kw": {
"key": "20201110192416",
"serial": 10,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
}
]
Logging into web ui works, but when clicking through to the Authentication tab, the following error pops:
IPA Error 4301: CertificateOperationError
Certificate operation cannot be completed: Unable to communicate with CMS (403)
About three weeks ago, we had replication issues with this particular server but resolved them with Rob’s help. See the thread here: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Any help would be appreciated. Thanks,
Scott
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 4 months
IPA Server Upgrade: CA REST API: 403 error
by Dungan, Scott A.
Prior to running yum update on one of our IPA servers running RHEL8 version 4.9.6-6, ipa-healthcheck showed no errors. After running the update to 4.9.6-10, healthcheck threw "non-2xx response from CA REST API: 403" errors:
[root@ipa1 ~]# ipa-healthcheck --failures-only
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
[
{
"source": "ipahealthcheck.dogtag.ca",
"check": "DogtagCertsConnectivityCheck",
"result": "ERROR",
"uuid": "0fcf1f94-16d3-4f33-aabc-446403a8190f",
"when": "20211222175722Z",
"duration": "0.715360",
"kw": {
"msg": "Request for certificate failed, Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "969b76e2-bda7-4d47-a76b-fa48b59e469f",
"when": "20211222175735Z",
"duration": "1.208329",
"kw": {
"key": "20210406003327",
"serial": 7,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "696f34d9-e965-4d23-8a60-192811cedd51",
"when": "20211222175735Z",
"duration": "1.479161",
"kw": {
"key": "20210406003320",
"serial": 5,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "bd716c75-de8b-4893-9e6e-f474dcf898a6",
"when": "20211222175735Z",
"duration": "1.747070",
"kw": {
"key": "20210406003321",
"serial": 2,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "59815cd0-e48c-47bf-965f-c089bcf0f2dd",
"when": "20211222175736Z",
"duration": "2.021750",
"kw": {
"key": "20210406003322",
"serial": 4,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "ea34c649-7823-4c35-b54d-7b3aaf8677c8",
"when": "20211222175736Z",
"duration": "2.291332",
"kw": {
"key": "20210406003323",
"serial": 1,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "8ed4da7b-dec9-4dc5-ad05-ac7064181481",
"when": "20211222175736Z",
"duration": "2.567577",
"kw": {
"key": "20210406003326",
"serial": 3,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "faf9b70b-333e-4e08-a211-bd887c346d13",
"when": "20211222175736Z",
"duration": "2.723022",
"kw": {
"key": "20211130180109",
"serial": 20,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "6f4097a7-c62a-4771-9019-90c3fa8d0e80",
"when": "20211222175737Z",
"duration": "2.985982",
"kw": {
"key": "20210406003328",
"serial": 8,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
},
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "1e7bfdc0-6dbf-4d0c-a102-86b312c8181e",
"when": "20211222175737Z",
"duration": "3.136052",
"kw": {
"key": "20201110192416",
"serial": 10,
"error": "Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)",
"msg": "Request for certificate serial number {serial} in request {key} failed: {error}"
}
}
]
Logging into web ui works, but when clicking through to the Authentication tab, the following error pops:
IPA Error 4301: CertificateOperationError
Certificate operation cannot be completed: Unable to communicate with CMS (403)
About three weeks ago, we had replication issues with this particular server but resolved them with Rob's help. See the thread here: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Any help would be appreciated. Thanks,
Scott
2 years, 4 months