Deploying FreeIPA within existing company domain/DNS

My team would like to have centralized authentication for all of their Linux servers, although there is no company wide LDAP or Active Directory to leverage to do so. The wisdom of the internet seems to recommend FreeIPA, although as a non-DNS expert, I’ve found the DNS aspects of FreeIPA difficult to decipher.

Should I use the integrated DNS service when deploying FreeIPA within an existing company domain/DNS?

  • If I set up FreeIPA with DNS and use a subdomain, I assume there are some DNS records that will need to be updated on either the existing DNS service and/or the FreeIPA DNS service, what should they be?

  • Should the team’s servers now change their FQDN to include the subdomain?

Lets use these for examples:

  • Existing organization domain called: dept.uni.edu
  • Servers are named in the following way (pre-FreeIPA): server1.dept.uni.edu
  • FreeIPA DNS server configured to use subdomain team.dept.uni.edu

I had a similar situation but where I had no possibility of persuading the corporate Windows support monkeys who handle DNS of adding SRV, NS etc records and whatever else FreeIPA suggests you should do. This extended to it being problematic to even change the domain name used by the Linux systems. The easiest approach ended up with disabling the built-in DNS and having a realm and domain which don’t match. This all works. The absence of many of the DNS records (SRV stuff) doesn’t really matter because IPA clients are using their config files to find the servers rather than DNS.

It depends on whether you can get cooperation from the people running DNS in the wider organisation and whether any machines on their system need to access your servers. If they don’t delegate the team.dept.uni.edu subdomain to you, it could be painful because your machines end up with two fully qualified names and things get confused. If your machines never need to talk to their’s you might not care.

Leave a Comment