[Freeipa-users] Enrolling with multiple IPA servers

[Petr Spacek]

On 6.10.2014 20:43, Alexander Bokovoy wrote:
> On Mon, 06 Oct 2014, Nordgren, Bryce L -FS wrote:
>>> The hostname put by ipa-client-install corresponds to the server to which this
>>> client is enrolled.  You enroll with a single server, after all.
>>
>> How would one enroll with multiple IPA servers? For instance, a
>> standard configuration for a Rocks HPC cluster is to have at least two
>> and usually three networks active, with different DNS zones for each.
>> The "public" network is "company.example.com", "private" is typically
>> an isolated GbE network named "local", and there's usually a fast
>> network for real work (Infiniband or 10GbE); let's name it "ipoib" for
>> IP over Infiniband. There may also be a slow 100bT network for
>> management.
> I don't think this has anything to do with 'enroll with multiple IPA servers'.
>
> 'Enrolling a host' in IPA terms means:
> 1. creating a host record + Kerberos principal for host/`hostname`
> 2. configuring the client to provide identity information, with
>     host/`hostname` as an originator when talking to LDAP and other
>     servers.
>
> As all IPA masters are equal and only differs in additional services
> like hosting CA or DNS, a record created at one of them will be
> propagated to all of others in the topology. So (1) can be done at any
> accessible IPA master.
>
> By default (2) is configured against the server used at (1). If
> discovery of IPA master using SRV records was successful, SSSD will have
> its configuration pointed to use _srv_ (meaning do dynamic discovery
> using SRV records at run time) and using the server this host was
> enrolled to as a server of last hope.
>
> If you want to use another strategy, you are welcome to change the
> generated configuration to something different.
>
> If you have some masters that are accessible by these isolated nodes,
> enroll isolated nodes against these masters. Nobody prevents you to
> select your deployment strategy and manipulate configuration files
> afterwards. Purpleidea's puppet module even allows you to define IPA
> masters' topology right in puppet scripts, if puppet is in use.
>
>
>> A few machines have access to all three networks
>> (headnode.company.example.com, headnode.local, and headnode.ipoib).
>> Compute nodes have access to two (compute-0-0.local,
>> compute-0-0.ipoib).
>>
>> Is it possible to make a single IPA instance manage the two isolated
>> networks (local and ipoib)? Would multiple IPA servers and multiple
>> enrollments be required? Once an IPA solution is defined, how does one
>> configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO
>> (and NFS server access) works regardless of which isolated network is
>> used for communication?  Would the compute nodes' two-network
>> configuration be extensible to the headnode's three-network
>> configuration?
> If you want to make IPA masters available through several interfaces,
> you need to select one of that interfaces as primary and add SAN names
> to the certificates (LDAP, HTTP) of that server so that any node
> enrolled to this master will be able to use it. Think of those nodes as
> IPA masters in the isolated network, then enroll your isolated computing
> nodes to those masters.
>
> As long as you have means to uniquely identify DNS names of all hosts
> and your local IPA master can give you a ticket to a host/`hostname` of
> a host in question, things will work on Kerberos level.

I agree with Alexander so I will only mention one nit from DNS's point of view:

Do not use 'local.' TLD, it is reserved for mDNS [1]. It is much better to use 
name 'compute-0-0.local.company.example.com' instead of 'compute-0-0.local'.

The fact parent DNS name is in public sub-tree (company.example.com) doesn't 
force you to make all children also public. The name server can have private 
IP address or you can drop all queries from outside on firewall.

This approach has two benefits:
- You will not get naming conflicts when companies merge.
- Things will not break when DNSSEC validation is enabled.

Naturally you will not change host names now but it is a thing to keep in mind 
for future.

Have a nice day!

[1] http://tools.ietf.org/html/rfc6762

-- 
Petr^2 Spacek