[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 02/29/2012 04:36 PM, Simo Sorce wrote:
> 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.

I've read some articles about RODC and according to them, RODC is 
supposed to be used in branch offices where could be problem providing 
physical security of the machine - therefore RODC doesn't contain any 
passwords or confident data. The authentication requests must be 
forwarded to regular Domain Controller, but it is also possible to cache 
some credentials - usually the credentials of users that uses the RODC 
frequently, so that possible crack of RODC affects only this small group 
of users. If someone's credentials are not cached and the connection is 
broken between RODC and DC, he can't log in. RODC also supports 
read-only DNS.

If the consumer should really be read-only, then the RODC way seems to 
be exactly what we are looking for.
> Simo.
>


-- 
Regards,

Ondrej Hamada
FreeIPA team
jabber:ohama at jabbim.cz
IRC: ohamada