Ah, that was good to know, you’re converting a plain LDAP + Kerberos setup to IPA with integrated LDAP, integrated Kerberos and integrated DNS.
What’s important to know is that you cannot really cleanly convert that as the Kerberos tabs will have to be updated. With such a change, updating the kerberos config files is an easy next step.

Regarding DNS, NAT, KDCProxy, that’s most for if you wanted to do kerberos over the internet. Normally, you wouldn’t give an IPA server a public IP, so you’d NAT anyway. Natting an additional IP is a small pain to add ;-)
KDCProxy is meant as a kerberos-over-the-web solution where you can use kerberos in a somewhat safer way. Regarding the KDC realm: most people don’t really care what their ticket principals look like ;-)

If you have existing DNS, and you must re-use it for some reason, that is a more problematic scenario. In those cases it’s easier to just use a CNAME of additional A record on your existing DNS and point them to the new DNS.
Say your current setup is:

ldap.company.com for LDAP
kerberos.company.com for Kerberos

You could setup IPA with:

auth.company.com for everything (LDAP, web, KDC, KDC Proxy)

And then add a CNAME for ldap.company.com to auth.company.com for LDAP and a CNAME for kerberos.company.com to auth.company.com for Kerberos.
That way, the client-side config wouldn’t have to change domain names. The Kerberos realm would have to change so that’s a configuration you have to update anyway, no getting past that.
Configuring hosts for IPA uses the ipa-client-install script anyway, and that script would configure everything automatically anyway, so you don’t actually have to mess with the domains anyway. 
The domains and manual naming of things is only relevant if you have to manually configure everything.

John


On 17 Jun 2019, at 14:59, Christian Reiss via FreeIPA-users <freeipa-users@lists.fedorahosted.org> wrote:

Hey John,

Awesome response :)
But I am not setting any dns records by hand. I did it *prior* to
FreeIPA. We are using naked Kerberos and ldap as-is. So thats where the
DNS RR are coming from.

Does "Dont run IPA on a domain thats in use" mean "entire domain" or
"Subdomain is OK"?

kdcproxy.. nat.. does not really sound awesome to be honest.
Would a setup on auth.company.com (realm, domain, etc) have and
disadvantages? I could simply add dns srv records from company.com to
auth.company.com?

And it's okay I guess if the host keytabs look like

  host/server.company.com@AUTH.COMPANY.COM

I am slowly getting there :)

-Chris.

On 17/06/2019 14:06, John Keates via FreeIPA-users wrote:
In that case, you’re doing it wrong ;-)

Don’t manually make DNS records, it’s not needed unless you disable the
built in DNS server in IPA. Also, don’t try to run IPA on a domain
that’s in use for something else. Keeping it simple and ’standard’ will
help you a ton here.
For example, if you setup your server like this, all should would
out-of-the-box:

ipa-server-install —domain=auth.company.com <http://auth.company.com>
—realm=AUTH.COMPANY.COM <http://AUTH.COMPANY.COM> --setup-dns

