Re: [Freeipa-users] FreeIPA domains and sub-domains
On 27/10/2016 10:07, Brian Candler wrote: To the OP: in that case, I'd still recommend that you choose a distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated primary domain "ipa.yourcompany.com", and let FreeIPA manage that domain so that it sets up all the right SRV records for auto-discovery. But you don't need to put any hosts inside that DNS domain at all. Aside: I have just been trying this out. What's slightly confusing is that the ipa server-install process requires you to set a "domain name" as well as a realm, and it's not clear to me which "domain" to put here. Is this the domain which corresponds to the realm, or the domain which the clients normally reside in, or something else? For example, suppose I have realm IPA.MYCOMPANY.COM but my servers are xxx.int.mycompany.com. Should I set the FreeIPA "domain" to ipa.mycompany.com or int.mycompany.com, or mycompany.com ? After some experimentation, it seems that the LDAP baseDN is always taken from the realm (dc=ipa,dc=mycompany,dc=com). But the DNS domain is used for: - nisDomain and associatedDomain - ipaDefaultEmailDomain - crucially, the SRV records are published under the DNS domain So it looks like really you should put "ipa.mycompany.com" as the DNS domain, even if the IPA servers are in a different domain. Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA domains and sub-domains
On to, 27 loka 2016, Brian Candler wrote: On 27/10/2016 10:07, Brian Candler wrote: To the OP: in that case, I'd still recommend that you choose a distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated primary domain "ipa.yourcompany.com", and let FreeIPA manage that domain so that it sets up all the right SRV records for auto-discovery. But you don't need to put any hosts inside that DNS domain at all. Aside: I have just been trying this out. What's slightly confusing is that the ipa server-install process requires you to set a "domain name" as well as a realm, and it's not clear to me which "domain" to put here. Is this the domain which corresponds to the realm, or the domain which the clients normally reside in, or something else? For example, suppose I have realm IPA.MYCOMPANY.COM but my servers are xxx.int.mycompany.com. Should I set the FreeIPA "domain" to ipa.mycompany.com or int.mycompany.com, or mycompany.com ? It really depends on your taste, nothing else. There are some technical details, though, that you should look at: - Kerberos implementations have to deal with both realm to DNS and DNS to realm conversions. When there is no static configuration of KDCs per realm, MIT Kerberos would take the name of the realm and treat it as a DNS domain name to perform SRV record query (_kerberos._udp.REALM and _kerberos._tcp.REALM). - for DNS hostname to realm conversion, if realm is unknown, MIT Kerberos might look up TXT record _kerberos.$domain. These two details mean the following: - DNS domain corresponding to your REALM should be under your control. Note that it effectively means if you are using single word REALM, you are asking for trouble with dynamic KDC resolution (do you own one-word top level domain .REALM? With DNSSEC?) - all other domains where the same REALM is in use should have TXT record pointing to your REALM. - As long as you can control how clients resolve DNS hostnames to REALM and discover configuration of the REALM, you should be fine. This is why we recommend to have IPA primary DNS domain the same as REALM. You can have both IPA masters and IPA clients in other DNS domains too but the DNS domain named as your REALM has to be under your control. Final detail is related to the forest trust to Active Directory. Microsoft implementation of Active Directory protocol stack assumes your DNS domain is equal to your realm and that _kerberos.udp or _kerberos._tcp and _ldap._tcp SRV records for this domain point to the proper Active Directory DCs authoritative for the forest of REALM. This is why we recommend to have IPA primary DNS domain the same as REALM. You can have both IPA masters and IPA clients in other DNS domains too but the DNS domain named as your REALM has to be under your control. This will make your life going forward much simpler. After some experimentation, it seems that the LDAP baseDN is always taken from the realm (dc=ipa,dc=mycompany,dc=com). But the DNS domain is used for: - nisDomain and associatedDomain - ipaDefaultEmailDomain - crucially, the SRV records are published under the DNS domain So it looks like really you should put "ipa.mycompany.com" as the DNS domain, even if the IPA servers are in a different domain. FreeIPA enforces realm to primary DNS domain through these elements, right, out of practical needs outlined above. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA domains and sub-domains
On 27/10/2016 09:30, Alexander Bokovoy wrote: Yes, you can do that, there is no issue at all. Thank you for confirming that. To the OP: in that case, I'd still recommend that you choose a distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated primary domain "ipa.yourcompany.com", and let FreeIPA manage that domain so that it sets up all the right SRV records for auto-discovery. But you don't need to put any hosts inside that DNS domain at all. This gives you the flexibility to set up future Kerberos realms like AD.YOURCOMPANY.COM if you deploy Active Directory or Samba4 later. Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA domains and sub-domains
On to, 27 loka 2016, Brian Candler wrote: On 26/10/2016 21:03, Ranbir wrote: If I have two networks, say A and B, and I want both to use the same FreeIPA server, should I have one Freeipa domain for network A and a sub-domain for network B, (domain.local and b.domain.local), or should I create two top level domains (a.local and b.local)? What's the recommended way to do this? Well, as a first point, I'd say never use a fake domain like ".local". Use a subdomain of some real domain that you already have - e.g. int.yourcompany.com. You don't need to expose it to the Internet if you don't want to, and a fake domain can cause you problems down the line. Secondly: do you really need two domains? DNS domains are used as way to delegate administrative responsibility. If the same person is managing the DNS for both sites, then you can just as well use one domain. Personally I like to embed the site in the hostname (e.g. lon-srv-1.int.yourcomany.com), because there are many circumstance in which only the shortened hostname "lon-srv-1" is seen, such as syslog messages and bash prompts. Hence it's good for the hostname itself to be unambiguous. But if you prefer a different DNS domain for equipment in each site, that's not a problem either. You can either create additional domains in FreeIPA (if you want to use the FreeIPA GUI/CLI to manage DNS records), or just have separate DNS domains managed elsewhere. If FreeIPA is managing your DNS, you can get it to manage your reverse DNS too, by creating domains like 10.in-addr.arpa and 168.192.in-addr.arpa. Taking this to extreme: you don't even need to use the same DNS domain for your IPA and your other equipment. It's fine to have: ldap-1.ipa.yourdomain.com host1.site1.yourdomain.com host2.site2.yourdomain.com even if all the hosts are joined into the same Kerberos realm IPA.YOURDOMAIN.COM (which sounds like is what you're doing). This is quite a good approach if you already have existing DNS for site1.yourdomain.com and site2.yourdomain.com which you don't want to change. Having FreeIPA manage its own domain makes it easier to automatically locate the Kerberos servers for the realm IPA.YOURDOMAIN.COM. But even that's not necessary if you are happy to create the necessary SRV records in the DNS yourself. The final issue is IPA replicas in multiple sites. Personally I've put all my IPA replicas in the same DNS domain (ldap-1.ipa.yourcompany.com; ldap-2.ipa.yourcompany.com), and have never tried putting them in different DNS domains: e.g. ipa-1.site1.yourdomain.com ipa-2.site2.yourdomain.com I'm not sure if you can do this, and I think it would be safer not to unless someone else on this list says it's OK. Yes, you can do that, there is no issue at all. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA domains and sub-domains
On ke, 26 loka 2016, Ranbir wrote: Hi Everyone! If I have two networks, say A and B, and I want both to use the same FreeIPA server, should I have one Freeipa domain for network A and a sub-domain for network B, (domain.local and b.domain.local), or should I create two top level domains (a.local and b.local)? What's the recommended way to do this? Does not really matter if you are talking about DNS. Read https://www.freeipa.org/page/Deployment_Recommendations for more details on DNS recommendations. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA domains and sub-domains
Hi Everyone! If I have two networks, say A and B, and I want both to use the same FreeIPA server, should I have one Freeipa domain for network A and a sub-domain for network B, (domain.local and b.domain.local), or should I create two top level domains (a.local and b.local)? What's the recommended way to do this? -- Ranbir -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
