[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Wed, 2012-02-29 at 16:19 +0100, Ondrej Hamada wrote:
> Hi everyone,
> I'm currently working on my thesis. It's objective is $SUBJ and we
> already have ticket for that: #194. The task is to create two more
> replica types - the HUB and Consumer. In 389-DS both the HUB and
> Consumer are read-only. Additionally the HUB can push the data to the
> Consumers.
> 
> In case of FreeIPA the server is not only providing data, but also
> services like CA, NTP, DNS, Kerberos. Therefore I'm kindly asking you
> for advices and opinions on that:
> 
> 1. What should be the position of HUB?
> I mean should it be used as an interconnection between Masters and
> Consumers only, so that it will be 'hidden' in the topology and only
> forwards the updates, or should the HUB be also used as a regular
> Consumer which has additional ability to push the updates further to
> Consumers/HUBS?
> 
I would think that having shadow HUBs would make things more reliable.

> 2. Which services should be available on HUB and Consumer?
> I think, the priority of these replicas would be to answer to data
> request by ipa whatever-(find|show) commands or to provide some LDAP
> data for email addressing etc. Also it shouldn't cause much trouble to
> run NTP on Consumer, but what about Kerberos or CA? Is it a good
> solution to let users authenticate against these replicas? Is it
> correct to leave classified data like passwords on these replicas?

CA's clearly have no place in a read-only replica in my mind.

Kerberos stuff is different. The problem with a read-only replica and
Kerberos is that krb needs to write data for local user lockouts.
Password changes can be avoided by allowing kadmind only on full
masters.

There is also another angle to consider and that is the Rad-Only Domain
Controller (RODC) available in the Microsoft world. This kind of server
is even more limited than a read-only replica as it does not contain the
full data. To do that it requires quite some tweaking on the KDC
component too, so maybe it is out of scope, but it may make sense
reading up on what they do to have a sense of the kind of services they
enable/disable on read only servers.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York