(Note: I’d use ds.company.com <http://ds.company.com> because auth
suggests it’s just an authentication server, but IPA is a lot more than
dat; then again ds for directory service isn’t a complete picture
either, you’d probably end up with ipa.company.com
<http://ipa.company.com> if you wanted to do it ‘right’)

For public use, I’d suggest using kdcproxy which is designed for public
exposure. It’s supported in IPA.

If you wanted to use separate domain names for TCP/IP communication,
that is not connected to what you set in IPA. So if you have IPA setup,
you can always make an extra DNS record called kerberos.company.com
<http://kerberos.company.com>, point it to an IP, hand then internally
NAT that IP to any IPA server(s) you want.

John

On 17 Jun 2019, at 13:58, Christian Reiss via FreeIPA-users
<freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>> wrote:

Hey John,

thanks again for a detailed information. I do understand this, but maybe
I am overthinking it. The current setup (non IPA) is:

company.com <http://company.com> Domain name,
Using kerberos on kerberos.company.com <http://kerberos.company.com>.
SRV & TXT Records all point to kerberos.company.com
<http://kerberos.company.com>.

All user prinicipals are user@COMPANY.COM <mailto:user@COMPANY.COM>,
all kerberized
services/keytabs have a principal of host/vm4.company.com@COMPANY.COM
<mailto:host/vm4.company.com@COMPANY.COM>

What we are aiming for is: A User requests a TGT via

kinit john@COMPANY.COM <mailto:john@COMPANY.COM> (ignoring default
realms for a bit) and it would
receive a TGT from either IPA server issues to

 john@COMPANY.COM <mailto:john@COMPANY.COM>

Servers are in the form

 host/server.company.com@COMPANY.COM
<mailto:host/server.company.com@COMPANY.COM>

Also, things that use ldap want dc=company,dc=com.
We will not be using any Windows / AD things. Only UNIX/Linux.
The Services are used in house as well as from around the world (public).

Thanks so much.
-Christian.


On 17/06/2019 13:44, John Keates via FreeIPA-users wrote:
What you are trying to do is possible but not recommended. If you make a
distinction between what you want your users to ’see’ and what your
domain technically should be you can probably resolve it.
For IPA, it’s important that the domain for the built in DNS server is
not used. That means: do not use a domain that is in use. Not for your
IPA domain and not for the kerberos realm.

So, say you have company.com <http://company.com>
<http://company.com> and that is in use and
you want to setup IPA. Since it’s in use, you’ll have to start on level
down on a subdomain.
That means (per your choice AFAIK) that you have to set it all to
auth.company.com <http://auth.company.com> <http://auth.company.com>,
both the IPA domain and the
kerberos realm. The main zone, company.com <http://company.com>
<http://company.com> doesn’t
actually come into play here.

Afterwards, if you want to, you could make NS delegations to your IPA
server(s) from your main zone.

If you can’t make this work out, or if DNS is managed by multiple
teams/people, it might be much easier to simply register a second domain
just for IPA, remove all of its public zones and just use it inside IPA.
So if you have company.com <http://company.com>
<http://company.com> you could use something
like company.net <http://company.net> <http://company.net> if that’s
available. Could be
confusing for users, so maybe companyauth.com <http://companyauth.com>
<http://companyauth.com> or company-internal.com
<http://company-internal.com>
<http://company-internal.com>.

The “domain” part in the server setup doesn’t mean anything regarding
what your users would type to access your web stuff, that can be proxied
and renamed as much as you like to anything else.

Something else: what is your goal? Is this IPA setup for internal use,
public use, end-users, admin-users, workstations, servers, web
applications?

John

On 17 Jun 2019, at 11:49, Christian Reiss via FreeIPA-users
<freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
<mailto:freeipa-users@lists.fedorahosted.org>> wrote:

Hey John,

Thanks for a speedy reply! Sure helped a lot understanding, tho a pity
that some clients simply require a "a/cname" and do not look up any srv,
like pfsense. And your reverse proxy idea is neat.


Just one issue, either technical or lack of understanding:

So I went ahead for the domain company.com <http://company.com>
<http://company.com>
(exmaple, using real IPs out
there):

auth.company.com <http://auth.company.com> <http://auth.company.com>
IN NS 10.0.0.1

and created

srv1.auth.company.com <http://srv1.auth.company.com>
<http://srv1.auth.company.com> (10.0.0.1)
srv2.auth.company.com <http://srv2.auth.company.com>
<http://srv2.auth.company.com> (10.0.0.2)

During setup of srv1 I set:

The IPA Master Server will be configured with:
Hostname:       srv1.auth.company.com <http://srv1.auth.company.com>
<http://srv1.auth.company.com>
IP address(es): 10.0.0.1
Domain name:    auth.company.com <http://auth.company.com>
<http://auth.company.com>
Realm name:     COMPANY.COOM

BIND DNS server will be configured to serve IPA domain with:
Forwarders:       10.0.0.1
Forward policy:   first
Reverse zone(s):  0.0.10.in-addr.arpa.

WARNING: Realm name does not match the domain name.
You will not be able to establish trusts with Active Directory unless
the realm name of the IPA server matches its domain name.

So:
Server: srv1.auth.company.com <http://srv1.auth.company.com>
<http://srv1.auth.company.com>
Domain: auth.company.com <http://auth.company.com>
<http://auth.company.com>
K5    : COMPANY.COM <http://COMPANY.COM> <http://COMPANY.COM>

Replica adoption failed because auth.company.com
<http://auth.company.com>
<http://auth.company.com> is not company.com <http://company.com>
<http://company.com>.


2nd try, this time:

Server: srv1.auth.company.com <http://srv1.auth.company.com>
<http://srv1.auth.company.com>
Domain: company.com <http://company.com> <http://company.com>
K5    : COMPANY.COM <http://COMPANY.COM> <http://COMPANY.COM>

Primary failed: ERROR    DNS zone COMPANY.COM <http://COMPANY.COM>
<http://COMPANY.COM>.
already exists in DNS and
is handled by server(s): ns1.ns-serve.net <http://ns1.ns-serve.net>
<http://ns1.ns-serve.net>.,
ns2.ns-serve.net <http://ns2.ns-serve.net> <http://ns2.ns-serve.net>.

What would be the right approach here?

Thanks again!
-Chris.


On 17/06/2019 10:10, John Keates via FreeIPA-users wrote:
A HA-aware client would use SRV records to locate the server(s) and
then connect every returned instance until a working server is found.
And by using locations you can scope the servers you get back.

Regarding the single URL: while there are many options, we decided to
simply register all servers in a load balancer and when you access
the URL provided by the loadbalancer you simply get redirected to any
working server.
Some people prefer no URL redirects and try to solve it using stick
tables and the likes, but to us that seems like a dirty solution so
we ditched it after a PoC phase. It works but we don’t want it ;-)

