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. 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> 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 (exmaple, using real IPs out > there): > > auth.company.com IN NS 10.0.0.1 > > and created > > srv1.auth.company.com (10.0.0.1) > 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 > IP address(es): 10.0.0.1 > Domain name: 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 > Domain: auth.company.com > K5 : COMPANY.COM > > Replica adoption failed because auth.company.com is not company.com. > > > 2nd try, this time: > > Server: srv1.auth.company.com > Domain: company.com > K5 : COMPANY.COM > > Primary failed: ERROR DNS zone COMPANY.COM. already exists in DNS and > is handled by server(s): ns1.ns-serve.net., 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> 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 >>> - ipa02.auth.dc-01.company.com >>> - ipa03.auth.dc-01.company.com >>> - ipa04.auth.dc-01.company.com >>> >>> Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll >>> stick to that as an example) against 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 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 /"\ 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. >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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. > > _______________________________________________ > 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
_______________________________________________ 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
