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 Domain name, Using kerberos on kerberos.company.com. SRV & TXT Records all point to kerberos.company.com. All user prinicipals are u...@company.com, all kerberized services/keytabs have a principal of host/vm4.company....@company.com What we are aiming for is: A User requests a TGT via kinit j...@company.com (ignoring default realms for a bit) and it would receive a TGT from either IPA server issues to j...@company.com Servers are in the form host/server.company....@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> 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>, both the IPA domain and the > kerberos realm. The main zone, 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> you could use something > like company.net <http://company.net> if that’s available. Could be > confusing for users, so maybe companyauth.com > <http://companyauth.com> or 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>> 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> >> (exmaple, using real IPs out >> there): >> >> auth.company.com <http://auth.company.com> IN NS 10.0.0.1 >> >> and created >> >> srv1.auth.company.com <http://srv1.auth.company.com> (10.0.0.1) >> 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> >> IP address(es): 10.0.0.1 >> Domain name: 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> >> Domain: auth.company.com <http://auth.company.com> >> K5 : COMPANY.COM <http://COMPANY.COM> >> >> Replica adoption failed because auth.company.com >> <http://auth.company.com> is not company.com <http://company.com>. >> >> >> 2nd try, this time: >> >> Server: srv1.auth.company.com <http://srv1.auth.company.com> >> Domain: company.com <http://company.com> >> K5 : COMPANY.COM <http://COMPANY.COM> >> >> Primary failed: ERROR DNS zone COMPANY.COM <http://COMPANY.COM>. >> already exists in DNS and >> is handled by server(s): ns1.ns-serve.net <http://ns1.ns-serve.net>., >> 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>> 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> >>>> - 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> >>>> - ipa04.auth.dc-01.company.com <http://ipa04.auth.dc-01.company.com> >>>> >>>> Realm company.com <http://company.com>, Kerberos 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> 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> 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 - em...@christian-reiss.de >>>> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >>>> supp...@alpha-labs.net >>>> <mailto:supp...@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-le...@lists.fedorahosted.org >>>> <mailto:freeipa-users-le...@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-le...@lists.fedorahosted.org >>> <mailto:freeipa-users-le...@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 - em...@christian-reiss.de >> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >> supp...@alpha-labs.net >> <mailto:supp...@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-le...@lists.fedorahosted.org >> <mailto:freeipa-users-le...@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-le...@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 - em...@christian-reiss.de /"\ ASCII Ribbon supp...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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