If you have a special use case, a separate web app that talks to IPA
can be better, that is what we did for non-tech accounts; a simple
self-service app that allows you to change your own password and
manage MFA.
For everything else (i.e. SSO, SAML etc.) we often use something else
that talks to IPA, like Keycloak, because the IPA WebUI itself is
really not going to give a user any useful functionality; it’s more
of an operator and admin thing.

John

On 17 Jun 2019, at 10:02, Christian Reiss via FreeIPA-users
<freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
<mailto:freeipa-users@lists.fedorahosted.org>> wrote:

Hey folks,

I just recently began planning the deployment of FreeIPA and have
successfully made several test setups.  Next step would be to
integrate
this in our new datacenter; so we are starting there from scratch.

I understand HA on the server side. What boogles my head is HA on the
*client* side.

For example: Our pfsenses use a LDAP lookup against a single FQDN, and
the cert must be valid (against any provided CA). Exporting the CA
from
freeIPA and importing that in pfsense is a cake.

But what do I point the clients towards? Let's say I have 4 FreeIPA
servers:

- ipa01.auth.dc-01.company.com
<http://ipa01.auth.dc-01.company.com>
<http://ipa01.auth.dc-01.company.com>
- ipa02.auth.dc-01.company.com
<http://ipa02.auth.dc-01.company.com>
<http://ipa02.auth.dc-01.company.com>
- ipa03.auth.dc-01.company.com
<http://ipa03.auth.dc-01.company.com>
<http://ipa03.auth.dc-01.company.com>
- ipa04.auth.dc-01.company.com
<http://ipa04.auth.dc-01.company.com>
<http://ipa04.auth.dc-01.company.com>

Realm company.com <http://company.com> <http://company.com>,
Kerberos COMPANY.COM <http://COMPANY.COM>
<http://COMPANY.COM>. If I point the pfsense (I'll
stick to that as an example) against ipa01.auth.dc-01.company.com
<http://ipa01.auth.dc-01.company.com>
<http://ipa01.auth.dc-01.company.com> and
this server is offline, then no HA is given. DNS Delegation might
yield
*any* of the four servers, including the one offline, so a 25% fault
chance in there.

Second question, same area: If I want my users to have one single url
for the FreeIPA webservice, like auth.company.com
<http://auth.company.com>
<http://auth.company.com> that follows the above
solution then the self-signed and generated certs do not have this as
altname.


So summed up:

- How can I make (ldap) clients access the current online server(s)?
- How can I provide access to the webinterace to the current online
server(s)?


(Or is this simply by the magic of dns zone delegation and pure faith
that always an online server will be hit?)

Thanks for any advice!
-Christian.

--
Christian Reiss - email@christian-reiss.de
<mailto:email@christian-reiss.de>
<mailto:email@christian-reiss.de>         /"\  ASCII Ribbon
                 support@alpha-labs.net
<mailto:support@alpha-labs.net>
<mailto:support@alpha-labs.net>           \ /    Campaign
                                                   X   against HTML
WEB alpha-labs.net <http://alpha-labs.net> <http://alpha-labs.net>
                                / \   in eMails

GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5

"It's better to reign in hell than to serve in heaven.",
                                        John Milton, Paradise lost.

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@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.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@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.fedorahosted.org


--
Christian Reiss - email@christian-reiss.de
<mailto:email@christian-reiss.de>
<mailto:email@christian-reiss.de>         /"\  ASCII Ribbon
                  support@alpha-labs.net <mailto:support@alpha-labs.net>
<mailto:support@alpha-labs.net>           \ /    Campaign
                                                    X   against HTML
WEB alpha-labs.net <http://alpha-labs.net> <http://alpha-labs.net>
                                / \   in eMails

GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5

"It's better to reign in hell than to serve in heaven.",
                                         John Milton, Paradise lost.

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@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.fedorahosted.org


_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@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.fedorahosted.org


--
Christian Reiss - email@christian-reiss.de
<mailto:email@christian-reiss.de>         /"\  ASCII Ribbon
                  support@alpha-labs.net
<mailto:support@alpha-labs.net>           \ /    Campaign
                                                    X   against HTML
WEB alpha-labs.net <http://alpha-labs.net>
                                / \   in eMails

GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5

"It's better to reign in hell than to serve in heaven.",
                                         John Milton, Paradise lost.

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@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.fedorahosted.org


_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 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.fedorahosted.org


--
Christian Reiss - email@christian-reiss.de         /"\  ASCII Ribbon
                  support@alpha-labs.net           \ /    Campaign
                                                    X   against HTML
WEB alpha-labs.net                                 / \   in eMails

GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5

"It's better to reign in hell than to serve in heaven.",
                                         John Milton, Paradise lost.

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 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.fedorahosted.org